A continuous delivery elsősorban mérnöki megközelítés: olyan gyakorlatokat és elveket sorakoztat fel, amelyek nagyságrendekkel tudják hatékonyabbá tenni a szoftverfejlesztést.
Ez a cikk egy sorozat második része. Ha az elsőt is el szeretnéd olvasni, itt megteheted:
Continuous Delivery (1. rész) – Jelentése, alapelvei és amiért érdemes alkalmazni
DevOps-kultúra
➔ A continuous delivery elsősorban mérnöki megközelítés: olyan gyakorlatokat és elveket sorakoztat fel, amelyek nagyságrendekkel tudják hatékonyabbá tenni a szoftverfejlesztést. A mérnöki megközelítésből fakadóan a fejlesztők és üzemeltetők közötti kapcsolat szorosabbá tételét sürgeti a hatékonyság növelése érdekében, ami egy külön kifejezést is kikövetelt magának: DevOps. A szó a development (fejlesztés) és operations (üzemeltetés) szavak rövidítéséből és összefűzéséből keletkezett, és azt fejezi ki, hogy a fejlesztőknek és üzemeltetőknek szorosan együtt kell dolgozniuk annak érdekében, hogy sokkal hatékonyabb legyen a szállítási folyamat.
A DevOps egy kultúra. Szokás manapság pozíciókat (title) vagy csapatokat DevOps-nak hívni, ezzel viszont vigyázni kell, mert ha egy dedikált DevOps-csapat dolgozik a fejlesztői csapat mellett vagy attól függetlenül, akkor éppenséggel pont az ellenkezője történik annak, ami a DevOps eredeti célkitűzése lenne. A DevOps mindig közös erőfeszítést követel meg a fejlesztői csapattól (ideális esetben keresztfunkcionális és önszerveződő csapat) és az üzemeltetői fókuszú csapattól egyaránt.
Azon szoftverfejlesztés esetében, ahol nem DevOps-szemlélet szerint történik a szállítás, a fejlesztői csapat általában nincs tisztában az üzemeltetési körülményekkel, ezért a fejlesztés során nem tudja ezen szempontokat is figyelembe venni. A fejlesztők sokszor gyorsítanának, az üzemeltetők ezzel szemben lassítani igyekeznek a folyamatot. Mivel nem ismerik egymást és egymás munkáját, bizalmi problémák lépnek fel a felek között, ami a szállítás hatékonyságnövelésének áll az útjában. Szabályozott környezetben (pl. bankok) az üzemeltetők gyakran minden verzióhoz telepítési útmutatót kérnek, az éles deploymentet rendszerint üzemidőn kívülre ütemezik, ha pedig valami balul sül el (ami elég gyakran megtörténik), az üzemeltetőknek szinte reménytelen a helyzete, hiszen nem ismerik a kód működését, az adatbázis szerkezetét stb. Az ilyen környezet lassítja a szállítási folyamatot, és a lassú szállítás eredményeképpen általában romlik a minőség. A DevOps-kultúra, ami együttműködésre ösztönzi a fejlesztőket és az üzemeltetőket, a continuous delivery elveit és praktikáit alkalmazva az említett problémákra ad megoldást.
Ami fáj, azt csináld gyakrabban!
➔ Lehetnek olyan pontok a szállítási folyamatban, amelyeket szeretnek a mérnökök elkerülni (tipikusan a continuous integration vagy a gyakori release-adás), mert állandó „fejfájást” okoznak nekik. Ilyenkor az az ösztönös reakciójuk, hogy későbbre tolják e „fájó” pontokkal való foglalkozást. Pl.: „Dolgozzunk feature brancheken, mert az kényelmes, majd a végén integrálunk.” vagy „Adjunk ki ritkábban release-t, mert most nagyon körülményes lenne.”
Az az igazság, hogy ha így gondolkozunk, akkor egyre inkább eltávolodunk a continuous delivery lényegétől, és ezzel együtt búcsút is inthetünk a hatékony, biztonságos és gyors szállítási folyamatnak. A megoldás nem az, hogy elkerüljük a problémát, hanem éppen ellenkezőleg: hozzuk még előbbre, hogy „még jobban fájjon”. Ha pedig jobban fáj, nagyobb késztetést fogunk érezni arra, hogy mihamarabb orvosoljuk a problémát.
Fájdalmas a release-adás negyedévente? Csináljuk havonta. Fájdalmas havonta? Csináljuk kéthetente.
Kapcsolat a scrummal
➔ Sok cégnél alkalmazzák a scrumot, hogy keretet szabjanak a szoftverfejlesztés folyamatának. Érdekes kérdés az is, hogy hogyan kapcsolódik az iterációkban, sprintekben gondolkozó scrum a continuous deliveryhez, aminek a célja a folyamatos szállítás képességének megteremtése.
A scrum is érinti valamelyest a sprint végére elkészülő potentially shippable product fogalmát (ezáltal a deliveryre utal), azonban semmilyen támpontot nem ad arra vonatkozóan, hogy ez tulajdonképpen mit is jelent valójában, és hogyan lehetne azt elérni. A magam részéről szerencsésebbnek tartom a CD-t függetlenül kezelni a sprinttől és annak céljától, és inkább arra törekedni, hogy a sprint előrehaladtától függetlenül képesek legyünk a CD-re. Ha csupán azért törjük magunkat, hogy a sprint végére legyen kiadható állapotban a szoftver, akkor ezt a célt – mintegy másodlagos célt a sprint célja alá rendelve – jó eséllyel félvállról fogjuk venni, ha viszont arra törekszünk, hogy mindig release-elhető legyen a kód, akkor arra valóban minden pillanatban törekedni fogunk, és így valóban el tudjuk majd érni és fenn tudjuk tartani a CD által megkívánt ideális állapotot. A jelenlegi technikák (TDD, continuous integration, trunk-based development), amik a CD alappillérei, nem tesznek különbséget a sprint eleje és a sprint vége között. Ezeket a technikákat folyamatosan, fegyelmezetten kell alkalmazni, hogy a CD-t elérhessük még akkor is, ha szándékunk szerint csak a sprint végén adunk ki release-t.
Példa
Saját tapasztalataimból szemezgetve volt olyan projekt, amely a sprint kéthetes ciklusait tartva minden héten kedden adott release-t. A scrum ritmusa megadta a csapatnak a folyamatos önreflexióra való lehetőséget, a PO-val való szinkronizálás lehetőségét és a célok egyeztetését, átértékelését. Ettől függetlenül a csapat minden kedden szállított, a kód minden időpillanatban release-elhető volt. Azt garantálni viszont, hogy egy feature mindenképpen elkészüljön a sprint végére úgy, hogy az az összes felhasználó által használatba vehető legyen, lehetetlen volt. Feature toggle-ök alkalmazásával lehetségessé vált egy fejlesztés alatt lévő feature-t a felhasználók egy részével megosztani, és így folyamatosan visszajelzést gyűjteni.
Bár a PO nem tartotta fontosnak a heti szállítást, mert az új feature-ök ilyen ütemben nem készültek el, a fejlesztői csapat tudta, hogy a folyamatos visszajelzés az éles rendszerből kritikus fontosságú ahhoz, hogy a felmerülő problémák mihamarabb javításra kerüljenek, és a rendszeres szállítás valójában kikényszerítette a fenntartható, gyors és biztonságos szállítást. A rendszeres szállítás és a scrumfolyamat egymástól történő függetlenítése felszabadítólag hatott a csapatra.
A fejlesztőknek és üzemeltetőknek szorosan együtt kell dolgozniuk annak érdekében, hogy sokkal hatékonyabb legyen a szállítási folyamat.
Mentális gát: release-tervezés
➔ Sok szervezet még mindig release-eket tervez. A ticketing rendszerben (pl. Jira) a tervezett feature-öket, fixeket release-ekhez, és a release-eket is különböző dátumokhoz (pl. negyedéves release) rendelik.
Teljesen világos, hogy elengedhetetlen a rendszerben történő változások megfelelő kommunikációja a felhasználók számára, azonban a continuous delivery alkalmazása során a verziószámok nem relevánsak többé, mert a szállítási folyamat egy folyamatos áramlásban valósul meg. (Trunk-based developmentről lévén szó a verziószám egyetlen számból álló számláló is lehetne.)
Ez átalakítja a tesztelés folyamatát is, hiszen nem fagyasztunk be egy release candidate-et, hogy abban a tesztelők addig teszteljenek, amíg úgy nem találják, hogy biztonságos a rendszer élesbe engedése. Egyszerre csak egy verzió létezik.
Bizonyos esetekben (pl. mobilfejesztés) a CD alkalmazása akadályokba ütközhet, mert nem lehetséges a szoftverből bármikor új verziót telepíteni (felhasználói engedélyhez kötött, vagy nincs hálózat). Ez nem azt jelenti, hogy ne törekedhetnénk arra, hogy mindig release-elhető legyen a kód. Viszont azzal is tisztában kell lennünk, hogy hiba esetén nem tudjuk feltétlenül új verzió kiadásával javítani a korábbi hibát, ezért erre fel kell készülnünk a szállítási folyamat során, és esetleg bizonyos pontokon kompromisszumra kényszerülhetünk az ideális CD-hez képest.
A continuous delivery alkalmazása során a release-tervezés veszít a jelentőségéből. Minden szervezetnek érdemes átgondolnia, hogy ebben az új működésben valóban szükség van-e release-tervezésre, és miért.
Konklúzió
➔ Nemzetközi kutatások bizonyítják, hogy azok a cégek, amelyek jól alkalmazzák a CD-t, é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.
A continuous delivery kizárólag műszaki kiválóságra való törekvés révén érhető el csakis olyan szakemberekkel, akik ambiciózusak és motiváltak. Olyan környezetet is szükséges biztosítani számukra (önszerveződő csapatok), amelyben ezt az attitűdjüket meg is őrizhetik.
Gyors és biztonságos szállítás egyetlen módon érhető el: ha fenntartható módon szállítunk. Ez a continuous delivery.
A continuous delivery technikáit és elveit részletesen az ebben a témában alapműnek számító könyvből lehet megismerni.