DevOps od podszewki, czyli jak to działa?

DevOps, dlaczego to się opłaca?

Jesteśmy nie tylko praktykami, ale również entuzjastami powyższego podejścia do DevOps. Gdy rekomendujemy je klientom, często przychodzi nam jednak zacząć od podstaw, czyli od tłumaczenia, na czym właściwie ta metoda polega. O co chodzi z połączeniem developmentu i supportu w jednym zespole i równoległą pracą nad obydwoma obszarami?

O tym, jak wygląda DevOps od podszewki – za chwilę. Wcześniej jeszcze o tym, czemu to służy i jaki jest cel. Moim zdaniem, to aspekt nie mniej istotny niż zaplecze technologiczne, a odpowiedź jest znacznie bardziej oczywista, niż mogłoby się wydawać. DevOps zwiększa wydajność zespołu i pomaga nam rozwiązać odwieczny problem, z którym spotykamy się w projektach IT: zależność produkcji od nowych releasów. Przy sprawnie działającym procesie uwalniamy produkcję, bo nie czekamy z naprawą incydentów, aż skończą się prace nad nowymi funkcjonalnościami. Jeśli pojawiają się zgłoszenia, reagujemy i naprawiamy na bieżąco.

Jest to możliwe dzięki wykorzystaniu repozytorium kodu oraz Continuous Integration. Pozwala to tak zarządzać udostępnianiem kolejnych funkcjonalności, aby zminimalizować pracę ręczną, a w efekcie – ryzyko błędów oraz różnic między środowiskami. Każdy kto ma doświadczenie w pracy w projekcie IT wie, jak ta praca często wygląda: różne środowiska, wprowadzanie zmian, które jednak nie są widoczne w kolejnym środowisku, bo po drodze coś zginęło.

Gdy projekt prowadzony jest zgodnie z Continuous Integration, nie musimy czekać, aż developer wrzuci coś na serwer – od tego są narzędzia (np. serwer Jenkins). Automatyzacja daje nam ciągłość działań i pełną kontrolę nad projektem.

Brzmi to bardzo technicznie. Czy w takim razie benefity z wdrożenia DevOps odczuwają tylko programiści i administratorzy? Nie, i to również podkreślamy podczas rozmów z klientami: korzyści są widoczne także dla biznesu. Gdy przedstawiamy klientowi założenia pracy w modelu DevOps, dajemy jasny komunikat: w IT jesteśmy elastyczni, nie tworzymy sztucznych barier ani reguł pracy, zakazów i nakazów w rodzaju: ”To musi poczekać, nie możemy tego zrobić, bo zajmujemy się czymś innym”. DevOps usuwa blokady, zapewnia płynność pracy i szybkie reagowanie. Zwiększa przejrzystość i transparentność – klient wie, nad czym zespół aktualnie pracuje. Korzyści z wdrożenia DevOps to obszerny temat – wrócę do niego w kolejnych artykułach.

DevOps w praktyce krok po kroku

Co oznacza dla nas DevOps w praktyce? Jak pracują craftwarowe zespoły zespoły DevOps? Omówię kluczowe aspekty technologiczne pracy w tym podejściu.

• Kontrola wersji

Rzecz teoretycznie oczywista w projektach, ale niestety nie aż tak oczywiste w Salesforce. W Craftware przyjmujemy zasadę: nie ma repozytorium – nie ma kontroli. Idąc dalej – bez repozytorium nie ma DevOps. Praca z repozytorium to fundament tego podejścia.

Istotnym elementem kontroli wersji jest również zasada przynajmniej jednej akceptacji. Co to oznacza? Gdy w projekcie pracuje więcej niż jeden programista, rekomendujemy wzajemne sprawdzanie zmian w kodzie przed wprowadzeniem go do repozytorium. Im bardziej rozbudowany system akceptacji, tym lepiej.

Zalecamy także włączenie dodatkowego etapu akceptacji – uruchomienie testów jednostkowych przed umieszczeniem kodu w repozytorium, przynajmniej na etapie środowiska integracyjnego i późniejszych.

• GIT Flow

To rekomendowany przez nas sposób pracy z repozytorium kodu, czyli droga, jaką przechodzi kod, zanim trafi na produkcję.
Wyjaśnia to poniższa grafika. Gałąź Master odzwierciedla produkcję, gałąź Develop – kod do nowego releasu. Jak widać, po kolejnych zmianach na poziomie Develop nie następuje bezpośrednie wypuszczenie kodu na produkcję – wcześniej przejdzie on przez poziom release.

Obraz – GIT Flow

• Sandbox hierarchy oraz Continuous Integration

