Када је у питању испорука сцрум-а, људи обично очекују извршење ослобађања након завршетка спринта. То значи непосредно након успешне демо презентације клијенту.
Али увек сам се питао како ово може бити тако аутоматско очекивање. Поготово ако узмете у обзир доле наведене могуће активности које се морају десити пре или поред.
- Развијте и довршите све приче у спринту. Неке би могле бити завршене раније, али већину времена, приче се завршавају непосредно пре краја спринта. Можда и после демо презентације, да буде отворен овде.
- Извршите све заказане тестове над садржајем спринта да бисте били сигурни да је код који треба да се објави да је спреман за производњу.
- Ухватите корак са откривеним грешкама и поправите их на време пре објављивања.
- Уверите се да је цевовод за примену ажуриран најновијим садржајем и да је сам цевовод поуздан за извршавање.
- Покрените цевовод на свим релевантним окружењима да бисте их довели у најновије стање из кода као и из перспективе података.
- Припремите белешке о издању и комуницирајте са клијентом о утицају издања и шта ће се тачно променити након тога.
- Ако је релевантно, синхронизујте се са другим паралелним сцрум тимовима како бисте осигурали да ће зависни садржај бити објављен истовремено. Ништа не би требало да недостаје да би се осигурало да ће садржај вашег издања функционисати како се очекује.
- Поврх свега овога, прођите кроз све церемоније сцрум-а. Не само у вези са тренутним спринтом, већ и са онима који су циљани за следећи спринт (нпр. сесије прецизирања прича).
Сада замислите да спринт има две недеље.
За самосталне активности потребно је време и људи. Али не може потрајати превише. Одмах после последњег дана спринта долази директно први дан следећег спринта, и круг ће почети поново.
Да ли очекивање ослобађања након сваког спринта и даље изгледа тако аутоматски?
Преглед садржаја
Обрада садржаја издања
Ако су сви процеси унутар спринта аутоматизовани, постоји могућност да се само „повуче окидач“ и инсталира најновија верзија кода у производњу на крају сваког спринта. Проблем је у томе што никада нисам доживео тако савршено стање сцрум тима.
Ако је то заиста случај у неким малим приватним предузећима, заиста им завидим. Али реалност у корпоративном свету је да сцрум тим неће постићи тај ниво зрелости. Напротив, процеси објављивања су обично повезани са дуготрајним активностима које достижу већину следећег спринта, утичући на тај спринт из перспективе садржаја и свих метрика. Ослобађање је само стресан чин кроз који нико у тиму није срећан.
Зато сам открио следећи најбољи сценарио за суочавање са издањима.
Закључак је био да сваки други спринт буде Релеасе Спринт. Ево шта то значи.
Одвојена верзија кода за следеће издање
Овде се ради о руковању одвојеним гранама у ГИТ спремишту. Постоји много начина да се приступи истом проблему, и сви они могу бити успешни. Али у сврху овог чланка, учинићу ствари једноставним да бих показао приступ и његов утицај.
Да би се што мање утицало на текуће развојне активности, важно је одвојити садржај за следеће издање у посебну грану. Назовимо га Релеасе Бранцх. Овим ће се решити следеће:
- Развојни тим може да настави са активностима и да се без ометања споји са новим причама главне гране.
- Не постоји ризик да ће на садржај издања утицати неочекиване модификације кода од стране Сцрум тима.
- Активности тестирања се могу изводити у изолованом простору. Овде ће бити унете само промене неопходне за решавање тестирања.
- Пошто ће цевовод за издавање применити у продукцију само садржај из огранка за издавање, имамо јасан процес и потпуну контролу над садржајем који ће бити објављен. Не може се десити да неко неочекивано урезивање у Гит грану поквари већ тестирани код.
Зато само оставите садржај следећег издања по страни и пустите да се заврши у стабилном стању, спреман за пуштање.
Време издавања тако да раде изнова
Одустао сам од амбиције да урадим издање након што је сваки спринт завршен. Било је супер јасно да ово неће имати шансе да функционише. Барем не са таквим нежељеним ефектима као што су:
- утичући на садржај развоја следећег спринта,
- неспособност да стабилизује садржај издања,
- сустизање свих потребних активности тестирања итд.
Дакле, циљ је био да се изврши ослобађање до краја сваког другог спринта. То би подразумевало следеће:
- Издање ће увек садржати приче из последња два већ завршена спринта. Пошто се издање изводи у оквиру тренутног (активног спринта), овај садржај спринта још није укључен у издање.
- Постоји читав један спринт да се обаве неопходне активности тестирања и исправке грешака.
- Власник издања има довољно времена да прикупи информације релевантне за издање (тестне случајеве, белешке о издању, итд.) са спринтом без издања. На овај начин могу да раде у основи самостално и да оставе остатак развојног тима да ради на новим причама.
- У случају откривања грешке, власник издања може брзо да се повеже са конкретним програмером како би решио проблем и вратио се на тренутни садржај спринта. Тако да увек треба да постоји одређени проценат времена који се издваја из капацитета тима да подржи ово исправљање грешака. Колико се тачно може открити током времена.
Јасно је да корисници неће добити најновији садржај спринта у најновијем издању. Али временом ће ово постати неважно. Ионако ће добити два спринта садржаја са сваким следећим издањем, након сваког другог спринта.
Ово изгледа као добар компромис између брзог задовољства испоруком и одржавања корака са сцрум активностима без значајних сметњи.
Извршите имплементацију издања
Када су тестирање, исправљање грешака и активности спремности цевовода успешно завршене, прилично је једноставан процес да се изврши производни цевовод и заврши пуштање у производњу.
Пошто се примењује из самосталне гране, ово у основи може бити непримећена и невидљива активност. Нико не мора да зна. Ако је то случај, то је најбоља могућа имплементација издања.
Предуслов за то је креирање солидног аутоматизованог ДевОпс цевовода. Не само да се користи за примену у производном окружењу, већ иу свим другим окружењима нижег нивоа. Ово може укључивати програмере, сандбок, тестове, осигурање квалитета, окружење перформанси итд. Ово ће бити једним кликом да бисте применили сва решења за свако појединачно окружење.
Ослобађање не би требало да представља бол или стрес. Или ноћна мора којих се сви плаше и која се припрема за тај дан недељу дана. Не – уместо тога, ако то нико уопште не примети, ово је најбољи знак успешног издања.
Спојите назад грану издања у грану за развој
Грана издања сада садржи неки посебан садржај који не постоји у редовној грани развоја. Односи се на све поправке које су имплементиране током периода тестирања. Овај садржај треба поново спојити у развојну грану како би се осигурало да ће поправке остати тамо чак и након следећег издања.
У том тренутку, најновији Релеасе Бранцх служи као производни код за хитне случајеве спреман за поновно распоређивање. Ако хитно питање високог приоритета треба да се реши убрзо након постављања производње, може да користи ову грану. Лако је узети овај код и имплементирати поправку унутра. Ово је још увек тачна копија тренутног производног кода без икаквог новог необјављеног садржаја.
Коначно, када почне нови период тестирања, претходна грана издања може се избрисати и заменити новом. Нови је поново креиран као копија из тренутне развојне гране.
Успоставите редовна издања
А сада га имамо 😀 — солидан процес за приближавање издању. Једина ствар која недостаје је да се посветите редовном одржавању. У овом случају, после сваког другог спринта.
Одржавајући га редовним, заправо постављамо основу за лакше постизање, углавном зато што:
- Ако је издање након не тако дугог времена, нема толико новог садржаја за инсталирање у продукцију. Прираст је мали и сматра се стабилним.
- Сада толико новог садржаја не значи много активности тестирања и креирања тест случајева. Мање комуникација, договора и сарадње са заинтересованим странама о томе шта све треба поново потврдити. Такође ће се сложити да није прошло тако дуго од последњег издања. Дакле, овој акцији се придаје мање значаја.
- Тим ће се навикнути на овај циклус; временом ће то бити природан део тима.
- Као споредни ефекат, окружења за развој и тестирање често добијају освежавање података. То је ионако потребно за сваки нови циклус тестирања. Дакле, то неће бити само још једна планирана активност. Тачније, радња која је већ део устаљеног процеса. Ова промена перспективе има велики утицај на атмосферу тима. Човек у то не би веровао.
Закључак
Ово поглавље завршава моје претходне постове о теми животног циклуса сцрум-а. Такође, ради се о ономе што се показало да функционише у стварном животу.
Често тимови почињу на агилан начин и раде многе ствари погрешно. Затим се на крају развијају и почињу да раде ствари другачије. Ова серија би могла помоћи некима од њих да брже изврше ову промену.
Нити је овај приступ издању једини изводљив, нити је без проблема. Они ће и даље постојати, а тимови морају да се носе са њима. Онда побољшајте оно што је могуће и заборавите оно што нема смисла.
Али колико ја знам, овај приступ, иако једноставан, показао је да је промена могућа. Од хаотичних, непредвидивих спринтева до стабилније испоруке са редовним издањима на која се можете ослонити и планирати. И не захтева посебну, веома компликовану методологију – само једноставна правила и спремност да се следи план.