Pojęcie DevOps kryje za sobą wiele różnych ról i praktyk, które nie sposób opisać jednym zdaniem. Na temat pracy z DevOps, jej charakterystyce oraz drodze do zostania DevOps Engineerem rozmawialiśmy z Aleksandrem Czarnołęskim i Michałem Piotrowiczem z Sollers Consulting.
Co oznacza i jaka jest rola DevOps na projektach?
Aleksander: To wszystko zależy od tego, jak definiujemy DevOpsa. Najczęściej spotykamy się z rolą DevOps Engineera, którego celem jest automatyzacja procesu wytwórczego oprogramowania. I to jest częściowo zgodne z całym podejściem DevOpsowym, ale pomija bardzo istotny aspekt kulturowy i organizacji procesów – źle zaprojektowany proces manualny, po automatyzacji będzie źle zaprojektowanym procesem automatycznym.
DevOps jest bardzo szerokim pojęciem, pod które można podpiąć wiele praktyk – zwykle sprowadzam je do następującej definicji: optymalizacja procesu wytwarzania i dostarczania systemu poprzez zapewnienie odpowiedniej kultury organizacyjnej, procesów i, na samym końcu, narzędzi.
Biorąc pod uwagę postrzeganie rynkowe oraz nasze doświadczenie z podejściem DevOps, najczęściej wyróżniamy dwa typy projektów:
- Jeżeli działamy na pojedynczym projekcie u naszego klienta i nie mamy większego wpływu na działanie całej organizacji, skupiamy się na zbudowaniu jak najwyższego poziomu dojrzałości i automatyzacji procesu wytwórczego na poziomie projektu. Polega to na optymalizacji i automatyzacji procesu wytwarzania i dostarczania oprogramowania, jak również na budowaniu odpowiedniej świadomości u klienta na temat praktych DevOpsowych, takich jak bliska kooperacja zespołów developerskich z biznesem, wczesnego testowania, zwiększania umocowania (empowerment) zespołu do podejmowania decyzji, zapewniania zespołowi narzędzi do tworzenia rozwiązania end-to-end, itd.
- W przypadku projektów, których celem jest zmiana organizacji po stronie klienta, mamy zdecydowanie większy wpływ na postawienie odpowiednich fundamentów prawidłowej kultury organizacyjnej i zaprojektowania procesów na poziomie całej firmy. Staramy się wtedy znaleźć złoty środek pomiędzy zapewnianiu zespołom odpowiednich narzędzi i swobody tworzenia, jak również wprowadzania pewnych ram, które pozwalają utrzymać spójne podejście technologiczne i wspomagają re-używanie przygotowanych rozwiązań oraz utrzymanie spójności wytwórczej na poziomie całej organizacji.
