Fenomen DEVOPS na ratunek dla skostniałych i niezbyt wydajnych zespołów w IT (programista i administrator w jednym)

Widowiskowe prezentacje na konferencjach to nie tylko takie, które powalają technologią i frapują, że tego tricku architektonicznego jeszcze nie mamy w naszym systemie :-) Są to również sprawy "miękkiej natury ludzkiej", które w branży IT stanowią często niezbędny pomost pomiędzy tymi, którzy potrafią ale im się nie chce a tymi, którzy mogliby więcej bo mogą dać z siebie więcej dla wyższych idei :-)

Jak wiadomo z ciekawej sztuki V jak Vendetta "idea jest niezniszczalna" i w tym wpisie chętnie poruszę temat spraw nie technicznych, które wspierają ludzi technicznych. Idei, które trwają w świecie DevOps :-)

Jak się zaczęło to całe DevOps i gdzie po drodze spotkali się ludzie z IT?

Na początku był Dev a potem pojawił się Ops albo odwrotnie, zależnie od źródeł ... ;-)
Zmierzam do tego, że na początku ery komputerów i informatyki istnieli deweloperzy, którzy stworzyli maszyny, po czym dalej byli zajęci kodowaniem i mieli misje rozwoju oprogramowania. Zabrakło im czasu na utrzymywanie i zarządzanie technicznymi aspektami ich dzieła i pojawił się zawód administratora w informatyce.
Celowo bardzo ten wstęp uprościłem, gdyż te dwie role i do tej pory rozdzielne zawody: programista / developer oraz sysops / ops / administrator za sprawą tzw. chęci stały się jednością:)

"Banalne" założenie – łączymy wysiłki zespołów rozwoju i utrzymania (Development i Operations).

Tak na serio poruszam temat dość niesamowity w branży IT, kiedy dwie popadające w skrajności - tak, nie przesadzam - grupy informatyków o podobnych zainteresowaniach zawodowych ścierały się ze sobą i utrudniały sobie prace a tu nagle ....
Z pomocą przyszedł tzw. Agile wraz z manifestami zwinności w codziennym postępowaniu. Niczym kodeks, który stanowi bazę dla wszelkich czynności zawodowych zjawia się: Agile Manifesto , który wspomógł ideologicznie cały świat IT. 
Istotnie są tacy, którzy się temu nie poddali - jak zwykle "mądrzejsi" - ale nie o nich jest ten wpis. Skupiam się na ludziach, którzy lubią na co dzień ryzykować i eksperymentować, którzy porzucili wygodną strefę komfortu na rzecz zwinności w pracy.

Oto zasady, którymi posługuje się na stale od wielu lat:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się:

• Ludzie i interakcje ponad procesy i narzędzia

• Działające oprogramowanie ponad obszerną dokumentację

• Współpracę z klientem ponad formalne ustalenia

• Reagowanie na zmiany ponad podążanie za planem

Według Manifestu Agile docenia się to, co wymieniono po prawej stronie, jednak bardziej ceni się to, co po lewej (src)

Otóż, naturalnie zainteresowanie programowaniem ze strony administratorów systemów operacyjnych oraz zainteresowanie budową systemu Linux ze strony programistów, czy inżynierów oprogramowania spowodowało falę pozytywnych kreacji. Nie teoretyzuję tutaj, bo widzę na co dzień zadowolonych adminów, software developerów, którzy nazywają siebie DevOpsami.

Nazwałem zjawisko w tytule jako Fenomen DevOps dlatego, że nie znam branży, w której dwa kierunki rozwoju zawodowego spotykają się tak ochoczo i brną we współpracę.
Są widoczne naturalnie pozytywne skutki tego połączenia w wielu organizacjach. Wiele firm z TOP 500 już wdrożyła Agile, SCRUM, czy Lean ew. Kanban i po latach nauki mogą cieszyć się zwinnością w produkcji zmian w swoich produktach.

Co zyskujemy wdrażając w organizacji kulturę DevOps ?

Argumenty poniższe są zapożyczone z praktyki:

