Release koji ovisi o sjećanju jedne osobe nije proces. DevOps i CI CD trebaju isporuku pretvoriti u ponovljiv tok u kojem je poznato što je promijenjeno, što je provjereno, tko donosi odluku o puštanju i kako se sustav vraća ako promjena naruši važan poslovni tok.
Broj kontrola pritom ne mora biti jednak za svaki deployment. Cilj je postaviti provjere prema riziku promjene i najčešćim načinima na koje vaš release proces zakazuje.
Svaka produkcijska promjena treba imati jasan put. Commit pokreće ili ulazi u pipeline, pipeline stvara verzionirani artefakt, a taj se artefakt uz rezultate provjera veže uz deployment. Nakon toga tim može odgovoriti na osnovna operativna pitanja:
Testirani kod mora biti isti kod koji odlazi u produkciju. Ručni ponovni build prije produkcije otvara mogućnost da se isporuči nešto drugo od onoga što je provjereno. Razlike između razvojnih, testnih i produkcijskih okruženja trebaju biti u konfiguraciji i tajnama, a ne u novom ručnom sastavljanju aplikacije.
Takav trag je posebno vrijedan kada ERP, integracije i poslovni moduli dijele podatke ili redoslijed obrade. Tehnički ispravan deployment može i dalje prekinuti proces ako promijeni očekivani format poruke, pravilo obrade ili redoslijed koraka. U takvim slučajevima treba provjeravati i vezu aplikacije s poslovnim modulima povezanim s ERP-om , ne samo dostupnost servisa.
CI CD gate je provjera koja mora dati prihvatljiv signal prije sljedećeg koraka releasea. Gate nije cilj sam po sebi. Ima smisla kada hvata poznatu vrstu pogreške dovoljno rano da tim može reagirati bez većeg prekida.
Osnovni pipeline može sadržavati sljedeći redoslijed:
Nisu sve promjene jednake. Ispravak teksta obično nema isti utjecaj kao promjena obračunskog pravila, integracije prema partneru ili strukture podataka. Promjena višeg rizika može tražiti dodatni review, feature flag ili postupan rollout. Feature flag odvaja puštanje koda od uključivanja funkcije, pa poslovni vlasnik i tim mogu kontrolirati kada se funkcija aktivira. Postupan rollout najprije izlaže novu verziju manjem dijelu korisnika ili prometa te ograničava posljedicu ako signal odstupa.
Aplikaciju je često moguće vratiti na prethodnu verziju brzo. Podatke je teže vratiti bez gubitka ili dodatnog rada. Zato deployment koji uključuje bazu ne treba promatrati kao jednu naredbu.
Sigurniji obrazac je unatrag kompatibilna promjena:
Ovaj pristup stvara više koraka i privremeno povećava složenost. Njegova korist nije u tome da uklanja svaki rizik, nego da rollback aplikacije ostane moguć bez automatskog vraćanja cijele baze. Za rizične migracije korisno je uvježbati postupak na kontroliranom okruženju i unaprijed odrediti što se promatra tijekom i nakon promjene.
Uspješan pipeline potvrđuje završetak predviđenih koraka automatizacije. Ne potvrđuje sam po sebi da produkcijski korisnik može završiti važan posao. Nakon releasea potrebno je promatrati tehničke i poslovne signale.
Tehnički signali mogu uključivati pogreške, latenciju i potrošnju resursa. Poslovni signali ovise o sustavu, ali mogu uključivati uspješno kreiranje dokumenta, prolazak integracije ili obradu zahtjeva koji je važan za dnevni rad. Sustav može odgovarati na zahtjeve, a da važna funkcija ipak ne radi zbog konfiguracije, dozvola ili promijenjenog podatka.
Za svaki deployment unaprijed odredite:
Odgovornost je zajednička, ali uloge nisu iste. Razvojni tim poznaje promjenu, operativa ponašanje sustava, a poslovni vlasnik posljedicu prekida procesa. Release proces treba spojiti te informacije, a ne prebaciti cijeli rizik na jednog od njih.
Tim ne mora odmah graditi složenu platformu. Početni, koristan DevOps tok može biti automatski build, osnovni testovi, provjera tajni, deployment u testno okruženje i jedan smoke test kritičnog toka. Kada taj put postane pouzdan, mogu se dodavati sigurnosno skeniranje, preview okruženja, postupni rollout i dublji produkcijski signali.
Redoslijed ulaganja treba slijediti stvarni failure mode. Ako deploymenti padaju zbog ručnih konfiguracija, prvo standardizirajte artefakt i okruženja. Ako migracije stvaraju strah, uvedite uvježbavanje i kompatibilne promjene. Ako korisnici prvi uoče pogrešku, dodajte smoke test i signal promatranja odmah nakon deploymenta.
Brzina pipelinea također je proizvodni problem. Prespor feedback potiče veće promjene i zaobilaženje provjera. Brze testove stavite rano, a sporije i skuplje provjere rasporedite prema riziku. Time ne uklanjate stručnu prosudbu, nego joj dajete pravovremene dokaze i sigurniji način djelovanja.
Za sljedeći release odaberite jednu provjeru koja najranije otkriva vaš najčešći uzrok problema. Zapišite njezin signal, vlasnika, prag odluke i put povratka. Kada taj signal postane brz i pouzdan, tim može smanjivati veličinu promjena umjesto dodavati nove ručne korake.
Ako problem nije samo u pipelineu nego u nejasnim ovisnostima između procesa, sustava i odgovornosti, ERP i procesni screening prije promjene može pomoći utvrditi što release stvarno može poremetiti.
Stručni pregled: Borna Grgurić