Terraform i infrastruktura jako kod Łódź

Co zostaje w środowisku po roku kampanii

Sklep, który prowadzi kilkanaście akcji handlowych rocznie, ma w konsoli dostawcy zapis tych akcji, tylko nikt go tak nie nazywa. Przed każdą powstaje coś na próbę: kopia środowiska, na której da się sprawdzić nową wtyczkę, maszyna do przetestowania integracji z kolejną porównywarką, druga baza z danymi sprzed tygodnia, żeby zobaczyć, jak zachowa się zmiana w cenniku.

Każda z tych rzeczy była potrzebna i każda została utworzona przez kogoś, kto miał na to dobry powód. Problem zaczyna się po akcji, a dokładniej w chwili, w której ktoś zadaje pytanie, czy to jeszcze jest potrzebne. Odpowiedź brzmi zwykle: chyba nie, ale nie mam pewności. I to zdanie decyduje o tym, że zasób zostaje na kolejny rok.

Firma nie płaci więc za bałagan, tylko za brak pewności. Skasowanie czegoś, co mogłoby jeszcze pracować, jest ryzykowne, a sprawdzenie tego bywa droższe niż utrzymywanie zasobu przez następne dwanaście miesięcy. Dopóki tak jest, każda rozmowa o porządkach kończy się przesunięciem terminu.

Skąd biorą się zasoby, których nikt nie kasuje

Co powstaje	Po co	Dlaczego zostaje	Co robi z tym opis
Kopia środowiska przed akcją	sprawdzenie zmiany bez ruszania sprzedaży	nikt nie wie, czy ktoś jeszcze z niej korzysta	powstaje z datą wygaszenia i gaśnie sama
Maszyna pod jedną integrację	próba z nowym marketplace	integracja weszła, maszyna została	figuruje w module z przypisanym właścicielem
Migawka zrobiona na wszelki wypadek	możliwość powrotu po zmianie	nie ma terminu, więc nie ma powodu do usunięcia	ma okres przechowywania zapisany w opisie
Dysk po skasowanej maszynie	nic, jest pozostałością	nikt go nie widzi w rachunku jako osobnej pozycji	wychodzi na listę przy pierwszym wciągnięciu zasobów
Adres publiczny zarezerwowany doraźnie	wystawienie czegoś na czas próby	kosztuje mało i przez to nie zwraca uwagi	należy do środowiska i znika razem z nim
Konto techniczne od dostawcy wtyczki	jednorazowa konfiguracja	zostaje, bo nikt nie wie, czy wolno je zamknąć	trafia na listę dostępów przechodzoną kwartalnie

Kolumna trzecia jest tą, dla której ta tabela w ogóle powstaje. Żadna z tych pozycji nie została zostawiona świadomie i żadnej nie da się usunąć bez sprawdzenia. To jest praca, którą opis w plikach wykonuje raz i za wszystkich.

Dlaczego skasowanie jest trudniejsze od postawienia

Postawienie czegokolwiek w konsoli dostawcy zajmuje kilka minut i nie wymaga niczyjej zgody. Usunięcie tego samego wymaga odpowiedzi na trzy pytania: czy coś jeszcze się do tego odwołuje, czy zniknie razem z tym coś, czego nie chcemy stracić, i kto weźmie na siebie skutki, jeśli odpowiedzi były błędne.

W środowisku klikanym żadne z tych pytań nie ma dobrego źródła. Konsola pokazuje bieżący stan, a nie powiązania, i nie mówi, kto dany zasób uruchomił ani po co. Człowiek, który to wie, zwykle pracuje już gdzie indziej albo pamięta połowę.

Opis w plikach odwraca tę asymetrię. Zasoby należą do środowiska, powiązania widać w kodzie, a lista zmian przed wykonaniem pokazuje z nazwy wszystko, co ma zniknąć. Decyzja o usunięciu przestaje być odwagą i staje się przeczytaniem listy, a to jest różnica, przez którą takie porządki w ogóle dochodzą do skutku.