• zadowolenie wśród pracowników i brak barier branżowych (dyskusje na różne tematy)
• otwartość i transparentność w działaniach (każdy z każdym współpracuje jak najlepiej potrafi)
• utrzymanie i rozwój produktów przez wiele zwinnych osób (bo im się chce, a nie muszą)
• zespoły produkujące są też utrzymującymi swoje produkty (bo wiedzą o nich wszystko)
• zespoły monitorują swoje wdrożenia i produkty metrykami biznesowymi i technicznymi (wiedzą przed awarią, że zasoby niebawem się skończą i zareagują na automatyczny alarm)
• automatyzują pracę, która jest powtarzalna i monotonna (bo są wygodni i maszyna zrobi to zawsze tak samo, w tym czasie mogą pójść na herbatkę)
• dzielą się ze światem Open Source, bo biorą z niego też niektóre składowe swoich produktów
• pozwalają na krytykę innym ze swojej pracy i dyskutują o tym, wyciągają wnioski (wartościowa cecha ludzka)
• panują nad kodem i wiedzą co zrobić, aby koszt utrzymania nie rósł stale (bo są inżynierami)
• motywują się wzajemnie przez dzielenie pasjami zawodowymi (taki to wesoły świat IT)
• razem z biznesem patrzą sobie na ręce, bo mają metryki i mogą (biznes też się uczy wiele z właściwych metryk n.t. zdarzeń w produkcie)
• robią Hackatony, aby udowodnić sobie i innym, że zabawki zrobione w 24h potrafią zaskakiwać oraz poznają kolegów z innych odległych oddziałów (same atuty)
• drobne zmiany, które można szybko zobaczyć na produkcji są cenniejsze niż 5 m-cy straty
• eksperymentowanie to domena ludzi odważnych (czyli DevOpsów)

Liczby w różnych źródłach mówią o tym fenomenie dość konkretnie.

Z jakimi rozwiązaniami wiąże się DevOps ?

Celowo pozostawiłem nazwy w języku angielskich, bo ozn. bardzo konkretne działania

1. Continuous build - czyli zmiana to uruchomienie procesów budowania świata/środowiska od zera w konkretnym scenriuszu
2. Continuous testing - czyli każda zmiana to uruchomienie testów automatycznych i zbudowanie paczki do wdrożenia lub alert
3. Continuous inspection - przeglądy kodu (Code Review), audyty, zapis historii zmian, autora zmian
4. Continuous integration - jeśli zbudujemy swój projekt, to jeszcze zintegrujmy go z resztą usług - jak zadziałają nie tylko nasze testy ale też innych, to jest bardzo dobrze
5. Continuous delivery - małe przyrosty zmian dające minimalną wartość produktu to cenny każdy dzień w pracy
6. Continuous configuration enforcement - wiem, gdzie przestawić przełączniki mojej aplikacji i wszelkie paramerty. Nie potrzebuję wdrożenia, aby zmienić właściwości i warunki pracy usług. Zawsze inni widzą, co zmieniałem ostatnio i mogą w trakcie awarii odpowiedni szybko zareagować.
7. Continuous deployment - najlepiej kiedy każda zmiana w kodzie, na dowolnym branchu uruchamia procedury testów automatycznych / integracyjnych. Lubimy spać spokojnie.
8. Continuous monitoring - na każdym etapie wytwarzania, testowania, wdrożenia, działania staraj się widzieć metryki a najlepiej podepnij do nich automatyczny system alarmujący w SMS lub dzwoniący. Tak przy każdej zmianie testuj też system alertujący, uratuje to Twój swiat.  
9. Continuous recovery - jeśli nie udało się wdrożenie, rollback to nie problem - wycofujemy i próbujemy dalej
10. Continuous scaling - cóż, w święta większy ruch, to nie problem jeden parametr lub automatyczne skalowanie instancji lub maszyn spowoduje, że wydajność usług nie spadnie

