DevOps to podejście do tworzenia, dostarczania i utrzymywania oprogramowania, które łączy ludzi, procesy i technologię w jeden przepływ od pomysłu do działającej usługi. Jego celem jest ograniczenie barier pomiędzy developmentem, operacjami, testowaniem i bezpieczeństwem oraz stworzenie warunków do częstego, bezpiecznego wprowadzania zmian.
DevOps nie jest konkretną metodyką ani pojedynczym narzędziem. Samo wdrożenie Jenkinsa, Dockera, Kubernetes czy pipeline’u CI/CD nie oznacza jeszcze, że organizacja pracuje zgodnie z DevOps.
Znaczenie ma cały system: jak kod trafia na produkcję, ile jest ręcznych przekazań pracy, jak szybko zespół otrzymuje feedback, kto odpowiada za działanie usługi i jak organizacja reaguje na awarie.
AWS definiuje DevOps jako połączenie filozofii kulturowych, praktyk i narzędzi zwiększających zdolność organizacji do szybkiego dostarczania aplikacji i usług. Microsoft podobnie opisuje DevOps jako połączenie developmentu i operations wokół ludzi, procesów i technologii obejmujących planowanie, rozwój, delivery oraz utrzymanie aplikacji.
Czym jest DevOps?
Nazwa DevOps pochodzi od połączenia:
Development – tworzenia i rozwijania oprogramowania,
oraz
Operations – wdrażania, utrzymywania i zapewniania niezawodności działających systemów.
Tradycyjny podział tych obszarów prowadził często do powstania silosów.
Development koncentrował się na dostarczeniu nowych funkcji. Operations odpowiadało za stabilność produkcji. Testerzy kontrolowali jakość w osobnym etapie, a security pojawiało się niekiedy dopiero przed wydaniem.
Zmiana przechodziła więc przez kolejne zespoły:
development → testy → operations → produkcja.
Każde przekazanie oznaczało dodatkowe oczekiwanie, zmianę kontekstu i możliwość utraty informacji.
DevOps próbuje zmienić ten model.
Zespoły współpracują wokół pełnego cyklu życia produktu lub usługi: od planowania, przez tworzenie i testowanie, po deployment, monitoring oraz reagowanie na problemy produkcyjne.
Microsoft wskazuje wprost, że cykl DevOps obejmuje planowanie, development, delivery i operations, a poszczególne fazy nie powinny być przypisane wyłącznie do jednej izolowanej roli.
W praktyce developer powinien więc rozumieć, jak jego aplikacja zachowuje się na produkcji, a osoby odpowiedzialne za operacje powinny uczestniczyć w projektowaniu mechanizmów pozwalających aplikację bezpiecznie wdrażać i utrzymywać.
DevOps nie oznacza po prostu zatrudnienia DevOps Engineera
Na rynku pracy DevOps Engineer jest realnym stanowiskiem, ale DevOps jako sposób działania organizacji nie powinien sprowadzać się do jednej osoby lub jednego zespołu.
Jeżeli proces wygląda tak:
developer kończy kod → wysyła zgłoszenie do zespołu DevOps → zespół DevOps wykonuje deployment → operations przejmuje aplikację,
organizacja może nadal posiadać ten sam problem przekazywania pracy, tylko pod nowymi nazwami.
AWS podkreśla, że w modelu DevOps bariery pomiędzy developmentem i operations są ograniczane, a zespoły mogą wspólnie odpowiadać za cały cykl życia aplikacji. Do tego modelu mogą być również bliżej włączone QA oraz security.
Osobny zespół może mieć natomiast sens jako:
- zespół platformowy,
- platform engineering,
- zespół budujący wspólne pipeline’y i narzędzia,
- cloud enablement,
- zespół pomagający innym wdrażać praktyki DevOps.
Różnica polega na tym, że powinien ułatwiać zespołom samodzielne delivery, a nie stawać się dodatkową bramką, przez którą musi przejść każda zmiana.
Jak działa DevOps w cyklu życia oprogramowania?
DevOps obejmuje znacznie więcej niż deployment.
Można spojrzeć na niego przez cały przepływ:
Planowanie
Zespół identyfikuje problem, planuje pracę i ustala priorytety.
W tym miejscu DevOps łączy się z Agile. Zamiast planować ogromne wydania na wiele miesięcy, pracę można dzielić na mniejsze części i regularnie zbierać informację zwrotną.
Development
Kod znajduje się w systemie kontroli wersji. Zmiany są niewielkie, regularnie integrowane, poddawane review i automatycznej kontroli.
Testowanie
Odpowiednie testy są wykonywane możliwie wcześnie i automatycznie.
Nie chodzi wyłącznie o testy interfejsu użytkownika. Pipeline może obejmować testy jednostkowe, integracyjne, API, bezpieczeństwa i wybrane E2E.
Delivery
Zbudowany i zweryfikowany artefakt przechodzi przez kolejne środowiska przy wykorzystaniu powtarzalnego procesu wdrożeniowego.
Operations
Po wdrożeniu zespół obserwuje działanie aplikacji, analizuje telemetrykę, reaguje na problemy i wykorzystuje wiedzę z produkcji przy kolejnych zmianach.
Microsoft właśnie w taki sposób dzieli praktyki DevOps pomiędzy planowanie, development, delivery oraz operations.
Powstaje w ten sposób zamknięta pętla:
planowanie → kod → weryfikacja → deployment → obserwacja → feedback → kolejna zmiana.
Agile a DevOps – jaka jest różnica?
Agile i DevOps są ze sobą silnie związane, ale rozwiązują problemy na innych poziomach.
Agile koncentruje się przede wszystkim na sposobie organizowania pracy, iteracyjnym dostarczaniu wartości, feedbacku i reagowaniu na zmianę.
DevOps rozszerza tę logikę na techniczny proces tworzenia, dostarczania i utrzymywania oprogramowania.
Można więc pracować w Scrumie i nadal wydawać aplikację raz na kwartał poprzez skomplikowany ręczny proces.
Z punktu widzenia zespołu projekt może być Agile. Z punktu widzenia delivery organizacja nadal może posiadać bardzo małą zdolność do szybkiego wprowadzania zmian.
DevOps pomaga usunąć tę lukę.
Microsoft wymienia Agile software development jako jedną z praktyk współpracujących z DevOps i podkreśla częste, niewielkie zmiany oraz szybkie uczenie się na podstawie feedbacku.
W praktyce:
Agile pomaga szybciej zdecydować, co warto zmienić.
DevOps pomaga tę zmianę szybko, powtarzalnie i bezpiecznie dostarczyć.
Najważniejsze praktyki DevOps
Nie istnieje jedna obowiązkowa lista praktyk, które trzeba wdrożyć jednocześnie. W dojrzałych środowiskach regularnie pojawia się jednak kilka mechanizmów tworzących wspólny system delivery.
Kontrola wersji
Version control jest jednym z fundamentów DevOps.
Kod aplikacji powinien znajdować się w repozytorium takim jak Git, dzięki czemu:
- historia zmian jest widoczna,
- zmiany mogą przechodzić code review,
- można wracać do wcześniejszych wersji,
- pipeline może reagować na commit lub pull request,
- kilka osób może bezpieczniej pracować nad wspólnym systemem.
W podejściu DevOps kontrolą wersji warto obejmować nie tylko kod aplikacji.
W repozytorium mogą znajdować się również:
- konfiguracje,
- definicje pipeline’ów,
- Infrastructure as Code,
- polityki,
- testy automatyczne.
Microsoft określa version control jako fundamentalną praktykę DevOps, która wspiera również CI oraz Infrastructure as Code.
CI/CD
Continuous Integration i Continuous Delivery automatyzują drogę zmiany przez kolejne etapy weryfikacji i przygotowania do wydania.
W CI developerzy regularnie integrują niewielkie zmiany, po których automatycznie uruchamiane są buildy i testy.
Continuous Delivery rozwija ten mechanizm, tworząc proces pozwalający utrzymywać oprogramowanie w stanie gotowym do wydania.
CI/CD jest jednym z najważniejszych technicznych mechanizmów DevOps, ale nie jest synonimem DevOps.
Można zbudować świetny pipeline, a jednocześnie mieć:
- zamrożone priorytety,
- silosy organizacyjne,
- brak odpowiedzialności zespołu za produkcję,
- słaby monitoring,
- ręczne procesy wokół pipeline’u.
Dlatego szczegółową budowę CI/CD warto traktować jako osobne zagadnienie, a na poziomie DevOps patrzeć przede wszystkim na cały system delivery.
Automatyzacja testów i continuous testing
Automatyczne testowanie pozwala otrzymać informację o jakości zmiany bez ręcznego wykonywania wszystkich scenariuszy przez testera.
DORA wymienia test automation wśród podstawowych zdolności wspierających continuous delivery. Skuteczny zestaw powinien być przede wszystkim wiarygodny: wykrywać rzeczywiste problemy i przepuszczać kod, który nadaje się do wydania.
W praktyce można automatyzować:
- testy jednostkowe,
- integracyjne,
- API,
- regresję,
- wybrane E2E,
- część kontroli bezpieczeństwa,
- testy wydajnościowe.
Samo napisanie automatów nie wystarcza.
W podejściu continuous testing odpowiednie testy są rozmieszczone na kolejnych etapach pipeline’u tak, aby możliwie szybko dostarczać informację o ryzyku.
Infrastructure as Code
Infrastructure as Code, czyli IaC, oznacza definiowanie infrastruktury za pomocą kodu zamiast ręcznej konfiguracji serwerów i usług.
AWS opisuje IaC jako stosowanie wobec infrastruktury podobnej dyscypliny jak wobec kodu aplikacyjnego: konfiguracja może być zapisana w repozytorium, wersjonowana, przeglądana i wdrażana w powtarzalny sposób.
Dzięki temu można automatyzować na przykład:
- tworzenie środowisk,
- konfigurację sieci,
- zasoby chmurowe,
- bazy danych,
- klastry,
- uprawnienia.
Przykładowymi technologiami są Terraform, OpenTofu, AWS CloudFormation, Azure Bicep czy Pulumi.
Najważniejsza nie jest jednak nazwa narzędzia.
Wartością IaC jest powtarzalność i możliwość odtworzenia środowiska bez ręcznego wykonywania dziesiątek kroków.
Monitoring, observability i feedback z produkcji
Deployment nie kończy pracy nad zmianą.
Zespół powinien wiedzieć:
- czy aplikacja odpowiada,
- czy wzrósł poziom błędów,
- czy użytkownicy mogą wykonywać najważniejsze operacje,
- jak zmienił się czas odpowiedzi,
- czy nowa wersja wpływa na infrastrukturę,
- gdzie powstaje problem.
Microsoft wskazuje telemetrykę i actionable alerting jako podstawowe elementy utrzymywania niezawodnych systemów.
Monitoring odpowiada zazwyczaj na znane pytania poprzez wcześniej zdefiniowane metryki i alerty.
Observability idzie szerzej: pozwala analizować zachowanie systemu na podstawie danych takich jak:
- metrics,
- logs,
- traces.
W praktyce mogą być wykorzystywane między innymi Prometheus, Grafana, OpenTelemetry, Datadog, New Relic czy rozwiązania poszczególnych chmur.
Narzędzie jest jednak dopiero drugą decyzją. Najpierw trzeba wiedzieć jakie zachowanie usługi chcemy obserwować i jaki sygnał powinien prowadzić do reakcji.
DevSecOps – bezpieczeństwo jako część delivery
Jeżeli bezpieczeństwo pojawia się dopiero przed produkcyjnym release, znaleziony problem może wymagać cofnięcia dużej części prac.
DevSecOps włącza security w cały proces developmentu i delivery.
AWS opisuje DevSecOps jako praktykę integrującą testowanie bezpieczeństwa z kolejnymi etapami tworzenia oprogramowania oraz budującą wspólną odpowiedzialność developmentu, security i operations.
W pipeline można automatyzować m.in.:
- secret scanning,
- SAST,
- analizę zależności,
- Software Composition Analysis,
- skanowanie kontenerów,
- DAST,
- wybrane kontrole compliance.
Nie oznacza to zastąpienia specjalistów security skanerem.
Automatyzacja pozwala przede wszystkim wcześniej i regularnie wykrywać znane klasy problemów.
Małe i częste zmiany
DevOps znacznie łatwiej działa, gdy organizacja dostarcza małe partie pracy.
Zmiana obejmująca 20 plików i niewielki fragment funkcjonalności jest łatwiejsza do:
- sprawdzenia,
- zrozumienia,
- wdrożenia,
- wycofania,
- zdiagnozowania po awarii
niż ogromny release zawierający kilkumiesięczną pracę kilkunastu zespołów.
AWS wskazuje małe, częste aktualizacje jako jedną z podstawowych praktyk modelu DevOps, ponieważ zmniejszają ryzyko pojedynczego wdrożenia i ułatwiają znalezienie źródła błędu.
Z tym mechanizmem wiąże się także trunk-based development.
DORA opisuje go jako pracę z niewielkimi zmianami regularnie integrowanymi z główną linią kodu zamiast utrzymywania długowiecznych gałęzi przez wiele dni lub tygodni.
Automatyzacja w DevOps – co warto automatyzować?
DevOps mocno wykorzystuje automatyzację, ale nie dlatego, że celem jest eliminacja ręcznej pracy za wszelką cenę.
Automatyzowane powinny być przede wszystkim czynności:
- częste,
- powtarzalne,
- podatne na błąd,
- posiadające jasno określone reguły,
- będące częścią krytycznego przepływu delivery.
Przykładowy przepływ może wyglądać następująco:
commit → build → automatyczne testy → security checks → przygotowanie artefaktu → deployment → smoke tests → monitoring
Inny proces może automatycznie:
- utworzyć środowisko z IaC,
- wdrożyć konkretną wersję aplikacji,
- skonfigurować usługę,
- wykonać migrację,
- zweryfikować działanie,
- wycofać zmianę po niespełnieniu kryteriów.
Automatyzacja nie powinna jednak utrwalać źle zaprojektowanego procesu.
Jeżeli deployment wymaga 18 niepotrzebnych akceptacji, pierwszym rozwiązaniem nie powinno być stworzenie automatu obsługującego wszystkie 18.
Najpierw trzeba uprościć przepływ, a dopiero później automatyzować jego potrzebne elementy.
DevOps a platform engineering
W większych organizacjach utrzymywanie indywidualnych pipeline’ów, konfiguracji Kubernetes, polityk bezpieczeństwa i infrastruktury przez każdy zespół może prowadzić do znacznego powielania pracy.
W tym miejscu pojawia się platform engineering.
Zespół platformowy może przygotować wewnętrzną platformę zawierającą gotowe ścieżki dla typowych operacji:
- utworzenie repozytorium,
- przygotowanie pipeline’u,
- deployment usługi,
- monitoring,
- zarządzanie sekretami,
- provisioning infrastruktury.
Dzięki temu developer nie musi za każdym razem poznawać szczegółów całej infrastruktury.
DORA traktuje obecnie platform engineering jako osobną zdolność wspierającą software delivery i zaleca ocenianie jej m.in. poprzez wpływ na wydajność delivery, doświadczenie developerów oraz wykorzystanie platformy.
Platform engineering nie zastępuje więc DevOps.
Może być jednym ze sposobów skalowania jego praktyk bez tworzenia setek indywidualnych rozwiązań.
Jak wdrożyć praktyki DevOps w organizacji?
Najczęstszy błąd polega na rozpoczęciu transformacji od listy narzędzi.
Firma kupuje platformę CI/CD, tworzy klaster Kubernetes, instaluje system monitoringu i zatrudnia DevOps Engineerów.
Po kilku miesiącach release nadal trwa dwa tygodnie.
Przyczyną jest to, że narzędzia zmieniły się szybciej niż proces.
Zacznij od przepływu wartości
Najpierw warto prześledzić drogę jednej realnej zmiany.
Od momentu, gdy developer zaczyna nad nią pracować, aż do momentu, gdy funkcja działa na produkcji i może zostać użyta przez klienta.
Warto zaznaczyć:
- pracę,
- oczekiwanie,
- akceptacje,
- ręczne przekazania,
- zależności,
- poprawki,
- testy,
- deployment.
DORA rekomenduje value stream mapping właśnie jako sposób analizowania przepływu software delivery i identyfikowania zarówno normalnej drogi dostarczania zmian, jak i ścieżki odzyskiwania po awarii.
Może się wtedy okazać, że samo budowanie aplikacji trwa 10 minut, ale:
- code review czeka dwa dni,
- testy rozpoczynają się następnego dnia,
- deployment wymaga ręcznego zgłoszenia,
- environment provisioning trwa trzy dni,
- wydanie odbywa się raz na miesiąc.
Automatyzowanie buildu z 10 do 5 minut nie będzie wtedy najważniejszą optymalizacją.
Usuń niepotrzebne handoffy
Jeżeli każda zmiana musi przejść kolejno przez development, QA, release management, operations i kilka poziomów akceptacji, lead time będzie długi niezależnie od technologii.
Warto ograniczać:
- kolejki,
- przekazywanie odpowiedzialności,
- duże partie,
- wielopoziomowe ręczne approvals,
- zależność od pojedynczych specjalistów.
Nie chodzi o likwidację kontroli.
Chodzi o przeniesienie ich bliżej miejsca, w którym powstaje zmiana, oraz automatyzację tam, gdzie regułę można jednoznacznie sprawdzić.
Zbuduj podstawy techniczne
Kiedy przepływ jest już zrozumiały, można stopniowo budować techniczne fundamenty:
version control → automatyczny build → automatyczne testy → powtarzalny deployment → IaC → observability
Nie każda organizacja musi realizować dokładnie taką sekwencję. Priorytet powinien wynikać z największego aktualnego ograniczenia.
Jeżeli deployment trwa dwa dni, jego automatyzacja może być ważniejsza niż rozbudowanie monitoringu.
Jeżeli release jest szybki, ale awarie wykrywa klient, większą wartość da observability.
Jak mierzyć efekty DevOps?
Liczba skonfigurowanych pipeline’ów albo wykorzystanie Kubernetes nie mówi wiele o poprawie delivery.
Dużo lepszym punktem odniesienia są metryki DORA.
W aktualnym modelu DORA stosuje pięć metryk opisujących przepustowość i niestabilność software delivery.
| Metryka | Co mierzy? |
|---|---|
| Change lead time | Czas od commitu do działającej zmiany na produkcji |
| Deployment frequency | Jak często zmiany są wdrażane |
| Failed deployment recovery time | Jak długo trwa odzyskanie po nieudanym wdrożeniu |
| Change fail rate | Jaka część deploymentów wymaga interwencji po wystąpieniu problemu |
| Deployment rework rate | Jaka część deploymentów jest nieplanowaną pracą naprawczą |
Pierwotny model był powszechnie znany jako „cztery metryki DORA”. Od 2024 roku DORA wykorzystuje pięć wskaźników, dodając deployment rework rate. Historię tej zmiany opisano ponownie w styczniu 2026 roku.
To ważne także z praktycznego punktu widzenia.
DORA podkreśla, że szybkość i stabilność nie muszą być przeciwieństwami. Dobrze działający system delivery powinien umożliwiać zarówno sprawne wprowadzanie zmian, jak i ograniczanie ich negatywnych skutków.
Metryk nie należy natomiast wykorzystywać jako rankingu developerów czy prostego sposobu porównywania zupełnie różnych systemów.
Najwięcej wartości dają podczas obserwowania jednego produktu lub usługi w czasie i sprawdzania, czy konkretna zmiana procesu rzeczywiście przyniosła poprawę.
Narzędzia DevOps – wybieraj według problemu
DevOps nie posiada obowiązkowego stacku technologicznego.
| Obszar | Przykładowe rozwiązania |
| Version control | GitHub, GitLab, Bitbucket, Azure Repos |
| CI/CD | GitHub Actions, GitLab CI/CD, Jenkins, Azure Pipelines |
| Kontenery | Docker |
| Orkiestracja | Kubernetes |
| Infrastructure as Code | Terraform, OpenTofu, Pulumi, CloudFormation, Bicep |
| Configuration management | Ansible |
| Monitoring i observability | Prometheus, Grafana, OpenTelemetry, Datadog |
| Security | SAST, DAST, SCA, secret scanning |
| Zarządzanie artefaktami | registry kontenerów, package repositories |
Nie każdy zespół potrzebuje wszystkich tych elementów.
Aplikacja działająca na prostej platformie PaaS może mieć świetnie działający proces DevOps bez Kubernetes.
Podobnie niewielki zespół nie potrzebuje skomplikowanej platformy observability tylko dlatego, że korzystają z niej duże firmy technologiczne.
Najpierw określa się problem procesu, później dobiera narzędzie.
Kubernetes, Docker i Jenkins nie są DevOps
Te trzy technologie bardzo często pojawiają się w materiałach o DevOps, ale pełnią zupełnie różne funkcje.
Docker pomaga pakować i uruchamiać aplikacje w kontenerach.
Kubernetes służy do orkiestracji konteneryzowanych workloadów.
Jenkins automatyzuje procesy i może być używany jako serwer CI/CD.
Każde z tych narzędzi może wspierać DevOps.
Żadne z nich nie jest wymagane do jego wdrożenia.
Organizacja może zbudować bardzo sprawny proces na GitHub Actions i zarządzanej platformie chmurowej bez własnego klastra Kubernetes.
Może też posiadać dziesiątki klastrów i setki pipeline’ów, a nadal mieć miesięczny lead time i ręczne handoffy pomiędzy zespołami.
Technologia umożliwia poprawę procesu. Nie zastępuje decyzji o tym, jak proces ma działać.
Jakie można napotkać błędy przy wdrażaniu DevOps?
Transformacja zaczyna się od narzędzi
Zakup kolejnej platformy nie naprawi złego przepływu odpowiedzialności.
Najpierw trzeba ustalić, gdzie praca czeka i dlaczego.
Powstaje kolejny silos DevOps
Jeżeli wszystkie zespoły muszą wysyłać tickety do pięcioosobowego zespołu odpowiedzialnego za każdy deployment, provisioning i zmianę pipeline’u, bardzo szybko powstanie bottleneck.
Zespół platformowy powinien zwiększać samodzielność zespołów produktowych, a nie przejmować od nich całą odpowiedzialność za delivery.
Automatyzuje się proces bez jego uproszczenia
Skrypt wykonujący dziesięć zbędnych kroków nadal realizuje dziesięć zbędnych kroków.
Pipeline jest zielony, ale nikt nie obserwuje produkcji
Testy mogą potwierdzić znane scenariusze. Nie powiedzą wszystkiego o rzeczywistym zachowaniu systemu pod prawdziwym obciążeniem i przy realnych danych.
Potrzebny jest feedback z produkcji.
Security pozostaje ostatnią bramką
Jeżeli większość kontroli bezpieczeństwa odbywa się na końcu, problemy są wykrywane wtedy, kiedy ich usunięcie jest najdroższe.
Każdy zespół buduje wszystko od początku
Przy większej skali warto standaryzować powtarzalne elementy i zapewniać zespołom wspólne komponenty oraz self-service.
Przykład wdrożenia praktyk DevOps
Firma rozwija aplikację SaaS.
Początkowo proces wydania wygląda tak:
Developer kończy funkcję i przekazuje ją do testów.
Tester czeka na ręczne przygotowanie środowiska.
Po zakończeniu regresji powstaje ticket do administratora.
Administrator wieczorem wykonuje deployment według dokumentu zawierającego kilkadziesiąt kroków.
Jeżeli wystąpi problem, logi są zbierane ręcznie.
Wydanie odbywa się raz na trzy tygodnie, ponieważ sam proces jest ryzykowny.
Zespół rozpoczyna zmianę nie od Kubernetes, lecz od mapowania przepływu.
Największymi problemami okazują się ręczny deployment, długie oczekiwanie na środowisko i późne testy regresyjne.
Pierwszy etap obejmuje więc:
- zapis konfiguracji w repozytorium,
- automatyczny build,
- szybkie testy przy pull requeście,
- automatyczne tworzenie środowiska testowego,
- powtarzalny deployment.
W kolejnym kroku część regresji trafia do pipeline’u, a zespół dodaje telemetrykę pozwalającą obserwować aplikację po release.
Zmiany stają się mniejsze, ponieważ koszt wydania spada.
Mniejszy release łatwiej zweryfikować i w razie problemu wycofać.
Po kilku iteracjach zespół analizuje change lead time i odkrywa, że kolejnym bottleneckiem nie jest już infrastruktura, lecz czas oczekiwania na code review.
Optymalizacja przesuwa się więc w inne miejsce.
To właśnie odróżnia wdrożenie DevOps od projektu pod tytułem „uruchamiamy pipeline”.
DevOps jest procesem ciągłego usprawniania całego systemu dostarczania oprogramowania.
Jak zacząć wdrażanie DevOps?
Dobre wdrożenie można rozpocząć bez wielkiej transformacji całej organizacji.
Wybierz jedną usługę lub produkt i prześledź realną zmianę od commitu do produkcji. Zmierz, ile czasu zajmuje wykonanie pracy, a ile oczekiwanie. Sprawdź, gdzie pojawiają się ręczne kroki, problemy jakościowe i zależności.
Następnie wybierz jedno ograniczenie, którego usunięcie najbardziej poprawi cały przepływ.
Może to być:
- ręczne budowanie aplikacji,
- brak automatycznych testów,
- deployment wykonywany według dokumentu,
- ręczne tworzenie środowisk,
- brak danych o produkcji,
- długotrwałe branchowanie,
- oczekiwanie na zewnętrzny zespół.
Po wdrożeniu zmiany obserwuj wpływ na lead time, częstotliwość wdrożeń, awarie i czas odzyskiwania. Jeżeli proces faktycznie się poprawił, przejdź do kolejnego ograniczenia.
Taka iteracyjna transformacja jest znacznie bliższa idei DevOps niż jednorazowy program wdrożenia zestawu narzędzi.
Dojrzałość DevOps nie polega na tym, ile technologii posiada organizacja. Widać ją przede wszystkim po tym, jak szybko zespół potrafi zamienić niewielką zmianę w działającą wartość dla użytkownika, zachowując przy tym kontrolę nad jakością, bezpieczeństwem i niezawodnością systemu.
