IT@BANK. Technologie – ESKOM IT sp. z o.o: Rozwiązania zwinne – sprawne i szybkie opracowywanie produktu

Tradycyjna metodyka pracy

Do czasu „nastania” epoki DevOps i metodologii agile (o której dalej) zespoły pracujące nad produktem działały oddzielnie i komunikacja pomiędzy nimi była ograniczona. Programiści tworzyli kody źródłowe, testerzy testowali oprogramowanie i dbali o jego jakość, zaś administratorzy zajmowali się utrzymaniem i rozwojem infrastruktury. Model ten spełniał swoje zadanie, gdy projekt był podzielony na dłuższe etapy, a po zakończeniu każdego z nich produktem zajmował się kolejny zespół.

Tradycyjna metodyka pracy nad tworzeniem oprogramowania zakładała trwający nieraz latami proces rozpoczynający się od zbierania wymagań, przez analizę, projektowanie, developement i testy, aż po wdrożenie. Rzecz w tym, że w trakcie prac wymagania klienta mogły się zmienić, podobnie jak sytuacja rynkowa.

Długi proces tworzenia oprogramowania uniemożliwiał finalnemu odbiorcy dokonywanie oceny produktu na bieżąco i zgłaszania swoich uwag. Uwagi pojawiały się dopiero po zakończeniu całego procesu, kiedy ich wprowadzenie było już bardzo trudne, a czasem nawet niemożliwe. Jednocześnie klient nie zawsze potrafił precyzyjnie określić swoje oczekiwania na początku projektu i gdy odbierał produkt, często okazywało się, że wyobrażał go sobie zupełnie inaczej.

Zwinne wytwarzanie

Zmiany zaczęły zachodzić wraz z upowszechnieniem się zwinnych metodyk wytwarzania oprogramowania. Jest to nic innego jak niezwykle popularny obecnie agile. Jego „zwinność” polega na dostosowaniu sposobu pracy nad produktem do wymagań dynamicznie zmieniającej się rzeczywistości.

Podstawową cechą metodyki agile jest podział pracy na iteracje, czyli krótsze etapy, których efekt prezentowany jest klientowi. Jeśli zgłosi on swoje uwagi, praca jest powtarzana, aż do osiągnięcia wymaganego efektu. Sprawia to, że ostateczny produkt nie rozmija się z oczekiwaniami klienta (a także pozwala mu modyfikować pierwotne wymagania) i będzie można go na bieżąco dostosowywać do realiów rynku.

DevOps w praktyce

DevOps, którego filozofia wywodzi się ze zwinnych metodologii pracy nad projektami, oznacza ścisłą współpracę pomiędzy developerami (Dev) a specjalistami odpowiedzialnymi za eksploatację oprogramowania (Ops). Oznacza to nacisk na komunikacją pomiędzy zespołami, która ma służyć optymalizacji zarówno kodu, jak i utrzymania produktu. Ponadto, zgodnie z agile, zespoły DevOps ściśle współpracują także z klientem, aby reagować na jego potrzeby i wymagania.

Jedną z cech metodologii DevOps jest automatyzacja. Na przykład, aby odciążyć programistów oraz administratorów, wykorzystywane są narzędzia przeprowadzające testy kodu, publikujące nowe wersje aplikacji, monitorujące kod na bieżąco, tworzące kopie zapasowe itd. – wszystko po to, aby zmniejszyć ilości ewentualnych błędów, które mogliby popełnić członkowie zespołu. Niewątpliwie automatyzacja ma również bezpośredni wpływ na szybkość wdrażania nowych zmian.

Co zyska IT, a przede wszystkim biznes, wdrażając DevOps?

1) Efektywna współpraca między działami programistów, operacji i wsparcia. Wprowadzanie częstych zmian w oprogramowaniu, przy ograniczonych zwykle możliwościach czasowych, z założenia wymaga efektywnej współpracy. DevOps spełnia tu rolę stymulatora, wpływając zarówno na innowacyjność, jak i na przyspieszenie samego procesu.

2) Automatyzacja procesów. Dzięki niej poszczególne zadania realizowane są dużo szybciej. Konieczność pisania nowych skryptów i zarządzanie nimi stają się łatwiejsze, co oznacza oszczędność zarówno czasu, jak i środków finansowych.

3) Wczesne wykrywanie błędów. Dzięki automatycznym testom błędy wykrywane są nie tylko bardzo szybko, ale także bardzo wcześnie, bo już na etapie powstawania produktu, zaś wszelkie konieczne modyfikacje wykonywane są na bieżąco.

4) Oszczędność czasu. Wspomniane wyżej błędy, wykryte już na etapie powstawania produktu, są zwykle łatwiejsze do usunięcia. Współpraca między działami i zwiększenie poczucia odpowiedzialności u każdego z pracowników wpływają z kolei na jakość produktu końcowego i zminimalizowanie konieczności jego poprawiania.

5) Zmniejszenie kosztów. Oczywistym następstwem efektywnej współpracy pomiędzy działami programistów, operacji i wsparcia jest nie tylko oszczędność czasu, ale i pieniędzy. DevOps zmniejsza koszty testowania i skraca czas potrzebny na naprawę błędów. Zapobiega także kosztownym przestojom oraz minimalizuje problemy związane z wprowadzaniem produktu na rynek.

6) Maksymalne podnoszenie jakości. Dzięki szybkiej informacji zwrotnej (automatyczne testy) i ścisłej współpracy, powstający produkt od samego początku jest dokładnie monitorowany i w miarę potrzeby poprawiany. Wcześnie wykryte błędy i wprowadzanie na bieżąco koniecznych zmian sprawiają, że cały proces – od pomysłu, aż do wdrożenia – przebiega bardziej płynnie, a jakość produktu końcowego jest maksymalnie wysoka.

7) Przyspieszenie wdrożenia. Kwestie wymienione w punkcie 6, a w szczególności wprowadzane na bieżąco modyfikacje sprawiają, że cały proces zostaje wyraźnie skrócony, a wolny od błędów produkt może zostać wdrożony znacznie szybciej. Według „State of DevOps Report 2018”, przygotowanego przez firmy Puppet i Dora, wynika, że przedsiębiorstwa działające w metodologii DevOps wdrażają nowy kod 46 razy częściej, a czas przestojów może trwać np. godzinę w porównaniu do miesiąca lub więcej w firmach, które dopiero DevOps wprowadzają.

8) Zmiana mentalności pracowników. Do powstania metodyki DevOps w dużym stopniu przyczyniły się brak kooperacji i skoordynowania działów programistów, operacji i wsparcia. DevOps ma w założeniu stymulować współpracę, a jednocześnie wpływać na innowacyjność. Czy wymaga wobec tego zmiany mentalności wśród pracowników? Jak najbardziej. Czy jest to możliwe? Doświadczenie pokazuje, że tak. Czy jest to korzystne? Zawsze.