Antywzorzec jaki zauważyłem w rozumieniu DevOps to jest robienie oddzielnych integracji zespołów DEV i odzielne OPS, to czyni świat IT gorszym a ludzi klasyfikuje niepotrzebnie na dewów i adminów. Ludzie nie lubią być sortowani, ale bardzo cenią sobie możliwość poznania zdania innych stron.
Inny problem to zamknięte w sobie i niewspółpracujące typki o dziwnych charakterach - cóż, warto być wyrozumiałym i dać im czas oraz szansę rozwoju. Po jakimś czasie będą bardzo wdzięczni za otworzenie oczu i wytarcie mgły sprzed ich oczu ;-) kiedy zobaczą swój kod na produkcji pod wysokim obciążeniem i kiedy miliony polaków przed swoimi monitorami klika ten "mój guzik" :-)

Jeśli nadal zastanawiasz się, czym jest DevOps i nie wiesz, jak wdrożyć u siebie zapraszam do dyskusji. Chętnie odpowiem o tym, jak ja to rozumiem i poznam też inne punkty widzenia.

Ciągła integracja + testy automatyczne przy pomocy Selenium i Hudson (Jenkins)

Od zawsze programiści marzyli o produkcji oprogramowania bez jego pisania :-)
Niestety o ile programiści dalej sobie marzą o tym,
ich koledzy teserzy, psujący dzieła programistów mają do wyboru automaty do testowania.

Automatyczne testowanie jest jednym z głównych postulatów eXtreme Programming (XP). Automatyzacja polega na użyciu oprogramowania do sterowania wykonaniem testów, porównywania ich wyników z oczekiwanymi, czy raportowania.

W dobie zaawansowania dedykowanych aplikacji internetowych i pozornie prostych w budowie systemów aukcyjnych oraz sklepów interenetowych, wymagania stawiane testerom stale rosną. Od testerów wymaga się podstawowych zdolności programistycznych, zwłaszcza, gdy używa się narzędzi testujących w sposób automatyczny.

Gdyby nie Selenium oraz Hudson / Jenkins testerzy stali by się w sposób naturalny świetnymi programistami. Na szczęście mogą nadal skupiać się na testowaniu jakości i zwracaniu uwagi na dziwne i "na niby bezpieczne" rozwiązania. Poniżej wyjaśnię na czym polega trick ;-)

Wszystko zaczyna się od zmiany podejścia i zastosowania:

• pomysłodawcy funkcjonalności powinni myśleć o optymalnych krokach możliwych do wykonania w produkcji, które można w zrozumiały sposób przetestować - bez budowania wzmocnionych mostów dla testerów, gdy potrzebujemy wykonać funkcjonalnie kładkę :-)
• TDD - programowanie ukierunkowane testami (Test-Driven Development) opierające się na technice automatycznego testowania, zaczynając od testu wynikającego ze specyfiki funkcjonalności, po czym realizowanie małymi krokami funkcjonalności, aby zapewnić poprawne wykonywania testu
• ciągłej integracji - po każdej zmianie, raz na wydanie, ciągle w repozytorium SVN/trunk lub GIT/master wykonywanie testów automatycznych, analizy statycznej kodu oraz wszelkich weryfikacji wykrywających
• reagownie na zmiany i błędy w trakcie procesu tworzenia a nie tylko incydentalnie po wydaniach
• świadome myślenie o lawinowym charakterze strat, gdy błąd który można usunąć w trakcie produkcji znajdzie klient po wydaniu wersji
• automaty służą do testów systemowych i integracji całości systemu a nie tylko, aby sobie budowały w nocy kod tak dla draki; aby ktoś z jakiegośtam działu nie zepsuł pracy kogoś z któregoś tam działu :-)

Tak mi się wydaje, że dopiero po uświadomieniu w drużynie projektowej od biznesu po produkujących kod, dlaczego warto automatyzować testy można przejść do zabawy z Selenium IDE, Selenium RC oraz Hudson ew. Hudson. Cytuje mądrą wypowiedź znawców kontroli jakości:

Ciągła integracja to przede wszystkim sztuka szybkiego przepływu informacji w procesie produkcji. Im szybciej wiemy o problemie, tym więcej czasu i za mniejsze pieniądze zareagujemy. Im później, tym większe ryzyko.

Materiały: http://www.thinkvitamin.com/features/webapps/easy-automated-web-application-testing-with-hudson-and-selenium

http://agilesurfing.pl/2011/programowanie/automatyczne-testowanie-kodu-jak-to-robic/

http://test-driven-development.com/