Poprzednie artykuły cyklu Techniczny Poradnik Product Managera poruszyły zagadnienia ciągłej integracji (ang. continuous integration) oraz ciągłego dostarczania (ang. continuous delivery). Są to praktyki programistyczne, których prawidłowe wdrożenie pozwala nie tylko na usprawnienie codziennej pracy zespołów wytwórczych, ale również dostarcza realnych korzyści product managerom. Obecnie coraz częściej oprócz programistów zatrudnia się również devopsów. Celem dzisiejszego artykułu jest przybliżenie idei kryjącej się za terminem DevOps oraz wyraźne podkreślenie, że zatrudnienie devopsa to jeszcze nie wdrożenie kultury DevOps w organizacji.

Zgodnie z definicją DevOps (ang. DEVelopment and OPerationS) to metodyka (w literaturze zamiennie mówi się tak o kulturze DevOps), zespolenia rozwoju (ang. development) i eksploatacji (ang. operations) oraz zapewnienia jakości (ang. quality assurance) [tworzonego/rozwijanego oprogramowania]. (…) Metodyka ta kładzie nacisk na ścisłą współpracę i komunikację profesjonalistów z zakresu utrzymania IT (administratorów) oraz specjalistów od rozwoju oprogramowania (programistów [i testerów])¹.

Do całkiem niedawna najpopularniejszym “rozkładem sił” w działach IT firm był podział funkcjonalny:

• programiści odpowiedzialni za rozwój oprogramowania,
• testerzy odpowiedzialni za testowanie oprogramowania/zapewnienie jakości (ang. quality assurance/QA),
• administratorzy odpowiedzialni za utrzymanie i rozwój infrastruktury (czyli zakup i utrzymanie serwerów, rozmieszczenie kabli “od Internetu” itp.).

Każda grupa osób siedziała w różnych miejscach biura, a komunikacja pomiędzy nimi była ograniczona do niezbędnego minimum. Takie rozwiązanie mogło się sprawdzać w przypadku wytwarzania oprogramowania z wykorzystaniem modelu kaskadowego, w którym każdy etap procesu był niezależną częścią, rozpoczynającą się dopiero po pełnym zakończeniu etapu poprzedniego. Najpierw programiści pisali kod źródłowy, który następnie był (np. po kilku miesiącach pracy) testowany przez testerów.

Metodyki zwinne a DevOps

Pojawienie się zwinnych metodyk wytwarzania oprogramowania takich jak Scrum zmieniło podejście do pracy w świecie IT. Model kaskadowy i długie następujące po sobie etapy zaczęto zastępować krótkimi iteracjami. Ludzie i interakcje między nimi zaczęto doceniać bardziej niż procesy i narzędzia, a reagowanie na zmiany bardziej niż skrupulatne podążanie za wcześniej ustalonym planem. W metodyce Scrum nie wyróżnia się ról takich jak analityk, tester czy programista. Każdy w zespole odpowiedzialnym za wytwarzanie jest nazwany developerem. Najważniejsze jest to, żeby zespół posiadał zestaw różnych kompetencji (analitycznych, programistycznych, testerskich itp.) niezbędnych do osiągnięcia ustalonego celu.

Terminy takie jak ciągła integracja oraz ciągłe dostarczanie są ściśle powiązane z DevOps. Dlaczego? Ponieważ głównym celem tej metodyki jest stworzenie kultury i środowiska pracy, w którym tworzenie, testowanie oraz publikowanie (oddawanie w ręce użytkownika końcowego na środowisku produkcyjnym) oprogramowania może odbywać się szybciej, częściej oraz bardziej niezawodnie.

DevOps devopsowi nie równy

Tak więc, żeby wdrożyć kulturę DevOps w organizacji nie wystarczy zatrudnić devopsa. Istnieje zbiór narzędzi oraz dobrych praktyk, które wspierają proces wytwarzania oprogramowania na różnych jego etapach, m.in.:

1. Programowanie – przegląd kodu (ang. code review) oraz współdzielone repozytorium kodu (tzw. repo),
2. Testowanie – automatyczne buildy (kroki sprawdzające) na serwerze ciągłej integracji, które uruchamiają testy i informują zespół w przypadku niepowodzenia,
3. Publikowanie – skrypty, które automatycznie publikują nową wersję systemu na środowisku produkcyjnym,
4. Monitorowanie – “obserwowanie” systemu podczas wykorzystania przez końcowych użytkowników i automatyczne informowanie zespołu w przypadku problemów.

Kultura DevOps kładzie duży nacisk na automatyzację wszystkiego co możliwe, co pozwala na wyeliminowanie ludzkich błędów w przypadku wielokrotnego wykonywania powtarzalnych czynności.

Oprócz czasu potrzebnego na wdrożenie praktyk, narzędzi oraz automatyzacji znaczącym wyzwaniem w transformacji w kierunku DevOps jest wypracowanie silnej współpracy pomiędzy rolami, którym z definicji przyświecają odmienne cele:

• programiści chcą wprowadzać zmiany (nowe funkcjonalności),
• testerom zależy na redukcji ryzyka,
• administratorom zależy na stabilności systemów.

Podsumowanie

Dynamiczny wzrost popularności zwinnych metodyk wytwarzania oprogramowania promujących wytwarzanie w krótkich iteracjach oraz częste zbieranie informacji zwrotnej od użytkownika spowodowały narodziny kultury DevOps, której wdrożenie pozwala m.in. na osiągnięcie wartości promowanych przez Agile. Czy warto? Pomimo, że nie jest to trywialna zmiana organizacyjna, którą można wprowadzić z dnia na dzień, osobiście uważam, że warto.

Wdrożenie kultury DevOps nie tylko dostarcza wymiernych korzyści programistom czy działowi IT, ale niejednokrotnie dostarcza korzyści całej organizacji (m.in. poprzez oszczędność pieniędzy), w tym również product managerom. Jak wskazują badania² firmy, które praktykują kulturę DevOps zaobserwowały korzyści takie jak:

• znacznie krótszy czas wprowadzenia produktu na rynek,
• wzrost satysfakcji klientów,
• lepsza jakość produktu,
• bardziej stabilne publikowanie systemów,
• wzrost produktywności i efektywności,
• większa zdolność do budowania produktów spełniających oczekiwania użytkowników dzięki szybkim eksperymentom i zbieraniu informacji zwrotnej.

1. https://pl.wikipedia.org/wiki/DevOps
2. Chen, Lianping (2015). „Continuous Delivery: Huge Benefits, but Challenges Too”. IEEE Software.