To nic innego, jak kolejność etapów testowania kodu z uwzględnieniem standardów Continuous Integration. Sandbox, czyli piaskownica w terminologii Salesforce, oznacza środowisko testowe. Warto podkreślić, że w Salesforce stworzenie takiego środowiska jest o wiele łatwiejsze niż w innych technologiach. Kopię produkcji można wyklikać w kilka minut.

Proponowany przez nas schemat testów dla bardziej skomplikowanych instancji Salesforce przedstawia poniższa grafika.

Obraz – Sandbox hierarchy

Jak widać, w przypadku kilku równoległych projektów każdy ma własne środowisko testowe. Środowisko pod nazwą Integration jest pierwszym, w którym możemy wykryć błędy, konkretnie – negatywny wpływ błędu w jednym z projektów na pozostałe.

Środowisko Integration ma charakter roboczy, nie jest polecane do oficjalnych testów, ponieważ zmian w projektach może być wiele, nawet w ciągu jednego dnia. Dopiero po stabilizacji w tym roboczym środowisku udostępnia się wersję do kolejnego etapu testów – do tego etapu często zaprasza się również biznes.

Zwracam uwagę na środowisko Hotfix. Jaka jest jego rola? Przygotowanie nowego release może trwać miesiące. Nie ma gwarancji, że w tym czasie nie pojawi się błąd na produkcji. Dzięki środowisku Hotfix można taką usterkę skutecznie i bezpiecznie naprawić, nie czekając na nową funkcjonalność – znajduje się tam kod produkcyjny (ale nie ma releases), można więc tu bez ryzyka przetestować poprawioną wersję.

Nie bez powodu podkreślamy znaczenie Continuous Integration na każdym etapie testów – im bardziej skomplikowany projekt, tym większa rola CI. Mówimy przecież o wielu przejściach kodu między środowiskami, o licznych zmianach w każdym ze środowisk – bywa ich wiele w ciągu dnia. Automatyzacja procesów jest w tej sytuacji istotnym ułatwieniem.

• Release management goals, czyli świadome podejście do releasów

W podejściu DevOps to bardzo ważny aspekt. Nowy release w projekcie IT nie wydarza się codziennie – i o tym trzeba pamiętać. Bez względu na to, czy nastąpi on za 3 tygodnie czy za 3 miesiące – oczekiwanie na niego nie może wstrzymywać poprawek na produkcji. Powtarzam to kolejny raz (i zapewne nie ostatni), ale to istota DevOps: development i support nie wykluczają się, można i trzeba prowadzić je w tym samym czasie!

Oczywiście, trzeba mieć pewność, że to, co weszło na produkcję, zostało odpowiednio przetestowane i działa bez zarzutu. Właściwe skonfigurowanie procesu Continuous Integration eliminuje większość związanych z tym problemów. I ten najczęstszy, z którym borykają się programiści: że na produkcji znalazł się stary kod.

Takie zdroworozsądkowe podejście ma wpływ na pracę zespołu – pozwala efektywnie zarządzać zasobami. Przygotowanie kolejnych funkcjonalności nie jest jednakowo czasochłonne, konkretny release wymaga więcej pracy, ale następny już mniej. Można więc zaplanować pracę ze sporym wyprzedzeniem, w kontekście urlopów czy wakacji.

• Testy automatyczne

Testy automatyczne mogą wydawać się kosztowne i nieopłacalne. I faktycznie, na początku nie widać dużych korzyści z ich przeprowadzania. Ale im bardziej rozbudowuje się system, tym bardziej się przydają.

Dla przykładu: w systemie jest kilka podstawowych ścieżek, po których porusza się użytkownik. Napisanie testu automatycznego zajmie prawdopodobnie sporo czasu, a gdy system nie będzie rozwijany, to ten czas być może się nie zwróci. Ale jeśli do systemu będą regularnie dodawane nowe funkcjonalności, zainwestowany w napisanie testów czas, zwraca się po wielokroć.

Znaczenie testów automatycznych widać zwłaszcza w kontekście testów regresji. Często zakładamy, że jeśli zmieniamy tylko pewien fragment kodu, nie wpłynie to na błąd w innej części programu – a przecież praktyka dowodzi, że nie jesteśmy w stanie tego przewidzieć. Dzięki uruchomieniu testów automatycznych można zweryfikować większy zakres kodu, oszczędzając na pracy testerów manualnych – co znacząco wpływa na skrócenie time to market.

Podsumowanie

Wdrożenie DevOps w projektach Salesforce wcale nie musi być trudne. Czasem najtrudniej jest zacząć, co wymaga po prostu zmiany nastawienia do prowadzenia projektu. Nasi klienci, podążając za naszymi rekomendacjami, coraz częściej przekonują się do tego podejścia, widząc w nim realne, również biznesowe, korzyści.