Имплементација Scrum издања: Од припреме до примене
Када се говори о Scrum методологији, често се подразумева да се издања имплементирају одмах након завршетка спринта, односно по успешном представљању демо верзије клијенту. Међутим, поставља се питање да ли је то заиста увек тако једноставно.
Постоји низ активности које је потребно обавити пре, или паралелно са, самом имплементацијом:
- Развој и финализација свих задатака унутар спринта. Већина задатака се завршава непосредно пре краја спринта, а понекад и након демо презентације.
- Спровођење тестирања како би се осигурало да је код спреман за производњу.
- Решавање пронађених грешака и њихово уклањање пре објављивања.
- Ажурирање и верификација исправности цевовода за имплементацију.
- Покретање цевовода на свим окружењима како би се она довела у склад са најновијим кодом и подацима.
- Припрема белешки о издању и комуникација са клијентима о утицају и променама које следе након имплементације.
- Координација са другим паралелним Scrum тимовима у циљу синхронизације зависних садржаја.
- Истовремено, треба одрадити и све Scrum церемоније, како оне које се тичу текућег спринта, тако и оне које се односе на наредни (нпр. припрема задатака).
Ако узмемо у обзир да спринт траје две недеље, можемо видети колико је захтевно све ово постићи.
За самосталне активности је потребно време и ангажман тима. Али, исто тако, не смеју трајати превише, јер се након завршетка једног спринта одмах наставља са наредним.
Да ли и даље изгледа реално да се издања имплементирају аутоматски након сваког спринта?
Обрада садржаја издања
Ако би сви процеси унутар спринта били у потпуности аутоматизовани, било би могуће једноставно „повући окидач“ и инсталирати најновију верзију кода у производњу на крају сваког спринта. Међутим, у реалности је веома тешко постићи такав ниво зрелости Scrum тима.
Могуће је да нека мања предузећа успевају у томе, али у корпоративном окружењу то је тешко изводљиво. Често су процеси објављивања повезани са активностима које се протежу кроз већи део наредног спринта, што утиче на сам спринт, његов садржај и све метрике. Имплементација издања постаје стресан процес, који нико у тиму не жели.
Зато је потребно размотрити следећи, ефикаснији приступ.
Решење је да сваки други спринт буде посвећен издању. У наставку ћемо објаснити шта то подразумева.
Одвојена верзија кода за наредно издање
Овај приступ се заснива на коришћењу одвојених грана у Git репозиторијуму. Постоји више начина да се ово постигне, и сви могу бити успешни. Међутим, ради једноставности, фокусираћемо се на један приступ.
Како би се минимално утицало на развојне активности, неопходно је издвојити садржај за наредно издање у посебну грану, коју ћемо назвати Release Branch. Ово ће омогућити:
- Развојни тим може несметано да настави рад на новим задацима и обједињује их са главном граном.
- Не постоји ризик да на садржај издања утичу неочекиване промене у коду.
- Тестирање се може спроводити у изолованом окружењу, где се уносе само измене неопходне за решавање пронађених проблема.
- Пошто цевовод за издавање у производњу убацује само садржај из Release Branch-a, имамо јасан процес и потпуну контролу над оним што се објављује. На тај начин, не може доћи до неочекиване грешке у коду.
Дакле, једноставно издвојите садржај за наредно издање и оставите га да се финализује у стабилном стању, спреман за објављивање.
Планирајте издања тако да се успешно понављају
Након што сам одустао од идеје о издању након сваког спринта, било је јасно да то не функционише. Ово је узроковало нежељене ефекте као што су:
- Утицај на развојни процес следећег спринта.
- Неспособност стабилизације садржаја издања.
- Недостатак времена за потребне активности тестирања.
Стога је циљ био да се издања имплементирају на крају сваког другог спринта. Ово би подразумевало:
- Издање ће увек садржати задатке из претходна два спринта. Пошто се издање имплементира у току тренутног спринта, његов садржај није укључен у издање.
- Постоји читав спринт за спровођење тестирања и исправљање грешака.
- Власник издања има довољно времена да прикупи потребне информације (тестне случајеве, белешке о издању) у току спринта без издања. На тај начин, може радити независно и не ометати остатак тима.
- У случају проналажења грешке, власник издања може брзо комуницирати са одговарајућим програмером како би је отклонио. Увек треба издвојити одређени део капацитета тима за подршку у решавању грешака.
Наравно, корисници неће добити најновији садржај у најновијем издању. Али то временом постаје неважно. Они ће добити садржај два спринта након сваког другог спринта.
Ово је компромис између брзе имплементације и несметаног одвијања Scrum активности.
Имплементирајте издање
Када су тестирање, исправљање грешака и припрема цевовода завршени, имплементација издања постаје једноставан процес.
Пошто се имплементира из одвојене гране, ово може бити неприметан процес. Ако је то случај, значи да је имплементација издања успешна.
Предуслов за ово је успостављање доброг, аутоматизованог DevOps цевовода. Овај цевовод се користи за имплементацију у производном окружењу, али и у свим осталим окружењима (програмери, тестирање, контрола квалитета, перформансе…). Овим се постиже могућност да се једним кликом имплементира решење у свако појединачно окружење.
Издање не би требало да представља стрес и ноћну мору. Уместо тога, требало би да прође неприметно, што је најбољи показатељ успешног издања.
Вратите Release Branch у Development Branch
Release Branch сада садржи измене које не постоје у главној грани развоја. Ово се односи на исправке које су имплементиране током тестирања. Ове измене је потребно вратити у развојну грану како би се осигурало да ће бити сачуване и након наредног издања.
Такође, Release Branch служи као производни код у случају хитних ситуација. Ако је потребно брзо решити проблем након имплементације, може се користити ова грана, која је тачна копија тренутног производног кода.
Када почне нови период тестирања, претходни Release Branch се брише и замењује новим, који се креира као копија из тренутне развојне гране.
Успоставите редовна издања
Сада имамо успостављен процес за имплементацију издања, који треба редовно одржавати, у овом случају након сваког другог спринта.
Редовним одржавањем издања постиже се:
- Мање новог садржаја се имплементира у производњу, што смањује ризик и обезбеђује стабилност.
- Нема много активности тестирања, што значи мање комуникације и договора са заинтересованим странама.
- Тим се навикава на циклус, који постаје природан део процеса.
- Окружења за развој и тестирање се редовно освежавају подацима, што је неопходно за сваки нови циклус тестирања. Ово се не посматра као додатна обавеза, већ као део редовног процеса, што позитивно утиче на атмосферу у тиму.
Закључак
Овај текст заокружује претходне текстове о Scrum процесу, представљајући приступ који је доказано успешан у реалним условима.
Многи тимови који почну са Agile методом раде неке ствари погрешно, али временом се развијају и почињу радити ствари на другачији начин. Овај приступ може помоћи неким тимовима да убрзају ту промену.
Овај приступ издању није једини могућ, нити је без проблема. Проблеми ће и даље постојати, али тимови морају да се носе са њима. Треба побољшати оно што је могуће, а заборавити оно што нема смисла.
Овај једноставан приступ је показао да је промена могућа, од хаотичних спринтова до стабилних и предвидљивих издања. Ово не захтева компликоване методологије, већ једноставна правила и спремност да се следи план.