Ez a cikk egy sorozat első része. Ha a másodikat is el szeretnéd olvasni, itt megteheted:
A continuous delivery (CD) az IT-körökben az egyik leggyakrabban használt kifejezés, ami a menedzsmentrétegtől kezdve a csapatok szintjéig mindenki által könnyen megfogható.
A continuous delivery valójában ennél sokkal több. Nemzetközi kutatások bizonyítják, hogy azok a cégek, amelyek azt jól alkalmazzák, és képesek a vállalati kultúrában is a megfelelő változtatásokat megtenni annak érdekében, hogy a szoftverfejlesztésben részt vevő különféle szereplők (üzleti oldal, fejlesztés és üzemeltetés) hatékonyan, magas bizalmi légkörben dolgozzanak együtt, csúcsteljesítő (high-performing) csapatokat alakítanak ki, ami a piacon érzékelhetően jelentős különbségeket okoz a szervezetek között.
Tehát aki képes high-performing csapatokat létrehozni és fenntartani, jelentős előnyre tehet szert a piacon. Mint a legtöbb fogalmat, a CD-t is félreértések övezik, ezért érdemes tisztázni, mit is jelent pontosan, mit várhatunk tőle, és mik azok a kulcselemek, amelyek elengedhetetlenek ahhoz, hogy megvalósulhasson a CD, és érdemes azt is látni, hogy milyen tágabb összefüggések állnak fenn az alkalmazásával kapcsolatban.
Ezzel mindenkinek érdemes tisztában lennie, aki szoftverfejlesztési projektben vesz részt, mert a CD nem csupán egy szoftverfejlesztési technika, ami csak a mérnökökre tartozik, hanem annak helyes bevezetése és alkalmazása elősegíti az agilis- és leankultúra megteremtését is a szervezetben, így jelentős pozitív hatást gyakorol a szervezeti kultúrára is.
Mit jelent a continuous delivery?
➔ Intuitív alapon akár könnyen érthetnénk is, mit jelent a continuous delivery (magyarul: folyamatos szállítás), azonban pont ez ad okot a gyakori félreértésekre. Sokan gondolják azt például, hogy a CD az, amikor a szoftvert minden változás után – amennyiben az átesett az automatikus minőségellenőrzésen – automatikusan kiadjuk éles környezetbe. Ezt continuous deploymentnek hívják (és nem deliverynek), aminek előfeltétele a continuous delivery. Sok szervezetnél, kifejezetten azoknál, ahol az erős szabályozói környezet egyéb kontrollokat is meghatároz, nem reális a continuous deployment elérése, azonban a continuous delivery megvalósítása minden olyan szoftverfejlesztési projektben, amelyben fontos a biztonság, a fenntarthatóság és a sebesség, ma már – mondhatni – kötelező.
Gyakori, hogy a CD elérése a magas automatizáltság kitűzését és megvalósítását jelenti. Valóban fontos az, hogy minél több ismétlődő feladatot automatizáljunk, ezáltal csökkentve a hibázás lehetőségét és elősegítve a gyorsabb működést, ez a szándék azonban önmagában még nem jelenti azt, hogy CD-t valósítottunk volna meg.
A continuous delivery valójában azt jelenti, hogy a kódot képesek vagyunk – szükség esetén – fenntartható módon, azaz bármikor biztonságosan és gyorsan (pár órán belül) release-elni.
A continuous delivery megvalósítása minden olyan szoftverfejlesztési projektben, amelyben fontos a biztonság, a fenntarthatóság és a sebesség, ma már – mondhatni – kötelező.
Vegyük észre, hogy a CD elérésének előfeltétele az, hogy a kód lényegében bármilyen időpillanatban release-elhető állapotban legyen. Ez a szoftverfejlesztésben használt jelenlegi gyakorlatok alapján kizárólag akkor érhető el, ha gyakoroljuk a continuous integrationt. A continuous integration három dolog együttes teljesülése esetén valósulhat meg maradéktalanul:
- A fejlesztői csapat minden tagja a master branchre commitál naponta legalább egyszer.
- A commitra lefut a build és az automata tesztek. A zöld build nagy biztonsággal képes jelezni a kód éles környezetbe történő deployálhatóságát.
- Ha piros a build, az 10 percen belül javításra, így újra zöld állapotba kerül.
A continuous delivery elérése elképzelhetetlen continuous integration alkalmazása nélkül.
Alapelvek
➔ Öt alapelvre épül a CD (Accelerate, 42. oldal):
Építsük be a minőséget (build quality in)
Hogyan tudunk bármilyen (fontos) hibát, issue-t mihamarabb észrevenni és kijavítani? Ez a kérdés áll ennek az elvnek a középpontjában. A minőségért mindenki felel. A szoftverfejlesztők ugyanúgy írnak teszteket (enélkül a CI elképzelhetetlen is lenne), és nem a QA felel kizárólagosan a minőségért, továbbá a minőség ellenőrzése nem ér véget azzal, hogy kiadtuk a szoftvert (és ha hiba van, akkor majd szól a felhasználó vagy az ügyfél). Ma már pl. éles környezetben is képesek vagyunk proaktívan mérni a meghibásodásokat, és hamarabb reagálni, mint ahogy a legtöbb felhasználó azt észrevenné. Ezt a technikát élesben tesztelésnek hívják.
Apró lépésekben haladjunk (work in small batches)
A nagy szervezetek hajlamosak nagy darabokban szállítani szoftvert (ld. vízesésmodell-szerű szállítás, ahol sokáig mérik fel a követelményeket, sokáig terveznek, sokáig valósítanak meg, és sokáig tesztelnek). A CD kulcsa az, hogy apró lépésekben szállítsunk, mert ezáltal nyílik lehetőségünk a lehető legkorábban gyűjteni visszajelzéseket, és azok alapján korrigálni. A visszajelzések korai begyűjtése két fontos kérdésre ad választ: a jó terméket építjük-e (tehát erre van-e szüksége a felhasználóinknak), illetve a terméket jól építjük-e (minőségileg rendben van-e). Bár elsőre úgy tűnhet, hogy az apró lépésekben történő fejlesztés sok overheadet okozhat, ezek a tranzakciós költségek jelentősen csökkenthetőek, és állandóan arra is kell törekednünk, hogy ezeket csökkentsük. Ma már ehhez minden technikai eszköz rendelkezésre áll, a legnagyobb akadályt az emberi tényező okozza, azaz, hogy képesek legyenek (más szóval: akarjanak) a különböző szereplők hatékonyan együtt dolgozni.
A gépek végezzék az ismétlődő feladatokat, az emberek pedig problémákat oldjanak meg
Drasztikus mértékű költségcsökkentés úgy érhető el, ha az időigényes, ismétlődő feladatokat gépekre bízzuk (pl. regressziós tesztelés és deployment), és hagyjuk, hogy az emberek a magasabb értéket képviselő problémamegoldással foglalkozzanak. Így az embereknek van idejük a folyamatos fejlesztésre a repetitív és sokszor tűzoltás jellegű feladatok ellátása helyett. Ez nemcsak gazdaságilag térül meg, de segít megelőzni a burnoutot, ezáltal egy sokkal motiváltabb szervezetet is eredményez.
Könyörtelenül törekedjünk a folyamatos fejlődésre (relentlessly pursue continuous improvement)
A csúcsteljesítményt nyújtó csapatok egyik jellemzője a folyamatos fejlődésre való megszállott törekvés. Soha nem elégedettek, és folyamatosan azon ötletelnek, hogyan tudnák még jobban, még hatékonyabban végezni a munkájukat.
Mindenki felelős
A bürokratikus, funkcionális részlegekre, osztályokra felosztott szervezetek elsődlegesen a saját részlegük céljainak elérésében érdekeltek ahelyett, hogy a nagy szervezeti célokat részesítenék előnyben. A fejlesztők a sebességre optimalizálnak, a tesztelés a minőséget méri, az üzemeltetés célja pedig a stabilitás. A valóságban viszont ezek a célok mind rendszerszintű célok, és csak akkor érhetőek el, hogy ha mindenki, aki a szállításban részt vesz, együtt dolgozik. A menedzsment feladata az, hogy ezeket a rendszerszintű célokat transzparenssé tegye, és elérje, hogy a résztvevők ezek elérése érdekében egymással együtt dolgozzanak.
Ez a cikk egy sorozat első része. Ha a másodikat is el szeretnéd olvasni, itt megteheted:
