Amikor a scrum kézbesítéséről van szó, az emberek általában egy sprint vége után várják az elengedést. Ez azt jelenti, hogy közvetlenül a sikeres bemutató bemutatása után az ügyfélnek.
De mindig azon töprengtem, hogy lehet ez ilyen automatikus elvárás. Különösen, ha figyelembe vesszük az alábbi lehetséges tevékenységeket, amelyeknek előtte vagy mellett kell történniük.
- Fejleszd ki és fejezd be az összes történetet a sprint során. Lehet, hogy egyesek hamarabb elkészülnek, de legtöbbször a történetek közvetlenül a sprint vége előtt fejeződnek be. Talán még a demóbemutató után is, hogy itt legyen nyitva.
- Végezzen el minden ütemezett tesztet a sprinttartalom felett, hogy megbizonyosodjon arról, hogy a kiadandó kód készen áll a termelésre.
- Utolérje a felfedezett hibákat, és időben javítsa ki őket, mielőtt a kiadás megtörténik.
- Győződjön meg arról, hogy a telepítési folyamat frissítve van a legújabb tartalommal, és maga a folyamat megbízható végrehajtása.
- Futtassa a folyamatot az összes releváns környezetben, hogy azokat a kód és az adat szempontjából a legújabb állapotba hozza.
- Készítsen kibocsátási megjegyzéseket, és közölje az ügyféllel a kiadás hatását és azt, hogy pontosan mi fog változni utána.
- Ha szükséges, szinkronizáljon más párhuzamos scrum csapatokkal, hogy biztosítsa a függő tartalom egyidejű kiadását. Semmi sem hiányozhat ahhoz, hogy a kiadás tartalma a várt módon működjön.
- Mindezeken felül menj végig az összes scrum ceremónián. Nem csak az aktuális sprinthez kapcsolódik, hanem a következő sprinthez (pl. történet-finomító munkamenetek) is.
Most képzeld el, hogy a sprintnek két hete van.
A felszabadítási tevékenységek önmagukban időbe telik és embereket vesznek igénybe. De nem lehet túl sok. Közvetlenül a sprint utolsó napja után közvetlenül jön a következő sprint első napja, és a kör újra kezdődik.
Még mindig ennyire automatikusnak tűnik a várakozás minden sprint után?
Tartalomjegyzék
Tartalomfeldolgozás kiadása
Ha a sprinten belül minden folyamat automatizált, akkor lehetőség van arra, hogy egyszerűen „meghúzzuk a ravaszt”, és minden sprint végén telepítsük a legújabb kódverziót a termelésbe. A probléma az, hogy még soha nem tapasztaltam ilyen tökéletes állapotot a scrum csapatban.
Ha ez valóban így van néhány kisméretű magánvállalkozásban, akkor nagyon irigylem őket. De a valóság a vállalati világban az, hogy egy scrum csapat nem éri el ezt a fejlettségi szintet. Éppen ellenkezőleg, a kiadási folyamatok általában olyan időigényes tevékenységekhez kapcsolódnak, amelyek a következő sprint nagy részét elérik, és hatással vannak arra a sprintre tartalmi és minden metrika szempontból. A kiadás csak egy stresszes cselekedet, amelynek a csapatból senki sem örül.
Így hát azután fedeztem fel a következő legjobb forgatókönyvet a kiadások kezelésére.
A következtetés az volt, hogy minden második sprintet Release Sprintnek kell tenni. Íme, mit jelent.
Külön kódverzió a következő kiadáshoz
Ez a GIT-tárban lévő külön ágak kezeléséről szól. Sokféleképpen lehet megközelíteni ugyanazt a problémát, és mindegyik sikeres lehet. Ennek a cikknek a céljaira azonban a dolgokat egyszerűnek fogom tartani, hogy bemutassam a megközelítést és annak hatását.
Annak érdekében, hogy a folyamatban lévő fejlesztési tevékenységeket a lehető legkisebb mértékben befolyásolja, fontos, hogy a következő kiadás tartalmait külön ágra különítsük el. Nevezzük Release Branch-nek. Ezzel a következők lesznek megoldva:
- A fejlesztőcsapat folytathatja tevékenységét, és megszakítás nélkül beolvadhat a fő ág új történeteibe.
- Nem áll fenn annak a veszélye, hogy a kiadás tartalmát a scrum csapat váratlan kódmódosításai befolyásolják.
- A tesztelési tevékenységek izolált térben is végrehajthatók. Itt csak a tesztelés feloldásához szükséges változtatások kerülnek bevezetésre.
- Mivel a kiadási folyamat csak a kiadási ágból származó tartalmat helyezi üzembe az éles környezetben, egyértelmű folyamatunk van, és teljes ellenőrzésünk van a kiadandó tartalom felett. Nem fordulhat elő, hogy a Git ágba történő váratlan véglegesítés megtörné a már tesztelt kódot.
Tehát csak tartsa félre a következő kiadás tartalmát, és hagyja, hogy stabil állapotba kerüljön, készen a kiadásra.
Időzítse be a kiadásokat, hogy ismételten működjenek
Feladtam az ambíciót, hogy minden egyes sprint után kiadjam. Nagyon egyértelmű volt, hogy ennek esélye sem lesz működni. Legalábbis nem olyan mellékhatásokkal, mint:
- befolyásolja a következő sprint fejlesztési tartalmat,
- nem tudja stabilizálni a kibocsátási tartalmat,
- felzárkózni az összes szükséges tesztelési tevékenységhez stb.
A cél tehát az volt, hogy minden második sprint végére végre lehessen hajtani a felszabadítást. Ez a következőket jelentené:
- A kiadás mindig tartalmazni fogja az utolsó két, már befejezett sprint történetét. Mivel a kiadás a jelenlegi (aktív sprint) belül történik, ez a sprinttartalom még nem szerepel a kiadásban.
- A szükséges tesztelési tevékenységek és a hibajavítások elvégzésére egy teljes sprint idő áll rendelkezésre.
- A kiadás tulajdonosának elegendő ideje van összegyűjteni a kiadással kapcsolatos információkat (tesztesetek, kiadási megjegyzések stb.) a nem kiadási sprinttel. Így alapvetően önállóan működhetnek, és a fejlesztőcsapat többi tagja új történeteken dolgozhat.
- Hibafelderítés esetén a kiadás tulajdonosa gyorsan kapcsolatba léphet a konkrét fejlesztővel, hogy kijavítsa a problémát, és visszatérjen az aktuális sprint tartalomhoz. Tehát a csapat kapacitásából mindig bizonyos százalékos időt kell elkülöníteni a hibajavítás támogatására. Hogy pontosan mennyit, az idővel kiderülhet.
Nyilvánvaló, hogy a felhasználók nem kapják meg a legfrissebb sprint tartalmat a legújabb kiadásban. De idővel ez irrelevánssá válik. Úgyis minden következő kiadással két sprint tartalmat kapnak, minden második sprint után.
Ez jó kompromisszumnak tűnik a gyors szállítási elégedettség és a scrum tevékenységekkel való lépéstartás között, jelentős zavarok nélkül.
Hajtsa végre a kiadási telepítést
Amikor a tesztelés, a hibajavítás és a folyamatkészenléti tevékenységek sikeresen befejeződnek, meglehetősen egyszerű folyamat a termelési folyamat végrehajtása és az éles kiadás befejezése.
Mivel egy önálló ágból kerül telepítésre, ez alapvetően észrevétlen és láthatatlan tevékenység lehet. Senkinek sem kell tudnia. Ha ez a helyzet, akkor ez a kiadás telepítésének lehető legjobb megvalósítása.
Ennek előfeltétele egy szilárd automatizált DevOps-folyamat létrehozása. Nem csak az éles környezetben való üzembe helyezésre szolgál, hanem az összes többi alacsonyabb szintű környezetbe is. Ez magában foglalhatja a fejlesztőt, a sandboxot, a tesztet, a minőségbiztosítást, a teljesítménykörnyezetet stb. Ez egy kattintás az összes megoldás telepítéséhez minden egyes környezetben.
Az elengedés nem lehet fájdalompont vagy stressz. Vagy egy rémálom, akitől mindenki fél, és egy hétig arra a napra készül. Nem – ehelyett, ha ezt soha senki sem veszi észre, ez a sikeres kiadás legjobb jele.
Egyesítse vissza a kiadási ágat a fejlesztési ágba
A Release Branch most olyan speciális tartalmakat tartalmaz, amelyek nem léteznek a szokásos, folyamatban lévő fejlesztési ágban. A tesztidőszak során végrehajtott összes javításhoz kapcsolódik. Ezt a tartalmat vissza kell olvasztani a fejlesztési ágba, hogy a javítások a következő kiadás után is ott maradjanak.
Ekkor a legújabb kiadási ág vészhelyzeti újratelepítésre kész éles kódként szolgál. Ha egy sürgős, kiemelt fontosságú problémát röviddel az éles üzembe helyezés után meg kell oldani, használhatja ezt az ágat. Egyszerű átvenni ezt a kódot és végrehajtani benne a javítást. Ez még mindig a jelenlegi gyártási kód pontos másolata, új, kiadatlan tartalom nélkül.
Végül, amint az új tesztelési időszak elkezdődik, az előző kiadási ág törölhető és helyettesíthető egy újjal. Az új ismét másolatként jön létre a jelenlegi fejlesztési ágból.
Rendszeres kiadások létrehozása
És most megvan 😀 – egy szilárd folyamat a megjelenéshez. Az egyetlen dolog, ami hiányzik, az a kötelezettségvállalás, hogy rendszeres marad. Ebben az esetben minden második sprint után.
Azáltal, hogy rendszeresen tartjuk, tulajdonképpen megalapozzuk a könnyebb teljesítést, főként azért, mert:
- Ha a kiadás nem túl hosszú idő után jelenik meg, akkor nincs olyan sok új tartalom, amelyet telepíteni kell az éles verzióra. A növekmény kicsi és stabilnak tekinthető.
- Mostantól ennyi új tartalom nem jelent túlnyomórészt sok tesztelési tevékenységet és teszteset létrehozását. Kevesebb kommunikáció, megállapodási felhívás és együttműködés az érdekelt felekkel arról, hogy mit kell újra érvényesíteni. Abban is egyetértenek, hogy nem is olyan sok telt el az utolsó kiadás óta. Így kisebb jelentőséget tulajdonítanak ennek az akciónak.
- A csapat hozzászokik ehhez a ciklushoz; idővel a csapat természetes része lesz.
- Ennek mellékhatásaként gyakran frissülnek az adatok a fejlesztői és tesztelési környezetekben. Erre mindenképpen szükség van minden új tesztelési ciklushoz. Tehát ez nem csak egy újabb ütemezett tevékenység lesz. Inkább egy olyan cselekvés, amely már a kialakult folyamat része. Ez a szemléletváltás nagy hatással van a csapat légkörére. Ezt nem hinné az ember.
Következtetés
Ez a fejezet a scrum életciklus témájával kapcsolatos korábbi bejegyzéseimet zárja. Arról is szól, ami a való életben bevált.
A csapatok gyakran agilis módon kezdik, és sok mindent rosszul csinálnak. Aztán végül fejlődnek, és elkezdenek másképp csinálni a dolgokat. Ez a sorozat segíthet néhányuknak, hogy gyorsabban hajtsák végre ezt a változást.
Ez a kiadási megközelítés sem az egyetlen működőképes, és nem is problémamentes. Ezek továbbra is léteznek, és a csapatoknak foglalkozniuk kell velük. Aztán javítsd azt, ami lehetséges, és felejtsd el azt, aminek nincs értelme.
De amennyire tudom, ez a megközelítés, bár egyszerű, bebizonyította, hogy a változás lehetséges. A kaotikus, kiszámíthatatlan sprintektől a stabilabb szállításokig, rendszeres kiadásokkal, amelyekre támaszkodhat és tervezhet. És ehhez nincs szükség speciális, rendkívül bonyolult módszertanra – csak egyszerű szabályokra és a terv követésére való hajlandóságra.