Co daje termin życia wpisany w samo środowisko

Środowisko powoływane na próbę dostaje u nas dwie rzeczy, których zwykle nie ma: nazwisko osoby, która o nie prosiła, i datę, po której ma zniknąć. Obie są wartościami w opisie, więc nie zależą od tego, czy ktoś o nich pamięta.

Skutek jest widoczny nie w rachunku, tylko w sposobie pracy. Zespół przestaje oszczędzać na powoływaniu środowisk, bo powołanie kolejnego przestaje być zobowiązaniem na lata. Zamiast jednej kopii, która żyje własnym życiem i po roku niczego już nie odwzorowuje, powstaje kilkanaście krótkich, każda z aktualnym stanem produkcji.

Przedłużenie terminu jest zmianą jednej wartości i przechodzi tą samą drogą co każda inna zmiana, czyli przez listę do zatwierdzenia. Dzięki temu na pytanie, dlaczego środowisko sprzed dziewięciu miesięcy nadal pracuje, zawsze jest odpowiedź, i zwykle jest to dobra odpowiedź.

Na co idą te dwa dni pracy

Pierwszy ruch to przeniesienie do kodu tego, co już pracuje, i doprowadzenie do stanu, w którym lista zmian nie pokazuje żadnej różnicy. Ten moment jest ważniejszy, niż wygląda: dopóki widnieją na niej rozbieżności, opis jest propozycją, a nie źródłem prawdy. Wychodzi z tego również pełny spis zasobów, w tym pozycji, których nikt nie potrafi przypisać do żadnej akcji.

Drugi to wyodrębnienie powtarzalnych elementów, przede wszystkim samego środowiska na próbę, które w takiej firmie powstaje najczęściej. Trzeci to wspólny stan zamknięty blokadą, żeby dwie osoby pracujące tego samego popołudnia nie nadpisały sobie zmian. Czwarty dotyczy kluczy do bramki płatniczej i do przewoźników, które wychodzą z plików do menedżera sekretów.

Ostatni element to potok wykonujący przyjęte zmiany, żeby żadna nie startowała z prywatnego komputera. Kalendarzowo rozkłada się to zwykle na dwa tygodnie, bo między krokami czekamy na potwierdzenia po Waszej stronie, a przerwa w sprzedaży nie jest do tego potrzebna.

Kiedy odradzamy tę pracę

Gdy sklep stoi w całości na gotowej platformie u dostawcy, a Waszym jedynym zasobem jest jedna maszyna z integracjami, bo wtedy powtarzalność, czyli cała przewaga tej pracy, nie ma zastosowania. Gdy sklep ma za kwartał przejść na inną platformę i całe środowisko i tak powstanie od nowa. Gdy nikt po Waszej stronie nie zamierza czytać listy zmian, a jednocześnie utrzymanie ma zostać wewnątrz firmy.

Nie zgadzamy się także na dopisanie tego do innego zlecenia jako pozycji dodatkowej. Opis wymaga osobnych godzin i osobnych prób, a robiony przy okazji przestaje odpowiadać rzeczywistości w kilka tygodni, czyli wraca tam, skąd wyszedł, tylko za Wasze pieniądze.

Co zostaje u Was

Repozytorium, moduły, opis uruchomienia środowiska od zera i procedura powrotu po nieudanej zmianie, wszystko po Waszej stronie od pierwszego dnia. Do tego lista dostępów awaryjnych z nazwiskami oraz zapis pierwszej zmiany przeprowadzonej tą drogą, przez którą przechodzimy razem z osobą mającą zatwierdzać kolejne.

Bieżące prowadzenie zasobów opisuje administracja chmurą, dzierżawę Microsoftu Azure dla firm, a układ z maszyną przy hali chmura hybrydowa. Łączniki uruchamiane na tak opisanych maszynach pakujemy wcześniej zgodnie z tym, co pokazujemy przy konteneryzacji Docker, a nowe środowisko warto opisać plikami już w trakcie migracji do chmury.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026