Transformacja DevOps poprzez rozbudowę możliwości platformy Jenkins.

Poskromienie DevOpsa

• Efektywność zespołów programistycznych to ich zdolność dostarczania w sposób ciągły kodu wysokiej jakości.
• Jakie sposoby stosuje się w DEV, aby tę zdolność szybkiego dostarczania jakościowego kodu zwiększyć? Co decyduje o tym, że zespoły programistyczne tę zdolność osiągają?
• Odpowiedzi na te pytania szukaliśmy w trakcie spotkania online „Transformacja DevOps poprzez rozbudowę możliwości platformy Jenkins” z udziałem ekspertów ze społeczności CIONET.

Zdaniem Bartosza Niwińskiego, szefa CloudBees w Polsce, zawsze doceniano w tym zakresie znaczenie kompetencji i przekładającej się na innowacje pomysłowości programistów. Firmy, które zbudowały efektywne zespoły programistyczne, dwa razy częściej niż zwykle osiągają swoje cele, komercyjne i niekomercyjne.

Od kilku lat rośnie także świadomość wagi zorganizowania samych procesów budowy i dostarczania kodu. Efektywny development aplikacji staje się coraz ważniejszy dla biznesu, dlatego wiele organizacji zaczęło wykorzystywać zwinne metodyki wytwarzania.

To jednak nie wystarcza. Konieczne jest odpowiednie ułożenie procesów w całym cyklu wdrożeniowym oprogramowania, aby przebiegał on w sposób powtarzalny i kontrolowalny. Do tego konieczne jest wykorzystanie specjalistycznych narzędzi, jakimi są aplikacje z kategorii Continuous Integration and Continuous Delivery (CI/CD).

Wśród nich olbrzymią popularność zdobył opensource’owy Jenkins, który pozwala zautomatyzować dużą część czynności składających się na cały proces dostarczania oprogramowania. Zespoły programistyczne zostają uwolnione od niektórych zadań, ale co równie ważne szybko dostają z Jenkinsa informacje zwrotne o jakości samego kodu.

Jenkins w praktyce

Od 2017 roku z Jenkinsa korzystają spółki Philip Morris International, koncern tytoniowy który przechodzi złożoną transformację, w tym cyfrową. Obejmuje ona nie tylko jak w wielu firmach ucyfrowienie procesów biznesowych, ale także szybką digitalizację produktów, bo wizją firmy jest zastąpienie tradycyjnych papierosów przez urządzenia do podgrzewania tytoniu, które do pracy wymagają oprogramowania, odpowiadającego ścisłym rygorom.

Piotr Musiał zarządzający IT DevOps w PMI Service Center Europe (spółki PMI)  przyznaje, że początkowo po Jenkinsa z własnej inicjatywy sięgały niektóre zespoły developerskie, korzystając z jego darmowej dystrybucji. Jenkins znalazł wtedy zastosowanie jako narzędzie do orkiestracji wdrożonych wcześniej aplikacji CI/CD, wykorzystywanych głównie w zakresie testowania kodu i wdrażania oprogramowania. Szybko okazało się, że Jenkins pozwala kontrolować pełny proces produkcji i wdrażania software’u, co podnosi nie tylko jego jakość, ale także bezpieczeństwo poprzez ustandaryzowanie i uwspólnienie zasobów i metod pracy.

Ciemna strona Jenkinsa

Darmowa dystrybucja Jenkinsa ma jednak pewne ograniczenia, które uwidaczniają się, gdy zaczyna się go stosować na dużą skalę. W przypadku firmy takiej jak PMI, z licznymi i geograficznie rozproszonymi zespołami developerskimi, niedostatki Jenkinsa były widoczne na poziomie zarządzania, poszczególne zespoły musiały kontrolować odrębne projekty, co wprawdzie podnosi ich jakość, ale może prowadzić do chaosu na poziomie całego działu DevOps.

Co istotne, podobne sytuacje nie należą do wyjątków. Jenkins w pierwotnych założeniach miał zaspokajać potrzeby automatyzacyjne pojedynczego zespołu programistycznego. W małym środowisku nawet wersja open source zapewnia pełne spektrum możliwości, ale sprawa komplikuje się przy stosowaniu narzędzia w większych organizacjach z licznymi zespołami, gdzie potrzeby rosną wraz z upływem czasu.

A to może prowadzić do pewnych patologii procesu tworzenia oprogramowania. Albo powstają „wyspy Jenkinsa”, gdy jeden serwer narzędzia przypada na jeden zespół, albo w organizacji funkcjonuje, jak określa to Bartosz Niwiński, „Jenkinstein” – pojedyncza duża instancja obudowana stosem wtyczek. W pierwszym przypadku mamy do czynienia z poważnym problemem administracyjnym, bo w takim rozproszeniu trudniej o standaryzację; w drugim cały uzysk wynikający z łatwego zarządzania zjada niższa stabilność i wydajność.

W PMI zaczęto więc rozglądać się za rozwiązaniem, które umożliwiłoby centralizację zasobów związanych z Jenkinsem i usprawnienie procesów zarządzania narzędziem. Jak się okazało, nie trzeba było go daleko szukać – podjęto decyzję o wdrożeniu komercyjnej wersji platformy, dostarczanej przez CloudBees.

„Enterprise” na pomoc

CloudBees już teraz jest, jako firma, największym kontrybutorem w społeczności Jenkinsa – jak mówił Bartosz Niwiński, ok. 80% kodu open source’owego Jenkinsa jest stworzone przez programistów CloudBees. Wersja komercyjna narzędzia powstała jednak w odpowiedzi na wskazane wcześniej wyzwania pojawiające się w organizacjach stosujących Jenkinsa na większą skalę.

Piotr Musiał nazywa to podejściem „master of master”. W praktyce administrator Jenkinsa – a w PMI zajmuje się tym obecnie jedna (!) osoba – z poziomu nadrzędnego „centrum operacyjnego”, działającego we własnym kontenerze, może kontrolować wszystkie aspekty funkcjonowania platformy i jednocześnie zarządzać istniejącymi instancjami Jenkinsa, zebranymi w drugim kontenerze. W przyszłości każdy nowy serwer Jenkinsa może otrzymać własny kontener. To szczególnie istotne jeśli firmy zamierzają przenosić całe infrastruktury aplikacyjnej do chmury obliczeniowej.

Jako taki, wariant enterprise nie jest przeznaczony dla każdego – jego wdrożenia wynikają z różnych, ale zawsze bardzo konkretnych biznes case’ów związanych z bezpieczeństwem, wydajnością czy skalowalnością środowiska IT danej organizacji. Wersja enterprise „wymusza” pewne dobre praktyki standaryzacji, by wiele zespołów deweloperskich w sensie procesowym mówiło tym samym językiem – podkreślał Niwiński.

Z kolei aspekt bezpieczeństwa dotyka na przykład ekosystemu wtyczek i rozszerzeń – mnogość dostępnych plug-inów zapewnia szerokie możliwości rozbudowy Jenkinsa, co jest ogromną zaletą platformy a jednocześnie jej wadą, jeżeli zespoły korzystają z wtyczek w sposób niekontrolowany lub w użyciu pozostają dodatki niesprawdzone, przestarzałe albo już nierozwijane. CloudBees wtyczki do Jenkinsa testuje, a sporo z nich certyfikuje. W ten sposób klient platformy uzyskuje wiarygodne informacje z pierwszej ręki o przydatności rozszerzenia.