Pierwszą grupą są te stworzone specjalnie z myślą o wprowadzeniu większej automatyzacji i ciągłości. Te „gotowce”, jak nazywa je Wurster, są najlepsze w niwelowaniu negatywnych reakcji na zmiany kultury IT powodowane przez DevOps.

Drugi fragment łańcucha to narzędzia, które do DevOps zostały dostosowane. Służą one głównie do integracji zespołów oraz automatyzacji testów. Mimo że na rynku funkcjonują już od dłuższego czasu, to są idealne do wytworzenia poczucia głębszej współpracy pomiędzy programistami i administratorami.

Zobacz również:

• Najpopularniejsze stanowiska pracy w chmurze obliczeniowej
• Premiera GitHub Copilot Enterprise

Ostatnie z tych narzędzi to te, które można łatwo wykorzystać do wspierania modelu DevOps, takie jak: nadzorowanie produkcji, testowanie zabezpieczeń czy narzędzia do zarządzania komputerami. Są one głównie wykorzystywane do istotnych, ale nie naglących zadań.

W Nationwide DeArdo skomponował taki zespół narzędzi składający się z IBM UrbanCode (płynny przesył danych), IBM Rational (platforma do tworzenia oprogramowania), Jenkins (do ciągłej integracji powstałego kodu) oraz Tasktop, które służy do łączenia wszystkich elementów.

DeArdo uważa jednak, że nawet tak dobrze działający zespół narzędzi jak w Nationwide nie pomoże, gdy „nie znamy pewnych standardowych działań czy procesów. Jeśli sposoby pracy są zbyt rozbieżne, to te narzędzia na nic się nie zdadzą”. Przed przyjęciem płynności oferowanej przez DevOps firmy IT muszą się dokładnie zastanowić, jakie narzędzia będą potrzebne w trakcie produkcji, jakie metody wprowadzą największe zmiany w ich działaniu oraz jak inne technologie wpłyną na pracę przy użyciu tego modelu.

Bez pośpiechu

Jak zawsze przy tak ogromnych przemianach w IT trzeba pamiętać, że najlepszym sposobem jest spokojne i stopniowe wdrażanie zmian. Po latach spędzonych w odizolowaniu od innych oraz na powolnym wydawaniu oprogramowania koncepcja ciągłego dostarczania nowych produktów może odstraszać liderów IT. DevOps nie jest czymś, co można wprowadzić w mgnieniu oka. Gruver ostrzega, że „nie jest możliwe zrobienie wszystkiego na raz, podobnie jak trudno jest te zmiany dokładnie rozplanować. Trzeba wyznaczyć cele na najbliższą przyszłość, a potem dostosowywać następne kroki do postępu”.

Również nie powinno się oczekiwać, że nasze środowisko DevOps będzie identyczne jak inne. W przeciwieństwie do bardziej sztywnego ITIL DevOps jest modelem elastycznym oraz otwartym na interpretacje, przez co ciągle się zmienia.

„Wprowadzenie DevOps nie jest szablonowym procesem, który dla każdego działa tak samo” – dopowiada Forsgren. Jednakże potwierdza ona, że pomimo trudności w postaci ustalenia nowych procedur w produkcji oprogramowania oraz zmiany panujących zwyczajów w branży IT, to praca z użyciem DevOps jest „oszałamiająco efektywna”.