W pewnym momencie każdy większy projekt infrastruktury jako kod dochodzi do punktu, w którym zmiany przestają być lokalne. Aktualizacja wersji modułu, zmiana kontraktu wejściowego albo migracja pomiędzy podejściami architektonicznymi wymaga wtedy modyfikacji w wielu miejscach jednocześnie oraz często w kilku repozytoriach.

W teorii są to “proste” zmiany: zmiana wersji, usunięcie parametru, dodanie nowego bloku konfiguracyjnego. W praktyce jednak ręczne refaktoryzowanie takich zmian jest czasochłonne, podatne na błędy i trudne do bezpiecznego review. Skrypty oparte o grep, sed czy inne operacje tekstowe pomagają tylko do pewnego momentu. Nie rozumieją one struktury konfiguracji, są wrażliwe na formatowanie i, co najważniejsze, nie są deterministyczne. Każde kolejne uruchomienie takiego skryptu wymaga ponownej weryfikacji efektu końcowego.

Przez lata pracy miałem okazję uczestniczyć w wielu projektach i widzieć różne podejścia do organizacji infrastruktury jako kod przy użyciu Terraforma. Niektóre z nich działały lepiej, inne gorzej. Część świetnie sprawdzała się na początku, ale w miarę rozwoju projektu, przy dodawaniu nowych zasobów pod presją czasu i priorytetów organizacji, kod stawał się trudny w utrzymaniu. Infrastruktura nadal była zapisana w kodzie, ale każda zmiana zajmowała więcej czasu, a refaktoryzacja przestawała być opłacalna.

Dlaczego kolejny plugin Gradle

Ostatnio chciałem poszerzyć swoją wiedzę o Build Scanach, Develocity i ich praktycznym zastosowaniu, dlatego zacząłem przerabiać kursy na naszej platformie DPE University. Na co dzień mam styczność z Develocity od strony operacyjnej i produkcyjnej – utrzymuję między innymi instancje open source, więc zależało mi na lepszym zrozumieniu produktu, a zwłaszcza użycia od strony użytkowników, w mojej codziennej pracy inżyniera.

Aby usystematyzować zdobytą wiedzę, postanowiłem zbudować projekt zgodny z best practices omawianymi na kursach. Równolegle pracowałem nad mikroserwisem w Spring Boot, generowanym ze Spring Initializr, i zauważyłem brak pluginu Gradle, który automatyzowałby ten proces w sposób przyjazny build cache i CI/CD. W efekcie każdy nowy projekt wymagał ręcznej konfiguracji. Chciałem to uprościć i zbliżyć doświadczenie do znanego gradle init – ale w wersji dla Spring Boot.

Witaj na moim blogu!

Stworzyłem go, aby dokumentować i dzielić się swoimi osobistymi doświadczeniami w budowaniu rozwiązań z zakresu architektury chmurowej, platform engineeringu oraz AI-native tooling.

Znajdziesz tu materiały, które nie są wprowadzeniami ani tutorialami, ale próbą uchwycenia sprawdzonych wzorców i decyzji w realnych, produkcyjnych kontekstach.

Czego możesz się spodziewać

• Praktycznych, opartych na realnych projektach wpisów skupionych na implementacji.
• Uporządkowanych wzorców do budowania skalowalnych platform.
• Technicznych insightów dotyczących Gradle, OpenTofu, workflowów GitOps i AI-native systems.
• Czystych, minimalistycznych, pozbawionych zbędnego szumu treści.

Zaczynamy

Żeby uszanować Twój czas oraz nie zostawiać Cię z samym powitaniem i zapowiedzą, co będzie na blogu, przedstawiam, jak uruchomiony jest ten blog. W pełni automatycznie i w sposób deklaratywny. W myśl z jednej moich ulubionych zasad: