Case study
AI Outstaff za web development: automatizacija Docker test okruzenja uz Codex i n8n
Web developer je trosio previse vremena na posao koji je imao malo veze sa web developmentom.
Same aplikacije nisu bile nuzno komplikovane za pokretanje, ali njihova test okruzenja jesu. Razliciti projekti zavisili su od razlicitih kombinacija PostgreSQL-a, MongoDB-a, Elasticsearch-a i drugih servisa. Kontejneri su morali da se ponovo grade, Docker Compose definicije da se prilagodjavaju, a svaki novi projekat znaćio je jos jedan krug podesavanja infrastrukture.
Pojedinacne promene su obicno bile male. Problem je bila njihova ucestalost.
Dodavanje projekta moglo je da znaci pisanje jos jednog dela u docker-compose.yml. Promena zavisnosti mogla je da zahteva izmene image-a, volume-a, porta ili definicije servisa. Testiranje sajta sa realisticnim podacima cesto je pocinjalo tako sto je najpre trebalo popraviti okruzenje, pre nego sto uopste mogne da pocne debagovanje aplikacije.
Ovo je bio dobar kandidat za AI automatizaciju, ali samo davanje developeru pristupa AI coding asistentu ne bi resilo osnovni problem. Asistent je prvo morao da razume kako ta okruzenja treba da rade.
Problem je bilo operativno znanje
Ponavljajuci workflow je izgledao otprilike ovako:
flowchart LR
A["Developer needs to run or debug a site"] --> B["Inspect project dependencies"]
B --> C["Adjust Docker Compose"]
C --> D["Rebuild containers"]
D --> E["Fix environment differences"]
E --> F["Start application debugging"]
Nijedan od ovih koraka nije posebno težak za iskusnog DevOps inzenjera.
Za web developera, medjutim, oni stvaraju stalno prebacivanje konteksta. Jos vaznije, iste infrastrukturne odluke se donose iznova i iznova kroz projekte.
Nismo hteli da pravimo veliku internu razvojnu platformu samo da bismo uklonili ovaj posao. Umesto toga, koristili smo Codex kao operativni interfejs i znanje iz DevOps-a koje mu je bilo potrebno premestili u sam projekat.
Najpre je DevOps inzenjer naucio agenta kako projekat radi
Prva faza je namerno bila vodjena od strane coveka.
DevOps inzenjer je pregledao postojeci razvojni workflow, identifikovao ponavljajuce operacije i pripremio Codex da radi unutar projekta.
Workspace je sadrzao trajna projektna uputstva kao sto su:
Vazan fajl za svakodnevnu upotrebu bio je SKILL.md.
Umesto da se oslanjamo na to da developer svaki put objasnjava okruzenje, dokumentovali smo rutinske operacije koje se ocekivalo da Codex izvodi i pravila koja treba da prati.
Za ovaj slucaj, te rutine su bile usredsredjene na posao koji je ranije prekidao razvoj:
- dodavanje novog projekta u Docker-based razvojno okruzenje;
- kreiranje ili menjanje potrebnih delova
docker-compose.yml; - prilagodjavanje kontejnera kada se promene zavisnosti projekta;
- ponovno gradenje i podesavanje test okruzenja oko servisa kao sto su PostgreSQL, MongoDB i Elasticsearch;
- obavljanje ponavljajuceg rada na okruzenju koji je potreban pre nego sto sajt moze da se testira ili debaguje.
Poenta nije bila da Codex “zna DevOps” uopsteno. Poenta je bila da mu se da operativni kontekst za ovo konkretno razvojno okruzenje.
n8n je postao developer interfejs
Developer nije morao direktno da radi sa Codex CLI-jem.
Povezali smo n8n Chat workflow sa trajnom Codex sesijom koja je radila na namenskom hostu.
flowchart TD
A["Developer"] --> B["n8n Chat"]
B --> C["Encode request"]
C --> D["SSH"]
D --> E["n8n-codex-chat.sh"]
E --> F["Project profile"]
F --> G["Codex workspace"]
G --> H["Persistent Codex session"]
H --> I["Docker project files"]
n8n workflow je namerno mali.
Prima developerovu poruku, enkodira je i izvrsava fiksni wrapper kroz SSH. Wrapper bira odgovarajuci project workspace i nastavlja postojecu Codex sesiju.
Koncepcijski, udaljeno izvrsavanje je:
| |
Project profile mapira taj zahtev na odgovarajuci workspace i sesiju:
Sam prompt se prosledjuje Codex-u preko standardnog ulaza, umesto da se interpolira u udaljenu shell komandu.
Zasto smo Codex sesiju zadrzali trajnom
Bezustavno AI workflow bi vratio veliki deo originalnog problema.
Svaki zahtev bi morao da ima dovoljno konteksta da objasni strukturu projekta, prethodne odluke i ocekivani nacin rada. n8n bi tada morao da ima sopstveni memorijski sloj ili poseban mehanizam za rekonstruisanje tog konteksta.
Umesto toga, Codex sesija poseduje istoriju razgovora.
U ovom dizajnu nema n8n Memory noda.
Workspace obezbedjuje trajna uputstva. Trajna Codex sesija obezbedjuje kontinuitet razgovora. n8n je samo transport i korisnicki interfejs.
Ovo takodje cini vise projekata upravljivim. Odvojeni profili mogu da upucuju na odvojene workspaces i Codex sesije bez pravljenja drugog automation workflow-a za svaki projekat.
Zahtevi koji ciljaju istu sesiju serijalizuju se pomocu lock-a, dok nezavisni profili mogu da rade odvojeno.
Sta se promenilo za developera
Ranije je tipican zahtev izgledao kao infrastrukturni zadatak:
Dodaj ovaj projekat u development stack, proveri njegove zavisnosti, azuriraj Docker Compose, pokreni kontejnere, pa onda mogu da pocnem da debagujem aplikaciju.
Nakon podesavanja, developer moze umesto toga da opise zeljeni rezultat kroz n8n.
Na primer:
ili:
Codex prima zahtev unutar workspace-a u kome su te konvencije vec dokumentovane.
Developer i dalje pregleda dobijene izmene, ali vise ne mora iznova da rekonstruise infrastrukturno resenje za svaku rutinsku operaciju.
DevOps uloga nije nestala
Ovo razlikovanje je vazno.
Korisna automatizacija nije nastala tako sto je n8n povezan sa AI modelom i zamoljen da upravlja Docker-om.
DevOps inzenjer je prvo morao da:
- razume postojeci sistem;
- identifikuje koje su operacije ponavljajuce;
- uspostavi strukturu projekta i operativna pravila za Codex;
- pretvori ta pravila u reusable vestine i procedure;
- konfigursie putanju izvrsavanja i granice projekta.
Kada je taj posao bio zavrsen, developer je mogao da ponovo koristi DevOps znanje bez potrebe za DevOps inzenjerom za svaku malu promenu.
Novi ili neuobicajeni infrastrukturni problemi i dalje mogu da se vrate inzenjeru. Ako ponavljajuci izuzetak postane rutina, odgovarajuca procedura moze da se doda u SKILL.md i postaje dostupna za buduce zahteve.
flowchart LR
A["New infrastructure problem"] --> B["DevOps engineer solves it"]
B --> C["Procedure becomes repeatable"]
C --> D["Add or update SKILL.md"]
D --> E["Developer can reuse it through n8n"]
Ovo je deo koji pristup cini korisnim kroz vreme. Automatizacija moze da akumulira operativno znanje umesto da svaki zahtev pocinje od generickog prompta.
Rezultat
Glavni rezultat nije bila nova Docker platforma. Bio je to uklanjanje ponavljajuce kategorije infrastrukturnog rada iz normalnog workflow-a developera.
Rutinske promene Docker okruzenja sada mogu da se zahtevaju kroz n8n koristeci uobicajene opise zadataka. Codex radi sa projektnim uputstvima specificnim za projekat i trajnim kontekstom koji je pripremio DevOps.
To je promenilo podelu posla:
| |
Namerno nismo merili rezultat kao vestacko procentualno poboljsanje. Korist je vise prakticna: ponavljajuce podesavanje infrastrukture vise ne mora rucno da se resava svaki put kada developer pokrene ili promeni projekat.
Zasto ovo odgovara AI Outstaff modelu
Tradicionalni outstaffing dodaje jos jednu osobu timu.
U ovom slucaju, relativno mala kolicina DevOps inzenjeringa je upotrebljena drugacije. Inzenjer je jednom uspostavio operativni model, enkodovao ponavljajuce znanje u projekat i to znanje uciniio dostupnim developeru kroz AI agenta.
Ljudski inzenjer i dalje ostaje odgovoran za tezi deo: infrastrukturne odluke, nove obrasce i izuzetke.
Codex obavlja posao koji je vec postao rutina.
Za timove koji vode mnoge male ili srednje web projekte sa razlicitim Docker zavisnostima, ovo moze biti prakticnije nego bilo drzati DevOps inzenjera ukljucenog u svaku promenu okruzenja ili ocekivati da web developeri sami odrzavaju kompletnu infrastrukturu.