Kultura
Kooperacja pracowników z różnych dziedzin IT przy tworzeniu wspólnego projektu, umożliwia szybsze i sprawniejsze wytwarzanie oprogramowania. Ponadto taki produkt ma zapewnioną opiekę specjalistów do jakości (testerów) na każdym etapie. Model ten, zgodnie z założeniami Agile ma iteracyjny charakter. Dostawy produktu, już z działającym kodem są od razu udostępniane klientowi do wglądu. Krótsze cykle wydawania upraszczają planowanie i zarządzanie ryzykiem.
Istotne jest uzmysłowienie sobie, jak ważna jest współpraca programistów, testerów, administratorów i biznesu, a także - jak, ta zależność, ma wpływ na rozwój oprogramowania.
Zespoły wykorzystujące filozofię DevOps skupiają się na wzmacnianiu ulepszeń w architekturze aplikacji poprzez odpowiedni dobór narzędzi.
Warto wspomnieć również o wzroście zaangażowania pracowników z produktem, a poprzez to z firmą, tworząc środowisko technologiczne o wysokiej wydajności. Powoduje to inny podział odpowiedzialności, wychodzący często poza zakres kompetencji pracowników, gdyż angażują się w dodatkowe fazy cyklu życia produktu.
Korzyści
Jedną z kluczowych korzyści jest możliwość bieżącego decydowania o produkcie, o jego rozwoju i utrzymaniu w zależności od cyklu jego życia. Istnieje możliwość ustabilizowania oprogramowania w przypadku gdy przygotowywana jest duża, nowa funkcjonalność a zespół uzna ją za ryzykowną.
Główną zaletą oprócz elastyczności jest skrócenie czasu tworzenia nowych produktów i sprawniejsze naprawianie błędów w ramach Continuous Testing. Zespoły DevOps stają się bardziej wydajne, dzięki współpracy i produktywności członków zespołu, umożliwiając osiągniecie celów biznesowych, do których można zaliczyć:
- Wejście na rynek w krótszym czasie,
- Elastyczność w dostosowaniu się do wymagań i oczekiwać rynku,
- Zachowanie niezawodności systemu oraz utrzymanie jego stabilności.
Wszystko to przekłada się na zmniejszenie kosztów testowania przy jednoczesnym zwiększeniu jego zasięgu. DevOps umożliwia zminimalizowanie przestojów oraz problemów w czasie wdrażania aplikacji.
Trzy drogi DevOps
W zastosowaniu filozofii DevOps w praktyce nadal istnieją rozbieżności. Proces wdrażania aplikacji i jej rozwoju został zautomatyzowany. Wpłynęło to nie tylko na ulepszenie sposobu wytwarzania oprogramowania, ale także na zmianę kultury biznesowej, dzięki której produkty zaczęły szybciej wchodzić na rynek. Zdarza się, że metodologia DevOps wprowadzana jest dopiero pod koniec cyklu życia produktu lub w momencie napotkania przez firmę problemów wynikających z wydania go na rynek. W niektórych firmach toczona jest stała walka z wdrożeniem DevOps do aktualnej struktury. W celu rozwiązania tych konfliktów można się posłużyć podstawowymi regułami skutecznego użycia DevOps, którymi są:
- Zasady przepływu - zalecenia związane z przepływem pracy pomiędzy poszczególnymi etapami życia wytwarzanego oprogramowania - od wymagań biznesowych aż po wdrożenie, obejmując procesy od developmentu aż do utrzymania; kluczowe elementy:
- Podział pracy z użyciem tablicy Kanban,
- Podział zadań na jak najmniejsze niezależne zadania,
- Skrócenie czasu wydań oprogramowania (od miesięcy do tygodni, dni i godzin),
- Błędy usuwane na bieżąco,
- Ciągła optymalizacja zadań;
- Zasady sprzężenia zwrotnego - stały przepływ informacji zwrotnych, budujący mechanizmy rozwiązywania i zapobiegania problemów od wczesnych etapów;
- Zasady ciągłego uczenia się i eksperymentowania - skupienie zespołu na dynamicznym i naukowym podejściu do podejmowania ryzyka, wyciąganie wniosków z dotychczasowych sukcesów i porażek, które mogą przyczynić się do poprawy działania innych osób w zespole.
CALMS
Co to właściwie jest? Jest to model wspierający menedżerów w ocenie dojrzałości firmy na przyjęcie DevOps.
Wyróżniamy pięć wymagań CALMS dla DevOps, do których należą:
- kultura (ang. culture) - budowana jest wspólna odpowiedzialność za wykonywany produkt w zespole;
- automatyzacja (ang. automation) - członkowie zespołu poszukują różnych sposobów na automatyzację jak największej liczby przeprowadzanych procesów w celu ciągłej dostawy oprogramowania;
- Lean - filozofia wytwarzania produktów, opierająca się na określeniu i tworzeniu wartości dla klienta, ciągłym doskonaleniu procesu poprzez eliminację marnotrawstw oraz okazywaniu szacunku dla zespołu pokazywanego postawą kadry zarządzającej;
- pomiary (ang. measurement) - istnieją narzędzia gromadzące dane i zapewniające ich monitorowanie;
- Udostępnianie (ang. sharing) - komunikacja pomiędzy członkami zespołu jest zachęcająca do stałej współpracy w czasie rozwoju aplikacji oraz w fazie jej utrzymania.
Praktyczny DevOps
Dobre praktyki
Kultura DevOps opiera się na praktykach odnoszących się do całego cyklu życia aplikacji. Usprawniają one określone fazy, bądź je łączą w celu poprawienia produktywności poprzez pomoc zespołom w tworzeniu bezproblemowych procesów.
Ciągła integracja
Wykorzystując metody wywodzące się z Continuous Integration zapewnia ciągłe dostarczanie automatycznie przetestowanego kodu i wdrażanie go w nowych wersjach aplikacji w środowisku produkcyjnym. Poprzez automatyzację kroków wymaganych do wdrożenia, zespoły ograniczają prawdopodobieństwo wystąpienia problemów. Wprowadzenie ciągłej integracji / ciągłego dostarczania przyśpiesza proces wdrażania nowego kodu, zmniejszając ryzyko związane z wrzuceniem kodu z błędami, na produkcję.
Kontrola wersji
Śledzenie poprawek i historii zmian, umożliwia łatwy przegląd kodu oraz odzyskiwanie w każdym momencie. Systemy te oferują prosty sposób scalania zmian w kodzie, które mają miejsce w tych samych plikach, obsługę konfliktów oraz cofanie zmian do poprzednich stanów.
Dzięki tej praktyce łatwiej rozdzielić zadania podczas kodowania między członkami zespołu.
Infrastruktura jako kod
O co tak właściwie chodzi? Otóż infrastruktura jako kod zawiera definicje topologii i zasobów systemowych przedstawionych opisowo. Umożliwia to zespołom zarządzanie zasobami jak kodem, które mogą być wersjonowane w systemach kontroli wersji i podobnie przeglądane oraz wycofywane. Taki sposób wykorzystywania infrastruktury jako kodu pozwala zespołom wdrażać zasoby systemowe w sposób niezawodny, powtarzalny i kontrolowany.
Ciągłe monitorowanie
Dobrą praktyką jest ustawianie alertów z możliwością podejmowania akcji i gromadzenia informacji, które umożliwią uzyskanie szczegółów, które pomagają zespołowi eliminować bieżące problemy.
Agile
DevOps kładzie nacisk na współpracę zespołową, informacje zwrotne od klientów, które dzięki krótkim cyklom wydawania mogą być na bieżąco wprowadzane. Metodyka Agile udostępnia klientom ciągłe zmiany i poprawki. Dzięki temu otrzymują opinię klientów na każdym etapie tworzenia oprogramowania, co powoduje, że mogą się dostosowywać do nowych wymagań.
SysOps vs DevOps
Charakterystyka SysOps
Metoda SysOps zachęca do manualnego zarządzania infrastrukturą IT w firmie. Administratorzy utrzymują i wdrażają technologie nie wymagające wiedzy technicznej a ponadto posiadają znajomość i wiedzę z zakresu infrastruktury klienta. Do ich obowiązków zalicza się także reagowanie na incydenty, czy to dotyczące bezpieczeństwa, czy działania całego systemu.
Którą metodę wybrać?
Metodyka SysOps sprawdza się lepiej w wytwarzaniu oprogramowania o małej infrastrukturze, która nie jest dynamicznie rozwijana i nie potrzebuje być skalowana poziomo. SysOps sprawdza się w administrowaniu do kilku różnych serwerów.
Natomiast DevOps zalecany jest dla dużych środowisk, w których zmiany występują dynamicznie i stale są rozwijane.
W obu przypadkach to administratorzy dopasowują odpowiednie metody do wytwarzanego produktu, przy czym powinni zwrócić uwagę czy infrastruktura może jednak zostać rozwijana. Wybór filozofii działania powinien zostać dokonany na podstawie doświadczenia i umiejętności administratora, wymagań klienta i jego potrzeb.
Podsumowanie
Dzięki DevOps opartemu na Agile i Continuous Delivery wydany produkt ma lepszą jakość ze względu na możliwość reagowania na wskazówki klienta, ale także na zmieniającą się sytuację rynkową. Poprzez współpracę specjalistów z różnych obszarów IT wytworzony produkt otrzymujemy szybciej. Przekłada się to na mniejsze koszty projektu i wdrożenie go w krótszym czasie.
