Po dłuższej nieobecności wracamy do was z kolejnym postem edukacyjnym. Przeglądając strony branżowe, śledząc hashtagi na twitterze i dopuszczając się innych aktywności w social mediach, temat DevOps w środowisku IT nie mógł pozostać dłużej nieopisany.
O DevOps wspomnieliśmy już trochę w naszym majowym wpisie Co dalej z Agile?, gdzie wymienialiśmy tę metodę w gronie alternatywny dla metodyk zwinnych. Tematu nie wyczerpaliśmy, dlatego postanowiliśmy poświęcić oddzielny post zagadnieniu DevOps. Czy teraz wyczerpiemy temat? Z pewnością nie, bo DevOps cały czas się zmienia i ewoluuje. Postaramy się jednak choć trochę przybliżyć samo zjawisko i jego cechy.
Gotowi na piątkową dawkę wiedzy?
O DevOps słów kilka
Tak jak w przypadku Agile, DevOps nie jest jedną metodą postępowania, a zbiorem metod, które mają wspólne cechy i tworzą mniej lub bardziej spójny nurt. Podobnie jak w przypadku zwinnego podejścia, metodyka DevOps szturmem wdarła się do świata IT, wzbudzając spore zainteresowanie. Tak jak wiele innych nowych i popularnych terminów, również i tu, nie od początku było wiadome, o co w tym wszystkim chodzi. DevOps to koncept sporych rozmiarów, scharakteryzowanie go wymaga nakreślenia pewnych niuansów, by w pełni zrozumieć zjawisko.
DevOps to termin powstały w wyniku mariażu dwóch dużych trendów. Pierwszy z nich, określony także jako zwinna infrastruktura (agile infrastructure) lub zwinna działalność (agile operations), powstał w wyniku zastosowania podejść Agile i Lean. Drugi oparty jest na współpracy między pracownikami. Konkretniej; chodzi o znaczne poszerzenie rozumienia wartości współpracy między programistami a personelem operacyjnym na wszystkich etapach cyklu rozwoju oprogramowania podczas tworzenia i obsługi usługi czy produktu.
W wąskim rozumieniu zjawiska terminem ten określamy praktykę programistów i pracowników operacyjnych współpracujących w trakcie trwania całego cyklu życia usługi; od projektu, poprzez proces rozwoju do wsparcia produkcji.
Szerzej całość scharakteryzował Arkadiusz Gałęcki w wywiadzie zamieszczonym na stronie it-manager:
Devops (współpraca rozwoju i operacji) jest metodą tworzenia oprogramowania, która podkreśla, komunikację, współpracę i integrację pomiędzy deweloperami i specjalistami od eksploatacji. Devops jest odpowiedzią na współzależność rozwoju i operacji. Pomaga organizacji szybko wytwarzać oprogramowanie, produkty i usługi. Devops IT to model współpracy pomiędzy obszarami odpowiedzialnymi za projektowanie, przekazanie i eksploatację usług.
We wpisie What Is DevOps? Ernest Mueller skoncentrował się na powiązaniu DevOps z podejściami Agile i Lean. Kiedyś pojmowanie procesu wytworzenia usługi czy produktu rozdzielało uczestników procesu na tych, którzy tworzyli produkt czy usługę (Dev) i tych, którzy zajmowali się nim/nią po stworzeniu (Ops). Takie ścisłe rozróżnienie niejednokrotnie doprowadzało do negatywnych konsekwencji w procesie wytwarzania. Ścisła współpraca między tymi dwoma stronami stanowi rdzeń podejścia DevOps. W takim ujęciu DevOps można interpretować jako rozwinięcie Agile; zwinne metodyki zalecają ścisłą współpracę klientów, zarządzających produktami, programistów i (czasem) zespołu ds. kontroli jakości w celu uzupełnienia luk i szybkiego przejścia do ulepszonej wersji produktu. Istotną sprawą w tym procesie jest także kwestia związana z dostarczeniem usługi i tym jak aplikacja czy system reagują w środowisku. Te zagadnienia dotyczące jakości wytwarzanego produktu czy usługi muszą być wzięte pod uwagę przez zespół. Tak pojmowany DevOps stanowi po prostu przedłużenie zwinnych metod poza granice kodu i rozciągnięcie ich do całego procesu dostarczenia usługi.
W 2010 roku w swoim artykule poświęconym DevOps Damon Edwards przyznał, że lubi określać DevOps i Agile jako metody ze sobą powiązane, jednocześnie dzielące wspólną przeszłość (Lean), ale pracujące na trochę innych płaszczyznach. Podczas gdy metodyki Agile skupiają się głównie na poprawie jednej, głównej funkcjonalności IT (dostarczenie oprogramowania), to DevOps pracuje nad polepszeniem interakcji i płynności między różnymi funkcjonalnościami w IT (cały rozwój oprogramowania nie ogranicza się tylko do kodu, ale zajmuje się całym cyklem operacyjnym).
W praktyce DevOps to wiele różnych metod dla wielu różnych ludzi, ponieważ jego znaczenie obejmuje wiele różnych postaw. Mówi się o nim jako o programowaniu i współpracy operacyjnej, jako o podejściu traktującym kod jako infrastrukturę lub o podejściu korzystającym z automatyzacji, z kanban albo opartym na zestawie narzędzi czy kulturze.
Koniec końców definicje DevOps, podobnie jak Agile pozostawiają niedosyt. Nie oznacza to jednak, że próby definiowania są niepotrzebne. Aby we właściwy sposób wykorzystywać możliwości DevOps, należy zrozumieć wszystkie aspekty tej metodyki oraz to, co jej wdrożenie może ze sobą nieść lub czego na pewno nie zapewni. To, co DevOps przekazuje to zrozumienie (a w konsekwencji i praktyka), że oprogramowanie produktu czy usługi nie jest skończone, dopóki nie zostanie pomyślnie dostarczone użytkownikowi i nie spełni oczekiwań dotyczących dostępności, czy wydajności.
O nazwie
„Dev” jest skrótem od programistów – developers. W praktyce reprezentuje jednak szersze grono wszystkich osób zaangażowanych w rozwój produktu, jego kontrolę jakości i inne rodzaje dyscyplin. „Ops” to ogólny termin dla inżynierów systemowych, administratorów systemowych, personelu operacyjnego, administratorów sieci, inżynierów sieci, specjalistów ds. bezpieczeństwa i wielu innych subdyscyplin i stanowisk.
Sama w sobie nazwa jest dość chwytliwa; jednocześnie kreuje przekonujący obraz tego, czego dotyczy. Początkowo jednak opowiadano się za „Agile operations” „Agile infrastructure” i „Dev2Ops”. Znaleźć można również wiele przykładów użycia tej metodyki, bez stosowania jej nazwy. Ostatecznie zdecydowana się na DevOps, które przez połączenie dwóch komponentów przy jednoczesnym podkreśleniu integracji, bardzo trafnie przemawia do zbiorowej świadomości. Nie można w tym miejscu przemilczeć wysiłków Patricka Duboisa, który przyczynił się do powstania konferencji DevOps Days i prowadzi stronę devops.info.
DevOps a testowanie oprogramowania
Chyba wszystkim znany jest schemat, gdy programiści i zespół testerski pracują do późnych godzin nocnych, skoncentrowani i pospieszani, by dostarczyć produkt w wyznaczonym terminie. Szybkie naprawy, ponowne ustalanie priorytetów i odraczanie błędów, by tylko zamknąć listę bugów, przekazać wszystko do staging server, przeprowadzić po raz ostatni regres i przepchnąć wszystko dalej do grupy operacyjnej, by skończyć swoje zadanie. Dla znacznej części programistów i testerów zespół operacyjny stanowi niewiadomą, a wiedza o rolach, obowiązkach czy terminach w Opsach, również jest znikoma. Niedługo po przekroczeniu terminu dla grupy Dev, po paru opóźnieniach, pytaniach i wprowadzeniu korekt, produkt wprowadzany jest na rynek. Zespół Dev nie ingeruje w to, co robi Ops, ani odwrotnie. Każdy wykonuje swoją część pracy i przekazuje ją do kolejnego etapu rozwoju.
DevOps proponuje inne rozwiązanie; ciągłą współpracę między różnymi specjalizacjami i stanowiskami podczas całego cyklu produkcyjnego. Dla różnych ludzi DevOps oznacza różne rzeczy, ale dla testerów oprogramowania oznacza jedno: Continuous Testing (CT). CT to nie tylko ponowne uruchamianie tego samego zestawu testów „pełnej regresji” w miarę jak produkt jest dostarczany i wdrażany. CT to dbanie o jakość produktu na każdym kroku jego powstawania, a nie kontrolę jakości pod sam koniec.
A jeśli chcecie dowiedzieć się więcej na temat Continuous Testing i roli testerów w metodyce DevOps, to zapraszamy do drugiej części naszego wpisu, która ukaże się już w sierpniu.
Źródło grafiki: http://dev2ops.org/2010/11/devops-is-not-a-technology-problem-devops-is-a-business-problem/
