Wyjaśniając komuś DevOps, zdarza się, że pojawia się pytanie:
W jaki sposób zarządzanie wersjami przy użyciu metodyki Agile różni się od Waterfall?
Jakiego rodzaju kryteriów możesz użyć, aby wyjaśnić te różnice takiej grupie odbiorców?
Które aspekty zarządzania wersjami pomagają wyjaśnić różnicę między Waterfall a Agile?
Odpowiedzi:
IMO DevOps to kultura, podobnie jak Agile (bez wybierania zwinnej metodologii). Dlatego nie „robisz” DevOps.
„Robisz” metodologię zwaną Continuous Delivery jako część DevOps Culture. (pełne ujawnienie, nie sądzę, żebym kiedykolwiek wspominał o CD jako o metodologii wydania, ale w moim stanie odrzutowym myślę, że to działa)
Jeśli to kupisz, oto definicja Continuous Delivery od jednej z osób, które napisały książkę pod tym samym tytułem, Jez Humble .
Continuous Delivery to możliwość wprowadzania zmian wszelkiego rodzaju - w tym nowych funkcji, zmian konfiguracji, poprawek błędów i eksperymentów - do produkcji lub w ręce użytkowników, szybko i bezpiecznie w sposób zrównoważony.
Naszym celem jest, aby wdrożenia - na dużą skalę systemu rozproszonego, złożonego środowiska produkcyjnego, systemu osadzonego lub aplikacji - były przewidywalne, rutynowe, które można wykonywać na żądanie.
Osiągamy to wszystko, zapewniając, że nasz kod jest zawsze w stanie do wdrożenia, nawet w obliczu zespołów tysięcy programistów, którzy codziennie wprowadzają zmiany. W ten sposób całkowicie eliminujemy etapy integracji, testowania i hartowania, które tradycyjnie następowały po „dev complete”, a także zawieszanie się kodu.
Zatem możesz pracować w metodyce Agile, mając oprogramowanie, które możesz zademonstrować firmie, upewniając się, że wykonujesz odpowiednie automatyczne testy, dobrze reagujesz na zmiany i wszystkie rzeczy, które sprawiają, że jest lepszy niż wodospad. Zbyt często nie oznacza to, że można go wdrożyć do produkcji.
W efekcie powstaje coś takiego:
Więc oprogramowanie będzie (prawdopodobnie) lepsze, gdy skończysz, jeśli nie miałbyś jakiegoś iteracyjnego podejścia, ale tak naprawdę nie wiesz, ponieważ prawdziwi użytkownicy nigdy go nie widzieli.
To, czego naprawdę chcesz, to coś, co wygląda mniej więcej tak:
Z każdą iteracją coś zostaje wdrożone do produkcji. Oprogramowanie zostało więc wdrożone . Jeśli zdecydujesz się utworzyć pliki do pobrania, otwórz serwer WWW lub dostaniesz oprogramowanie w ręce użytkowników, które zostaną wydane .
Co za cholera!? Zapytałem o DevOps! Nikt nie pytał o ciągłą dostawę !!
Co ma z tym wspólnego DevOps?
Bardzo, bardzo trudno (zbliża się to niemożliwe), aby naprawdę mieć oprogramowanie w stanie, w którym można je wdrożyć w dowolnym momencie, chyba że zespół pracuje w kulturze DevOps. Kultura, w której administratorzy systemu, DBA, SRE, specjaliści od bezpieczeństwa, deweloperzy, kontrole jakości itp. Są częścią jednego zespołu, a nie uciszoną częścią organizacji z handoffami.
Uwaga :
O części komentarza opublikowanego do tej odpowiedzi, która wyglądała tak:
O twoim „... oprogramowaniu w stanie, w którym możesz go wdrożyć, kiedy chcesz ...”: przypomina mi to oprogramowanie „automatycznego pilota” (w samolocie) ... Moje ulubione pytanie na ten temat: „ Wyobraź sobie aktualizację jest zastosowane do takiego oprogramowania ... Jak byś się czuł tak robiąc inflight ... Gdy jesteś na pokładzie? ".
Uwielbiam to pytanie (pogrubione, w powyższym cytacie)! Pomysł „czy to naprawdę gotowe?” jest czymś, o czym ciągle gadam - blog . IMO jest ważne, abyś był pewny bezpieczeństwa, wydajności i innych zbyt często „wtórnych” testów, aby ćwiczyć CD. Funkcje są wykonywane, gdy są gotowe, ale hakerzy są zawsze na miejscu.
Dziękujemy za interesujące punkty widzenia / odpowiedzi (i błyszczące obrazy ...). Muszę przyznać, że nigdy nie słyszałem o terminologii metodologii wydawania , chociaż zarządzanie wydaniami jest mi dobrze znane (od ponad 2 dekad ...). O twoim „... oprogramowaniu w stanie, w którym możesz go wdrożyć, kiedy chcesz ...” (w połączeniu z „jetlagged”): przypomina mi to oprogramowanie „automatycznego pilota” (w samolocie) ... Moje ulubione pytanie na ten temat: „ Wyobraź sobie, że do takiego oprogramowania zastosowano aktualizację ... Jak byś się czuł, robiąc to w locie ... Gdy jesteś na pokładzie? ”.
—
Pierre.Vriens
Uwielbiam to pytanie! Pomysł „czy to naprawdę gotowe?” jest czymś, o czym ciągle gadam - blog . IMO jest ważne, abyś był pewny bezpieczeństwa, wydajności i innych zbyt często „wtórnych” testów, aby ćwiczyć CD. Funkcje są wykonywane, gdy są gotowe, ale hakerzy są zawsze na miejscu.
—
Ken Mugrage,
Miałem na myśli - „Wyobraź sobie, że do takiego oprogramowania zastosowano aktualizację ... Jak byś się czuł, robiąc to w locie ... Gdy jesteś na pokładzie?”
—
Ken Mugrage,
I proszę wyedytuj, jestem tutaj n00b :)
—
Ken Mugrage
Zapoznaj się z moją sugerowaną edycją, aby uwzględnić również interesujący komentarz. Jeśli ci się nie podoba, po prostu wykonaj wycofanie do poprzedniej wersji (link znajduje się w „wersjach”) i / lub dalej popraw / rozszerz go, jak chcesz. Zgadnij co, wydaje się, że „inflight” zmieniło się niektóre z moich „uprawnień”… wygląda na to, że mam już za dużo przedstawicieli, aby nadal potrzebować „zatwierdzeń” dla takich sugerowanych zmian… na szczęście to tylko niektóre SE- oprogramowanie (nie sugerowana aktualizacja niektórych tras lotu bez uprzedniej zgody kontroli ruchu lotniczego ...). Oeps 2 (korekta): został zatwierdzony z prędkością światła ...
—
Pierre.Vriens
Nie jestem pewien, czy nie ma żadnych innych, ale takich kryteriów używam:
+-------------------+-----------+-----------+
! Criteria ! Agile ! Waterfall !
+-------------------+-----------+-----------+
! Release Events ! Frequent ! Rare !
! Risk ! Less ! High !
! Required Effort ! Smoother ! Peaks !
! Volume of changes ! Small ! Huge !
+-------------------+-----------+-----------+
A jeśli naprawdę chcesz sam poczuć różnicę jako użytkownik jakiegoś oprogramowania, zastanów się nad użyciem jakiegoś oprogramowania (takiego jak dystrybucja Linuksa), w którym masz do wyboru jedną z tych wersji:
wydanie „
Rolling” (==> Agile).wydanie „
Long Term Support” (==> Wodospad).
Przykład Linuksa może nie być zbyt inspirujący :) Osobiście nie lubię wydawania kolejnych wersji z powodu: 1. poziomu jakości i 2. raczej rozpraszających zmian (wolę skupiać się na swojej pracy, a nie na linuksie, którego używam praca). Więc używam tych (najstarsi) terminowych (często znacznie przekraczających EOL) i skupiam się na ważnej aktualizacji raz na 2-3 lata. Chyba że jest to tylko zwiększenie adwersji do zmian z powodu starzenia się? :)
—
Dan Cornilescu
@ DanCornilescu Użyłem tego przykładu dla Linuksa, ponieważ uważam, że jest to skrajny przykład aspektu „a” wydania mgnt (tj. Częstotliwości wydań) dla obu metodologii. Chociaż „osobiście” całkowicie zgadzam się z tym, że nie lubisz wydawania kolejnych wersji, z tych samych powodów, o których wspomniałeś.
—
Pierre.Vriens