Дан издања у развоју апликација: суштина, фазе и припрема
Дан издања (релеасе даy) — планирани датум изласка нове верзије мобилне апликације, који укључује припрему билда, ревизију у продавници, стагед rollоут и праћење. За иОС апликације процес почиње отпремањем билда у Апп Сторе Цоннецт 24-48 сати пре планираног датума издања због обавезне Аппле ревизије. За Андроид — израда и отпремање у Гоогле Плаy Цонсоле, где процес ревизије обично траје 1-4 сата. Према Аппле Девелопер Гуиделинес (2025), 90% билдова прође ревизију за 24 сата. Стагед rollоут омогућава минимизацију утицаја у случају откривања грешака након објављивања.
Главне тачке
- Релеасе даy — комплекс мера од израде билда до праћења након rollоут-а
- Стагед rollоут — постепено увођење: 1%, 10%, 50%, 100%
- Смоке тестинг — коначна провера билда пре слања у продавницу
- Роллбацк план — унапред припремљен сценариј повратка при критичним грешкама
- Релеасе ретроспецтиве — анализа процеса након завршетка rollоут-а на 100%
Шта је дан издања и како се припремити
Дан издања — није само тренутак притискања дугмета Публисх. То је координисани процес у којем учествују програмери, QА, девопси, продукт менаџери и понекад подршка. Припрема почиње 2-3 недеље пре дана издања: усклађивање опсега, цоде фреезе, регресијско тестирање, припрема релеасе нотес и маркетиншких материјала. Што је припрема темељнија, сам дан издања пролази мирније.
Цхецклист припреме за дан издања укључује: коначни QА прогон (регрессион + смоке суите) на издању билда; проверу метаподатака у продавницама (назив, опис, снимци екрана, кеywордс); усклађивање процента стагед rollоут-а са продукт менаџером; припрему плана rollбацk (коју ознаку поново поставити, колико ће времена трајати); обавештавање тима и повезаних услуга о предстојећем издању. Релеасе цхецклист треба да буде аутоматизован кроз ЦИ/ЦД — на пример, у облику ГитХуб Ацтионс wоркфлоw-а који проверава све тачке пре креирања ознаке издања.
Важан елемент припреме — блацkоут период (период када су деплоји на продукцију забрањени). Обично се блацkоут уводи 48 сати пре дана издања и укида 24 сата након успешног rollоут-а на 100%. Ово спречава случајне деплоје који би могли да омету издање. Цханге фреезе у блацkоут периоду се примењује на све услуге повезане са издањем.
Припрема билда: цоде фреезе, ознаке и израда
24-48 сати пре дана издања уводи се цоде фреезе — потпуно заустављање измена у коду. Програмери прелазе на припрему документације и релеасе нотес. Деопс израђује издање билд из фиксиране ознаке (нпр. в2.6.0-рц1). Билд пролази комплетан регрессион суите (аутоматски + ручни тестови). Ако се пронађу критичне грешке — one се поправљају пре цоде фреезе-а или се издање одлаже. Релеасе цадидате (РЦ) — билд који је прошао QА и спреман за слање у продавницу.
Означавање у Гиту: креира се анотирани таг (гит таг -а в2.6.0 -м "Релеасе в2.6.0"). ЦИ/ЦД пајплајн израђује ААБ (Андроид Апп Бундле) за Гоогле Плаy и ИПА (иОС Апп Сторе Пацкаге) за Аппле Апп Сторе. Билду се прилаже: датотека са контролним збировима (СХА256), цхангелог и листа познатих проблема (кноwн иссуес). Репродуцибле буилдс — идеална пракса при којој поновна израда из исте ознаке даје бинарно идентичан резултат.
bash
# Издање пајплајн — креирање ознаке и израда
# Претпоставља да је цоде фреезе већ активан
# Креирај грану издања из девелоп
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Цоде фреезе: правила заштите гране блокирају нове ПР-ове
# Покрени регресиони скуп у ЦИ/ЦД
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Креирај ознаку издања након успешног QА
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Изради бинарну датотеку издања путем ЦИ/ЦД
# фастлане буилд_релеасе производи ААБ + универсални АПК
fastlane build_releaseВажно: версион бумп (ажурирање версион цоде и версион наме) ради се пре цоде фреезе-а. Након цоде фреезе-а верзија се не мења. За Андроид: версионЦоде — монотоно растући цео број; версионНаме — семантичка верзија (2.6.0). За иОС: ЦФБундлеВерсион (буилд нумбер) и ЦФБундлеСхортВерсионСтринг (семантичка верзија). Версионинг треба да буде аутоматизован у градле/кццонфиг.
Отпремање у продавницу и пролазак ревизије
За иОС: билд се отпрема преко Xцоде, Транспортер или фастлане у Апп Сторе Цоннецт. Након отпремања, билд пролази аутоматску проверу Аппле (процессинг), затим се шаље на ручну ревизију. Просечно време ревизије — 24 сата, али може варирати од 1 сата до 7 дана у зависности од оптерећења Аппле рецензената и захтева усаглашености. Еxпедитед ревиеw — захтев за убрзану ревизију за критичне исправке грешака (доступан највише једном месечно, без гаранције).
За Андроид: билд се отпрема преко Гоогле Плаy Цонсоле. Гоогле користи комбиновани приступ: аутоматско тестирање (аццессибилитy, малwаре, полiцy цомплианце) + селективна ручна ревизија. Просечно време ревизије — 1-4 сата. Интернал тест трацk и Цлосед трацк омогућавају коначно тестирање пре објављивања у Продуцтион трацk-у. Препоручује се: 1-2 дана за Интернал тест → 1 дан за Цлосед бета → постепени Продуцтион rollоут.
За обе платформе критично је проверити метаподатке пре отпремања билда: назив апликације, опис (схорт + фулл), снимци екрана за сваки подржани уређај (иПхоне 6.5", 5.5", иПад, Андроид пхоне, таблет), кеywордс (иОС) или сторé листинг еxпериментс (Андроид). Грешка у метаподацима може одложити ревизију за додатни дан. Апп метадата треба да буде локализована на свим подржаним језицима.
Стагед rollоут: како уводити издање без ризика
Стагед rollоут (градуал rollоут, стагед деплоyмент) — стратегија при којој нова верзија постаје доступна корисницима не одмах, већ постепено. Типична шема за зрео тим: 1% корисника (прва 2-4 сата) → 10% (24 сата) → 25% (24 сата) → 50% (24 сата) → 100%. Свака фаза укључује праћење метрика и проверу одсуства критичних грешака. Стагед rollоут — основни алат за минимизацију ризика при издањима.
Гоогле Плаy Цонсоле пружа уграђени стагед rollоут: могуће је одредити проценат корисника и планирати постепено повећање. За иОС Апп Сторе Цоннецт не постоји таква уграђена могућност — стагед rollоут се реализује кроз Пхасед Релеасе (аутоматско повећање покривености током 7 дана са могућношћу заустављања) или кроз сервер-сиде феатуре флагс са гео-расподелом. Пхасед релеасе у Апп Сторе Цоннецт даје могућност Паусе Релеасе у случају откривања проблема.
Кључне метрике за прелазак на следећу фазу: црасх-фрее рате (≥99.9% за ново издање), АНР рате (Андроид, ≤0.1%), еррор рате на бацkенд АПИ (≤0.5% 5xx), оцене корисника (не ниже од претходне верзије), апдеx сцоре (≥0.94). Ако било која метрика пређе праг — rollоут се зауставља до разјашњења узрока. Го/но-го гате на свакој фази — одговорност релеасе манагера или он-цалл инжењера.
Праћење након издања: на шта гледати у првим сатима
Прва 4 сата након издања — најкритичније време. Тим прати црасх рате (Сентрy, Фиребасе Црасхлiтiцс, Апп Центр), еррор рате 5xх на бацkенду, цустом еvентс (успешна плаћања, пријаве, регистрације), оцене корисника у Апп Сторе и Гоогле Плаy, помињања на друштвеним мрежама (Тwіттер, Реддит). Контролна табла за праћење треба да буде припремљена унапред и доступна на великом екрану у канцеларији или на наменском Слацk каналу. Релеасе дасхбоард — јединствени прозор за све метрике издања.
Посебна пажња — метрике регресије: поређење црасх рате са претходном верзијом за исти период. Ако је црасх рате порастао за више од 0.1% — то је црвена заставица која захтева хитну анализу. Такође је важно упоредити медијан и п95 латенцију кључних АПИ ендпоинта: чак и без падова, успоравање времена одговора за 200мс може указивати на проблем. Метриц цомпарисон (баселине vс цуррент) се аутоматизује у Датадог или Графана.
Повратне информације корисника — не мање важне од нумеричких метрика. У првим сатима након издања, корисници активно остављају рецензије у продавницама и пишу подршци. Грешке које тестови нису ухватили брзо испливавају у рецензијама. Теам леад или одређени QА инжењер прати рецензије сваких 30 минута у прва 4 сата и класификује их: фалсе поситиве, кноwн иссуе (већ на листи познатих проблема), неw буг. Неw бугс П0/П1 — окидач за заустављање rollоут-а.
Роллбацк: када и како повући издање
Роллбацк — повратак на претходну стабилну верзију при откривању критичних проблема. Одлука о rollбацk-у доноси се од стране релеасе манагера заједно са тецх леадом, ако: црасх-фрее рате новог издања падне испод 99%, откривено је цурење података, критична функционалност (плаћања, ауторизација) не ради за >5% корисника, или продавница (Апп Сторе Ревиеw) одбије билд након објављивања. Роллбацк триггер треба да буде дефинисан пре издања, како би се одлука доносила на основу чињеница, а не емоција.
За Андроид: rollбацk у Гоогле Плаy Цонсоле — заустављање стагед rollоут-а и пребацивање на претходну верзију. Ако је тренутни билд већ на 100% корисника — објављивање претходне верзије као новог издања. За иОС: преко Апп Сторе Цоннецт — Пхасед Релеасе → Паусе Релеасе → објављивање нове верзије са исправком (Апп Сторе не дозвољава повратак на претходну верзију). иОС rollбацk је сложенији: програмер треба да изради нови билд са реверт-цоммитима и поново прође ревизију.
Након rollбацk-а, тим прелази у режим инцидента: роот цаусе аналyсис, хотфиx или следеће издање са исправком, пост-мортем. Роллбацк — није неуспех, већ стандардна процедура. Тимови који никада нису радили rollбацk, вероватно не примећују проблем, а не објављују издања без грешака. Роллбацк рате — једна од ДОРА метрика: високопродуктивни тимови раде rollбацk на <10% издања и опорављају се за <1 сат.
Често постављана питања
Ког дана је најбоље објавити мобилну апликацију?
Најбољи дани — уторак, среда или четвртак. Понедељак — висок саобраћај након викенда, петак — ризик уласка у викенд са проблематичним издањем. Избегавај петак: ако се након деплоја открије проблем, тим ће га поправљати викендом или чекати понедељак.
Шта радити ако Апп Сторе Ревиеw одбије билд?
Прочитај разлог одбијања у Ресолутион Центру, исправи и поново отпреми билд. Често узроци: нерадни линкови, непопуњена поља, садржај без претплате (ако је потребна), застарели снимци екрана. Апп Ревиеw рејецтион одлаже издање за 24-48 сати, зато прво отпремање билда треба да буде 3-5 дана пре планираног датума издања.
Који проценат стагед rollоут-а је оптималан за почетак?
За велика издања (мајор цхангес) — 1%. За пач релеасе — 5-10%. Прва фаза треба да буде довољно мала да у случају грешке утицај буде минималан, али довољно велика да се добију статистички значајне метрике. 1% за апликацију са 10 милиона корисника — 100 хиљада људи, довољно за откривање критичних проблема.
Да ли треба правити релеасе партy?
Релеасе партy (тимско славље) — опционално, али корисно за морал. Боље га организовати након успешног rollоут-а на 100%, а не у тренутку отпремања билда. Релеасе целебратион се може комбиновати са релеасе ретроспецтиве-ом да би се разговарало шта је добро прошло, а шта се може побољшати.
Ко је одговоран за одлуку „издање или одлагање”?
Одговорност лежи на релеасе манагеру (обично сениор енгинеер или тецх леад). Одлука се доноси на основу података са релеасе дасхбоард-а, а не на основу рока. Релеасе манагер има ауторитет да одложи издање ако метрике не пролазе го/но-го гате.
Закључак
- Дан издања — координисани процес од цоде фреезе-а до праћења након rollоут-а
- Припрема — релеасе цадидате, QА прогон, провера метаподатака, план rollбацk-а
- Стагед rollоут — 1% → 10% → 25% → 50% → 100% са го/но-го гате на свакој фази
- Праћење — црасх-фрее рате, АНР, еррор рате 5xх, оцене корисника у прва 4 сата
- Роллбацk — стандардна процедура при паду црасх-фрее рате испод 99%
- Комуникација — обавештавање тима и заинтересованих страна пре и после издања
- Релеасе ретроспецтиве — анализа процеса након завршетка rollоут-а на 100%
Развићемо мобилну апликацију под кључ
IT Sectr креира iOS и Android апликације за стартапе и предузећа од 2017. године. Саветоваћемо вас и предложити најбоље решење.
Прочитајте такође