Dlaczego „przyszłość DevOps to GitOps” – kontekst i realia
DevOps osiągnął sufit: gdzie procesy zaczynają się kruszyć przy dużej skali
Klasyczny DevOps rozwiązał wiele bolączek epoki serwerów fizycznych i monolitów. Zespoły zaczęły automatyzować buildy, testy, wdrożenia; pojawiły się pipeline’y CI/CD, a operacje i development zaczęły ze sobą normalnie rozmawiać. Jednak przy dużej skali – dziesiątkach mikroserwisów, wielu regionach chmurowych, środowiskach hybrydowych – ten model zaczyna pękać.
Najpierw rośnie złożoność narzędzi: osobne pipeline’y dla każdej aplikacji, osobne skrypty provisioningowe, osobne dashboardy monitoringu. Później rośnie złożoność procesów: kto ma prawo „kliknąć deploy”, gdzie jest ostateczna konfiguracja aplikacji, czy stan klastra pokrywa się z tym, co jest w dokumentacji. Kiedy do gry wchodzi kilkudziesięciu deweloperów z różnych zespołów, łatwo o chaos. Każda zmiana jest „incydentem w potencjale”, bo nikt nie ma jednego, spójnego widoku na to, jak <empowinno wyglądać środowisko.
Przy skali organizacyjnej rosną też wymagania audytowe i compliance. Działy bezpieczeństwa, regulatorzy, klienci korporacyjni pytają: kto, kiedy i co zmienił? Czy można to odtworzyć? Czy jest roll-back? Klasyczne podejście DevOps, gdzie część decyzji podejmuje się z poziomu narzędzi CI/CD albo konsoli chmurowej, zaczyna być trudne do ogarnięcia. GitOps wchodzi dokładnie w ten punkt bólu, zamieniając większość operacji na kontrolowaną pracę z repozytorium Git.
Chmura, Kubernetes i mikroserwisy: zmiana reguł gry
Przejście do chmury i Kubernetesa spowodowało, że infrastruktura stała się wyjątkowo dynamiczna. Zniknęły serwery „pod biurkiem”, ale pojawiły się klastry, autoskalery, setki manifestów YAML, CRD i operatorów. W świecie mikroserwisów każda aplikacja to kombinacja kilkunastu zasobów: Deployment, Service, Ingress, ConfigMap, Secret, RoleBindings i tak dalej.
Tego nie da się sensownie ogarniać ręcznie ani „klikologią” w panelu chmurowym. Próba zarządzania wszystkim z poziomu pojedynczych pipeline’ów CI/CD prowadzi do rozsynchronizowania stanu: coś jest w pipeline, coś jest w Terraformie, coś ktoś poprawił ręcznie na klastrze, a coś w ogóle żyje tylko w czyjejś głowie. Jeśli dodać do tego kilka regionów, środowiska testowe i klientów z osobnymi instalacjami, sytuacja staje się nie do utrzymania bez jednolitego modelu operacyjnego.
GitOps zakłada, że cała konfiguracja i stan docelowy systemu jest zapisany deklaratywnie i przechowywany w Git. Klastry, aplikacje i konfiguracje nie „żyją własnym życiem” – żyją tak, jak zapisano to w repozytorium. Kontrolery GitOps stale porównują rzeczywisty stan z pożądanym i przeprowadzają rekonsyliację. Przy dynamicznej infrastrukturze to często jedyny sposób, żeby mieć nad nią realną kontrolę bez dławienia się w narzędziach.
Git jako jedyne „źródło prawdy” – mit czy konieczność przy skali planetarnej
Hasło, że Git jest „single source of truth”, brzmi jak marketing. Jednak w praktyce, przy kilkudziesięciu klastrach rozsianych po różnych regionach, brak jednego źródła prawdy jest dużo droższy niż jego utrzymanie. Bez centralnego, zaufanego miejsca, w którym opisany jest docelowy stan, każda awaria wymaga dochodzenia: który klaster, którą wersję, z jaką konfiguracją, kto zmienił, czym to zdeployował.
Git nadaje się na źródło prawdy nie dlatego, że jest modny, ale dlatego, że:
ma wbudowaną historię zmian i autorów,
wymusza workflow oparty na commitach, gałęziach, code review,
łatwo integruje się z narzędziami automatyzacji i CI,
jest prosty technologicznie, dobrze znany deweloperom i adminom.
Przy skali „planetarnej” – setki klastrów, regiony, edge, środowiska klientów – GitOps umożliwia traktowanie całej infrastruktury jak kodu. Zamiast mieć 100 różnych miejsc konfiguracji, zespoły zarządzają zestawem repozytoriów, które opisują całość w sposób powtarzalny i przeglądalny. Nie jest to mit, ale też nie jest to darmowe: wymaga dyscypliny, konwencji i dobrej architektury repozytoriów.
„GitOps jako buzzword” kontra twarde korzyści operacyjne
Poziom szumu wokół GitOps jest spory. Część firm deklaruje „GitOps”, bo używa Gita i ma jakiś pipeline CI/CD. To jeszcze nie jest GitOps. Rzeczywisty zysk pojawia się wtedy, gdy:
declaratywny stan środowiska jest kompletny i przechowywany w Git,
kontroler GitOps w sposób ciągły synchronizuje klastry ze stanem w repo,
wszystkie zmiany przechodzą przez proces commit → review → merge → rekonsyliacja.
W zamian organizacja zyskuje:
audytowalność – każda zmiana jest śledzona w historii commitów,
odtwarzalność – łatwo odtworzyć stan sprzed incydentu,
spójność – środowiska nie „odjeżdżają” od siebie po cichu,
automatyczny drift correction – ręczne zmiany w klastrze są nadpisywane stanem z Git.
Bez tych elementów GitOps pozostaje buzzwordem. Kiedy jednak te zasady rzeczywiście stosuje się w praktyce, organizacje raportują niższą liczbę incydentów, krótszy czas odtworzenia środowisk i łatwiejszy onboarding nowych ludzi, bo „wszystko jest w repo”.
Przykład z praktyki: zespół dławiony change managementem
Typowa historia: firma ma już „DevOps”, CI/CD, Jenkinsy lub GitHub Actions, automatyczne buildy. Jednak każdy change na produkcję wymaga tony ticketów, zgód, screenów z pipeline’a i dodatkowych spotkań. Trwa to dłużej niż samo wdrożenie. Każda poprawka bezpieczeństwa jest przepychana tygodniami, bo proces audytowy nie ufa temu, co dzieje się w CI/CD.
Przy wdrożeniu GitOps część tej frustracji znika. Dział bezpieczeństwa i compliance dostaje jasny punkt odniesienia: repozytoria Git jako rejestr zmian. Zamiast sprawdzać, co robił każdy pipeline, zespół audytowy patrzy na pull requesty i polityki branch protection. Zgody mogą dotyczyć mergowania PR-ów, a nie „kliknięcia deploy”. CI nadal buduje obrazy, ale to Git – poprzez zmianę manifestów – inicjuje wdrożenie. Zamiast ręcznego przepychania ticketów w kilku systemach, cała logika zmian skupia się wokół jednego, łatwego do przejrzenia narzędzia.
Czym faktycznie jest GitOps – definicja bez marketingu
Deklaratywny stan w Git kontra ręczne zmiany i „klikologia”
GitOps to wzorzec operacyjny, w którym:
pożądany stan systemu (klastrów, aplikacji, konfiguracji) jest zapisany deklaratywnie,
ten stan jest przechowywany w repozytoriach Git,
specjalny kontroler dba o to, aby rzeczywisty stan środowiska był równy temu z Git.
Deklaratywność oznacza, że opisujemy co ma działać i jak ma wyglądać (np. „5 replik tej aplikacji, z tym limitem CPU, z tym ingress”), a nie jak krok po kroku dojść do tych ustawień. Znika potrzeba pisania kolejnych skryptów „deploy.sh” lub logowania się na serwery i klikania konfiguracji. Zamiast tego modyfikuje się pliki YAML/JSON/Helm i commitujemy zmiany do Git.
Manualne poprawianie zasobów w klastrze kubectl-em staje się antywzorcem. Można zrobić hotfix, ale jeśli nie trafi on do repozytorium, zostanie nadpisany przy najbliższej rekonsyliacji. Ten „sztywny” model na początku bywa niewygodny, ale znakomicie redukuje klasę błędów wynikających z ręcznych, nieudokumentowanych zmian.
Pętla rekonsyliacji: kontroler pilnujący stanu z repozytorium
Serce GitOps stanowi tzw. pętla rekonsyliacji. Kontroler GitOps (np. Argo CD, Flux):
cyklicznie (lub zdarzeniowo) pobiera manifesty z repozytorium,
porównuje je z aktualnym stanem klastra,
aplikuje różnice, aby doprowadzić klastry do stanu opisanego w Git,
raportuje status synchronizacji i ewentualne błędy.
Jeśli ktoś zmieni coś ręcznie w klastrze – na przykład podniesie liczbę replik z 3 do 10 – kontroler wykryje różnicę względem repo i przywróci wartość 3. To radykalnie zmienia odpowiedzialność: stan „prawdziwy” to ten z Gita, a klaster ma być jedynie odzwierciedleniem. Z punktu widzenia bezpieczeństwa i stabilności to ogromne uproszczenie, bo wreszcie wiadomo, gdzie szukać przyczyny problemu: w historii commitów, a nie w historii logowań do klastra.
GitOps a IaC (Terraform, Ansible) – uzupełnienie, nie zastępstwo
GitOps często mylony jest z infrastrukturą jako kod (IaC). W praktyce to dwa komplementarne elementy.
IaC (Terraform, Ansible, Pulumi, CloudFormation) najlepiej sprawdza się przy:
tworzeniu i aktualizacji zasobów chmurowych (VPC, sieci, load balancery, bazy danych),
zarządzaniu elementami infrastruktury poza klastrem.
GitOps z kolei koncentruje się na:
zarządzaniu stanem aplikacji i konfiguracją w klastrach,
ciągłej rekonsyliacji zasobów Kubernetes (i nie tylko),
traktowaniu wszystkiego, co żyje na klastrze, jako kodu w Git.
W dojrzałym układzie IaC buduje fundament (klastry, sieci, usługi zarządzane), a GitOps utrzymuje i rozwija to, co na tym fundamencie działa: aplikacje, serwisy, konfiguracje. Próba zastąpienia IaC czystym GitOps lub odwrotnie kończy się półśrodkami albo powielaniem pracy.
Trzy kluczowe cechy: audytowalność, odtwarzalność, odwracalność
GitOps wnosi do DevOps trzy bardzo praktyczne właściwości:
1. Audytowalność – każda zmiana infrastruktury i konfiguracji jest commitem. Widać autora, zakres, czas, historię dyskusji w PR. To często w zupełności wystarczy działom audytu i compliance, zamiast rozbudowanych narzędzi do śledzenia manualnych zmian.
2. Odtwarzalność – mając repozytorium z opisem stanu można:
zbudować nowe środowisko testowe „z niczego”,
odtworzyć produkcję po awarii klastra (lub regionu),
zasiać środowisko klienta na bazie sprawdzonego szablonu.
3. Odwracalność (rollback z commita) – cofnięcie zmian bywa tak proste jak revert commita lub przełączenie tagu. Kontroler GitOps wykona resztę. Nie trzeba ręcznie przywracać starej wersji configu ani desperacko szukać backupu sprzed tygodnia.
Gdzie GitOps nie ma sensu albo generuje przesadną złożoność
Nie każde środowisko potrzebuje GitOps. Są obszary, gdzie wdrożenie tej praktyki generuje więcej złożoności niż realnego zysku.
Małe, rzadko zmieniane systemy – jeśli infrastruktura jest stabilna, zmienia się raz na miesiąc i ma jednego opiekuna, ciężkie wdrażanie GitOps może być przesadą. Wystarczy porządny Terraform i spójna dokumentacja.
Systemy bez Kubernetesa – GitOps można stosować poza Kubernetesem, ale w praktyce większość dojrzałych narzędzi jest z nim mocno związana. Jeśli środowisko opiera się na klasycznych VM-ach i brak chęci do ich konteneryzacji, GitOps da ograniczony efekt.
Brak dyscypliny pracy z Git – jeśli zespół nie używa PR-ów, akceptuje pchanie na maina, nie robi review, GitOps szybko zmieni się w śmietnik. W takim zespole lepiej najpierw dopracować nawyki gitowe niż instalować kolejne kontrolery.
DevOps vs GitOps – ewolucja praktyk, nie religijna zmiana
DevOps jako kultura, GitOps jako wzorzec operacyjny
DevOps to podejście organizacyjne: kultura współpracy, ciągłe dostarczanie, automatyzacja, dzielenie się odpowiedzialnością. Nie jest to jedno narzędzie, ale zestaw zasad i praktyk. GitOps jest jednym z tych konkretnych wzorców, który implementuje DevOps w obszarze zarządzania infrastrukturą i wdrożeniami.
GitOps nie neguje DevOps – jest jego naturalną ewolucją w świecie chmury i Kubernetesa. Wprowadza większą dyscyplinę: wszystko jako kod, centralna kontrola w Git, pętla rekonsyliacji. Dla części zespołów to logiczny kolejny krok po zautomatyzowaniu buildów i podstawowych wdrożeń CI/CD.
GitOps precyzuje rolę CI/CD: build w CI, deployment sterowany przez Git
Tradycyjny model CI/CD często miesza dwa światy:
CI – budowanie, testowanie, skanowanie,
CD – wdrażanie na środowiska.
W większości instalacji pipeline CI robi „wszystko”: od budowy obrazu, po wykonanie kubectl apply na klastrze. GitOps rozdziela te odpowiedzialności.
Oddzielenie CI od CD w praktycznym GitOps
W modelu GitOps pipeline CI robi jedną rzecz: produkuje artefakt (obraz kontenera, paczkę Helm, manifesty), który ląduje w rejestrze. Deploy nie jest już „krokiem w pipeline”, tylko efektem zmiany w repo obserwowanym przez kontroler GitOps.
Typowy schemat:
CI buduje obraz, skanuje go i wrzuca do registry,
CI aktualizuje referencję w repo GitOps (tag obrazu, wersję chartu),
merge PR-a z tą zmianą uruchamia rekonsyliację w Argo CD / Flux,
kontroler aplikuje różnice na klastrze.
To przesunięcie ma parę konsekwencji. Po pierwsze, granica odpowiedzialności jest czytelna: CI dba o jakość artefaktu, a CD o stan środowiska. Po drugie, łatwiej jest sterować dostępem: pipeline budujący nie potrzebuje poświadczeń do klastra, wystarczą mu prawa do pushowania do repo oraz rejestru. Z punktu widzenia bezpieczeństwa i kosztów utrzymania to mniej ruchomych części.
Zmiana nawyków zespołu: „push na main” kontra PR + review
GitOps wymusza lepszą higienę pracy z Gitem. Nagle każda zmiana konfiguracji klastrów, secretsów czy limitów zasobów to nie „mały hotfix na produkcji”, tylko pełnoprawny commit.
Praktyczne konsekwencje w codziennej pracy:
deploy jest skutkiem merge’a, więc branch protection i review stają się realnym mechanizmem kontroli zmian infrastruktury,
znikają „szybkie poprawki przez konsolę” – jeśli ktoś je zrobi, kontroler i tak je cofnie,
zespół zaczyna myśleć o konfiguracji jak o kodzie aplikacji: PR-y, review, testy, standardy.
Na początku bywa to odczuwane jako spowolnienie. Po kilku tygodniach zwykle wychodzi, że dzięki spójnej historii w Git mniej czasu idzie na gaszenie pożarów i szukanie „kto, kiedy i dlaczego to zmienił”. W bilansie wychodzi taniej.
Źródło: Pexels | Autor: Sajeeb Anindo
Fundamentalne klocki GitOps – architektura w praktyce
Model pull kontra push – dlaczego to ma znaczenie
Kluczowe odróżnienie GitOps od klasycznego CD to model pull. Zamiast wypychać zmiany z pipeline’a do klastra, kontroler w klastrze sam pobiera stan z repo.
Z punktu widzenia bezpieczeństwa i kosztów operacyjnych:
nie trzeba utrzymywać złożonych poświadczeń do wielu klastrów w narzędziach CI,
każdy klaster ma swój kontroler, który ma tylko odczyt do repo (czasem z opcją zapisu dla statusów),
awaria CI nie blokuje rollbacku – rekonsyliacja działa dalej, dopóki repo i klaster żyją.
Model push (pipeline robi kubectl apply) jest prostszy na początek, ale skaluje się gorzej: więcej skryptów, więcej wyjątków, więcej miejsc, w których trzeba aktualizować tokeny i adresy endpointów. Przy trzech–czterech klastrach koszt utrzymania takiego rozwiązania zaczyna być wyraźnie wyższy niż postawienie jednego kontrolera GitOps na każdy klaster.
Repozytorium prawdy, kontroler, klaster – prosta, ale konsekwentna trójka
Minimalna architektura GitOps to trzy elementy:
Repozytorium Git – opisuje stan środowiska, często jako połączenie surowych manifestów, Helm chartów i/lub Kustomize.
Kontroler GitOps – co kilka sekund lub minut porównuje repo z klastrem.
Klaster docelowy – miejsce, gdzie działa aplikacja (Kubernetes, w niektórych narzędziach także inne platformy).
Reszta – system CI, skanery bezpieczeństwa, mechanizmy promocji między środowiskami – to „przystawki”. Jeśli ta trójka działa stabilnie i przewidywalnie, rozbudowa do pełnego ekosystemu idzie znacznie łatwiej i taniej.
Rekoncyliacja, dry-run i health-check – jak uniknąć ślepych wdrożeń
Dojrzała instalacja GitOps nie polega na bezrefleksyjnym „sync on commit”. Dobry kontroler oferuje co najmniej:
dry-run – możliwość sprawdzenia różnic między stanem w repo a klastrem bez ich zastosowania,
health-check – ocenę zdrowia aplikacji po wdrożeniu (np. status readiness/liveness podów, warunki CRD),
progress deadline – limit czasu, po którym nieudane wdrożenie jest oznaczane jako failed.
Dzięki temu łatwiej jest zaimplementować niedrogie mechanizmy bezpieczeństwa: automatyczne zatrzymywanie rolloutu, jeśli nowe pody nie startują, albo alerty do Slacka, gdy synchronizacja danego namespace’u od dłuższego czasu się nie udaje.
Bezpieczeństwo: kto może w ogóle dotknąć produkcji
GitOps wprowadza prosty, budżetowy model uprawnień. Zamiast zarządzać dziesiątkami ról w klastrze produkcyjnym, kontrola przesuwa się do Git:
zmiany w repo produkcyjnym mogą robić tylko osoby z prawem do mergowania PR,
dostępy do klastra są ograniczane do operatorów i kontrolerów GitOps,
audyty i przeglądy konfiguracji odbywają się na poziomie PR (często z automatycznymi checkami).
To często pozwala zmniejszyć liczbę ludzi mających bezpośredni dostęp do produkcji, a tym samym ograniczyć ryzyko przypadkowych zmian. Równocześnie skraca drogę dla programistów: nie muszą znać wszystkich tajników Kubernetesa, żeby zmienić zmienną środowiskową – wystarczy PR do odpowiedniego katalogu w repo.
Wybór narzędzi GitOps z perspektywy budżetu i progu bólu
Argo CD, Flux i reszta – krótkie porównanie bez marketingu
Rynek narzędzi GitOps jest dość szeroki, ale dla większości zespołów realny wybór sprowadza się zwykle do dwóch opcji: Argo CD i Flux.
Argo CD:
bogate UI webowe – łatwo pokazać menedżerom „co gdzie działa”,
większa złożoność na starcie, zwłaszcza przy hardeningu.
Flux:
mocno „kubernetesowy” – dużo CRD, konfiguracja przez YAML,
mniejszy narzut na zasoby klastra,
lepiej pasuje do filozofii „wszystko jako kod” (niewiele klikania),
UI wymaga dodatkowych klocków (np. Weave GitOps – w wersji community lub płatnej).
Przy małych i średnich środowiskach wybór często zależy od tego, czy koniecznie potrzebne jest UI. Jeśli zespół woli pracować z CLI/YAML i nie ma silnej potrzeby efektownego dashboardu, Flux będzie prostszy i tańszy w utrzymaniu. Jeśli trzeba pokazywać stan środowisk osobom nietechnicznym, Argo CD zwykle wygrywa wygodą.
Self‑hosted czy „GitOps as a Service” – kiedy płacić za wygodę
Na rynku pojawia się coraz więcej ofert „GitOps as a Service”: zarządzane instancje Argo CD/Flux, integracje z platformami chmurowymi, dodatki bezpieczeństwa. Kuszą tym, że „nie trzeba nic instalować”. Koszt rośnie jednak szybko – zwłaszcza przy wielu klastrach.
Praktyczny kompromis:
mały zespół / 1–3 klastry – zazwyczaj wystarczy self‑hosted Argo CD lub Flux; koszt to kilka godzin konfiguracji i okresowe update’y,
kilkadziesiąt klastrów, duża organizacja – warto rozważyć managed, jeśli brakuje ludzi do utrzymania centralnej platformy; w tym wypadku cena bywa niższa niż etat doświadczonego SRE.
Jeśli budżet jest ciasny, sensowną strategią jest start od self‑hosted i ewentualna migracja do usługi zarządzanej, gdy „ból utrzymaniowy” przekroczy konkretne progi (np. czas poświęcany na upgrade’y, liczbę incydentów wynikających z błędnej konfiguracji).
Sam kontroler GitOps to dopiero początek. Prawdziwe oszczędności czasu i nerwów pojawiają się, gdy do gry wchodzą narzędzia wspomagające:
Kustomize – dobre, gdy ten sam zestaw manifestów ma trafić na wiele środowisk z drobnymi różnicami (namespace, limity, adresy zewnętrzne). Prosty i wbudowany w kubectl, więc nie generuje dodatkowych kosztów.
Helm – sprawdza się do pakowania całych aplikacji i korzystania z gotowych chartów społeczności. W GitOps często wykorzystywany razem z Argo CD/Flux, które potrafią same renderować chart.
OPA / Kyverno – policy engines wymuszające standardy (np. brak deployów z :latest, ograniczenia dla privileged pods). To tani sposób na „kodeks drogowy” dla Kubernetesa i zmniejszenie liczby głupich błędów.
W praktyce budżetowy zestaw startowy to zwykle: Flux + Kustomize lub Argo CD + Helm. Policy engines można dołożyć później, gdy podstawy są opanowane.
Projektowanie repozytoriów GitOps – wzorce i antywzorce
Repo single‑tenant („environment per repo”) kontra multi‑tenant
Najczęstsza decyzja architektoniczna w GitOps dotyczy tego, jak podzielić repozytoria. Dwa skrajne podejścia to:
repo per środowisko (np. infra-dev, infra-staging, infra-prod),
jedno repo dla wielu środowisk z podziałem katalogów (np. environments/dev, environments/prod).
Repo per środowisko daje mocniejszą izolację – inne uprawnienia, inne zasady review. Dobrze sprawdza się w firmach z silnym podziałem ról, gdzie produkcja jest szczególnie chroniona. Wadą jest powielanie plików i większy wysiłek przy zmianach globalnych.
Wspólne repo jest tańsze w utrzymaniu: mniej miejsc do synchronizacji zmian, prostsza nawigacja. Wymaga jednak dobrej kontroli uprawnień (np. reguł, które ograniczają, kto może modyfikować katalog prod) i rozsądnego nazewnictwa katalogów.
Oddzielenie konfiguracji aplikacji od konfiguracji klastra
Dobrym wzorcem jest rozdzielenie repozytoriów na co najmniej dwie klasy:
repo klastra – opisuje sam klaster: CRD, operatory, systemowe namespacesy, monitoring, logowanie, ingress controllery,
repo aplikacji – opisuje konkretne aplikacje: deploymenty, service’y, ingressy, configMapy.
Dzięki temu update np. Prometheusa czy Ingress NGINX nie miesza się w historii z deployami aplikacji biznesowych. Ułatwia to rollbacki, audyty i delegowanie odpowiedzialności (inna osoba opiekuje się platformą, inna aplikacjami). Koszt początkowy to dwa–trzy dodatkowe repozytoria, ale bardzo szybko się zwraca, gdy środowisk i usług zaczyna przybywać.
Struktura katalogów: proste szablony zamiast „lasu YAML‑i”
W repozytoriach GitOps chaos pojawia się szybciej niż w kodzie aplikacji, bo YAML‑e lubią się mnożyć. Pomaga przyjęcie prostych, powtarzalnych struktur, np.:
Chodzi o to, aby nowa osoba po 15 minutach była w stanie znaleźć miejsce, w którym powinna zmienić np. zmienną środowiskową dla konkretnej aplikacji. Każda zaoszczędzona godzina onboardingowa to realny zysk – przy większej rotacji zespołu zwłaszcza.
Antywzorce: monorepo wszystkiego i „katalog śmietnik”
Dwa schematy szybko podnoszą koszty utrzymania:
jedno monorepo na wszystko (klastry, aplikacje, IaC, Terraform, Ansible) – na początku wygodne, po pół roku każda zmiana wymaga dotykania dziesiątek plików, a pipeline’y trwają wieczność,
katalog „misc” / „common” bez jasnych zasad – ląduje tam wszystko, czego nikt nie wie gdzie włożyć, a potem nikt nie wie, czy coś jest jeszcze używane.
Lepszy jest umiarkowany podział na kilka logicznych repozytoriów niż jeden „worek bez dna”. Nie trzeba od razu projektować idealnej taksonomii – wystarczy na bieżąco przenosić powtarzające się wzorce i czyścić nieużywane katalogi, trzymając się prostych zasad nazewnictwa.
Strategie wersjonowania: tagi, branche, katalogi
Dla zespołów przyzwyczajonych do „promocji builda” między środowiskami kluczowe jest ustalenie, jak to przełożyć na GitOps. Najczęstsze opcje:
branch per environment – np. dev, staging, prod z cherry-pickiem commitów; elastyczne, ale wymaga dyscypliny przy merge’ach,
