Framework CALMS

Mimo, że nie ma powszechnie przyjętego modelu / metodyki wdrażania podejścia DevOps w organizacjach, to jednak bardzo często wiąże się to podejście z akronimem CALMS, który został wymyślony przez Jeza Humble'a, współautora książki „The DevOps Handbook” i oznacza kulturę (Culture), automatyzację (Automation), Lean, pomiar (Measure) i współpracę (Sharing).

Miary i metryki DevOps

Rola framework'u CALMS we wdrażaniu DevOps

 

Czym jest framework? To pewne ramy postępowania w określonej dziedzinie. Nie jest to szczegółowa metodyka czy też metoda (innymi słowy nie jest to "książka kucharska"). Framework podpowiada CO zrobić, często nie wchodząc w szczegóły JAK to zrobić.

W części materiałów poświęconych DevOps CALMS określany jest również terminem "model", jeszcze inni określają akronim CALMS pryncypiami lub filarami.

 

Rozszyfrowujemy CALMS

 

Krótka historia

Pierwszy akronim – CAMS (Culture, Automation, Measurement, Sharing) został ukuty przez Johna Willisa i Damona Edwardsa w 2010 roku podczas pierwszego amerykańskiego DevOpsDays w Mountain View w Kalifornii. Literę „L” (Lean) do istniejącego akronimu dodał Jez Humble.

 

Poniżej rozszyfrowujemy każdą z liter.

 

C - jak Culture (Kultura)

Wprowadzenie DevOps do organizacji często wiąże się ze zmianą sposobu myślenia i działania o wytwarzaniu, dostarczeniu i utrzymaniu oprogramowania. DevOps bazuje przede wszystkim na ścisłej współpracy ludzi zaangażowanych w szeroko rozumiane IT. Proszę pomyśleć o tym, że IT jest swego rodzaju fabryką, która nie tylko dostarcza określone produkty, ale również je serwisuje. Będzie to niemożliwe - bez ścisłego współdziałania osób za rozwój i utrzymanie.

 

A - jak Automate (Automatyzacja)

W DevOps automatyzujemy wszystkie możliwe elementy wytwarzania oprogramowania, na wszystkich możliwych etapach jego życia. To pozwala zminimalizować rzeczy, które są czasochłonne, ale dostarczają niską wartość. Automatyzacja przekłada się także na wzrost jakości dostarczanego oprogramowania i przynosi korzyści z perspektywy trackowania (śladowania) zmian. Firmy zwykle wdrażają automatyzację etapami - zaczynając od ciągłej integracji i dostarczania, a następnie dochodząc do ciągłych wdrożeń.

 

L - jak Lean (Lean)

Z podejścia Lean DevOps czerpie przede wszystkim dwie rzeczy. Przede wszystkim jest to eliminowanie działań o niskiej wartości. Drugim elementem jest ciągłe doskonalenie i uczenia się na błędach.

Zespoły wytwórcze są (mentalnie, proceduralnie i narzędziowo) gotowe biorą pod uwagę, że w pewnym momencie pojawią się problemy, więc w momencie ich

pojawienia się koncentrują się na ich szybkiej diagnozie i przywrócenie oprogramowania do pracy. Po tym realizowana jest analiza post-mortem, która

koncentruje się na elementach, które nie zadziałały oraz ich udoskonaleniu.

 

M - jak Measure (Pomiar)

Zgodnie z zasadą - nie mierzysz, nie zarządzasz (i nie udoskonalasz) DevOps zakłada mierzenie (w możliwie zautomatyzowany sposób) różnych aspektów wytwarzania i utrzymania oprogramowania. O metrykach oprogramowania i ich znaczeniu w DevOps przygotowaliśmy dodatkowy cały artykuł.

 

S - jak Sharing (Współpraca)

Sednem DevOps jest założenie, że osoby, które tworzą oprogramowanie, powinny być jednocześnie zaangażowane w jego wydawanie i utrzymywanie. Nie oznacza to, że od razu wszyscy muszą tak pracować. W wersji minimalnej programiści i administratorzy blisko współpracują na każdym etapie cyklu życia oprogramowania. Docelowo można przejść do rotacji ról. Oznacza to, że programiści usuwają problemy wychwycone przez użytkowników końcowych i rozwiązują problemy produkcyjne. Natomiast administratorzy są zaangażowani np. w spotkania dotyczące rozwoju oprogramowania (przy okazji dostarczają oni całkiem nowego spojrzenia na funkcjonalności rozwijanych narzędzi). 

 

Poza CALMS

 

Okazuje się, że obecnie część osób zajmujących się DevOps myśli o rozwinięciu framework'u CALMS. Na przykład proponuje się, aby do CALMS dołożyć architekturę – w ten sposób powstał akronim CALMAS. Innym pomysłem jest dodanie „S” na końcu (w ten sposób powstaje CALMSS). To drugie „S” oznacza strukturę (organizacyjną) niezbędną do wdrożenia DevOps.

 

Podsumowanie

 

Należy mieć przede wszystkim świadomość, że DevOps (tak jak Agile) oznacza pewien styl myślenia, podejście do pracy, zestaw wartości. Jego wdrożenia - zwłaszcza w warunkach polskich jest bardzo trudne.

Dlaczego? Bo z jednej strony mamy - jako Polacy - wbudowany w ganach uniwersalizm, ale jednocześnie bardzo jesteśmy zamknięci na współpracę. Jednocześnie, wraz ze zmieniającą się rolą IT w organizacji (IT to nie źródło kosztów, to dostarczenie przewagi konkurencyjnej) nie ma w wielu firmach / branżach odwrotu od tego sposobu pracy.

Daj znać

Co sądzisz o naszym artykule? Czy powinniśmy coś w nim zmienić? Rozszerzyć go?