Codefreeze и непрерывная поставка
Пробки начинаются на перекрестках, когда транспортные потоки вступают в конфликт. Пока один поток движется, другой вынужден ждать. Что-то похожее происходит при выпуске очередного релиза программного продукта: чтобы выпустить продукт достойного качества, приходится останавливать разработку.
Программ без ошибок не бывает. Делая что-то полезное, мы невольно привносим в код то, что не собирались. Иногда неожиданности возникают на стыке, казалось бы, не связанных друг с другом изменений. Вот чудесный пример, как оптимизация драйвера мыши мешает обновлению адресной книги в Outlook. Поэтому всегда наступает такое время, когда команда сосредоточена исключительно на тестировании и исправлении ошибок. Добавление новых функций в это время запрещено.
Но источники новых требований, пожеланий и прочих хотелок не оскудевают. Пока идет стабилизация релиза, очередь на соседнем светофоре / бэклог продукта только растёт. Получается классическая пробка. Как разрешить этот конфликт?
Экстремальное программирование предлагает исправлять ошибки по мере их обнаружения, не останавливая разработку. И вообще, программировать надо без ошибок.Классный метод, мне нравится, но, к сожалению, разработчики всё равно программируют с ошибками. Интересно, почемузачем? Надо будет спросить при случае. В общем, пробки в этом случае не возникает, но какое-то количество аварий / досадных ошибок неизбежно просачивается в релиз. Если стоимость исправления просочившейся ошибки невелика, то этот подход вполне оправдан.
Другая крайность — это классический Waterfall, который призывает не смешивать одно с другим. Сначала все спроектировать, потом аккуратно реализовать, внимательно протестировать, исправить ошибки и результат передать заказчику.
Подход довольно разумный с точки зрения оптимизации затрат, но часто не очень эффективный в условиях неопределенности. При создании новых продуктов часто нет возможности достоверно узнать, что и как должно быть реализовано. Многое делается «на пробу» и переделывается впоследствии. При последовательном прохождении по фазам от идеи до её проверки проходит слишком много времени.
Продвигаясь по проторенному пути, полному проб и ошибок, мне кажется, нам удалось найти разумный компромисс между этими двумя крайностями – обеспечить гибкость, необходимую при разработке новых продуктов, и при этом сохранить высокий уровень качества. В этой статье я хотел бы поделиться нашим опытом, может, кому-то он будет полезен.
Сначала мы попробовали работать короткими итерациями, в результате которых получается работающая, протестированная версия. Ограниченный скоуп итерации помогает команде сконцентрироваться и не отвлекаться. Чтобы успеть устранить все шероховатости к финишу итерации, принято закладывать некоторое время на стабилизацию кода. В это время серьезные изменения в код не вносятся, только исправляются ошибки.
Период стабилизации необходим, он ограничивает количество изменений в коде и делает процесс сходящимся. На практике оказалось, что значительная часть команды в это время скучает: ошибок на всех не хватает. Конечно, всегда есть работа и за пределами итерации, но вносить изменения нельзя — идет стабилизация. А в начале следующей итерации скучают в ожидании новых ошибок тестировщики… Руководство, видя что что работники простаивают, грозится перевести их на другие проекты.
Следующим шагом стала попытка работать по Канбан-методике. Задачи идут непрерывным потоком, после завершения каждой задачи получается версия. Но надежду на качество разрушает основной закон органической химии: если смешать бочку меда и ложку дерьма — получится бочка дерьма. Ситуацию могло бы спасти полное тестирование версии после каждой задачи, но это оказалось слишком дорого как по трудозатратам, так и по времени.
Казалось бы, ситуация безвыходная… Но кто сказал, что изменения нужно вносить туда же, где идет стабилизация?
Сейчас мы работаем по модели «трех уровней нестабильности»:
Из продуктового бэклога мы набираем задач на релиз таким образом, чтобы сделать за месяц. Это наш текущий спринт. Команда приступает к реализации релиза, а ближе к его окончанию, когда изменений немного и работы на всех не хватает, начинаются плавные подготовительные работы к следующему спринту. Работы ведутся в отдельной ветке в гите, в отдельном разделе канбан-доски в Джире. Когда скоуп текущего релиза завершен, протестирован и стабилизирован, ветка релиза становится стабильной, ветка разработки становится базовой для следующего спринта, а ветка разработки замирает в ожидании окончания следующего спринта.
Позвольте, скажет кто-то, но тогда в ветке разработки нет актуальных правок. Да и с ошибками неудобно, их приходится править в двух ветках сразу. Чтобы таких проблем не было, мы договорились любую работу в ветке разработки предварять вливанием изменений из релизной ветки. После этой процедуры ветка разработки содержит все актуальные наработки и исправления ошибок.
Изменения из ветки разработки не попадают в релизную до окончания стабилизации. Это даёт возможность завершить релиз и передать стабильную версию в отдел продаж. А перед началом следующего релиза все наработки попадают в релизную ветку.
Теперь у нас есть непрерывный поток задач и неблокирующая процедура стабилизации релиза, которая позволяет нам выпускать качественные версии, не прекращая разработки.
Следующая точка приложения усилий — сокращение срока стабилизации для уменьшения разрыва между ветками и сокращения общего времени TimeToMarket.
Misusing the term «Code Freeze» [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
I’m just curious if the community considers it acceptable to use the term «Code Freeze» for situations where we stop development except for testing and fixing bugs.
Development Situation
We’re just finishing up our third and final sprint, which will be followed by a «Code freeze» and 2 weeks of Q/A testing. It is a big release and some components development have transcended all 3 sprints. Historically even though we call it a «Code Freeze» we still commit code to fix bugs.
Problem
Every release I try and correct my manager and co-workers that we should be calling it a «Feature Freeze», because it’s pretty obvious that we’re going to find bugs and commit code to fix them as soon as we start heavy testing. But they still persist in calling it a «Code Freeze». Sometimes we still have known bugs and declare a «Code Freeze».
The Wikipedia definition seems to agree with me here
Analysis
I suspect that calling these situations a «Code Freeze» is some sort of willful Double Think to provide false confidence to stake holders. Or we are pretending to be in a «Code Freeze» situation because according to Scrum after every sprint we should have a shippable piece of software and it is the expectation we are following Scrum. So we must call it what Scrum expects instead of what it really is.
Conclusion
Am I over analyzing this? I just find it to be unhealthy to ignoring realities of situations and should either give it up calling it something it’s not or fix the root problem. Has anybody else had similar experiences with Code Freezes?
9 Answers 9
Well, probably. Realistically, you should be thinking twice before making any code changes after the freeze. Bugs should have to pass some severity test, more so if the fix requires potentially-dangerous changes to the codebase or invalidates the testing that’s been done. If you’re not doing that, then yeah, you’re just deluding yourselves.
But if you’re not gonna fix any bugs, then freezing the code is kinda pointless: just build and ship it.
Ultimately, what matters is that you all understand what’s meant by the label, not the label itself. One big happy Humpty-Dumpty.
We use the term «Feature Complete». All the features are coded and functional, but we’re heading into a test pass to confirm that there are no bugs. If there are bugs, we will find them, fix them, and retest. After we’re satisfied with the result, we’re «Code Complete».
Some people who get into adaptive and agile engineering methodologies like scrum may not realise what you have gotten yourselves into.
The reason for being agile engineering is releasing to your customers whatever that is usable now and gradually build up its usability and features.
You have to granularise your modules to the right size and provide a contract-interface specification for each so that changes within a module is managed within a module. If your module by itself or due to dependence of other modules is unable to satisfy a contract-interface, you have to code-freeze to enable you to broadcast a contract-interface version 1 so that other teams could continue albeit with less than expected features in the next general product release.
A code freeze is a code freeze.
If your code freezes are experiencing frequent thawing delays, your scrum master and product architect are not communicating or not doing their jobs properly. Perhaps, there’s no point in trying to impress or acquiesce to your management that they are using some industry fad called agile programming. Or management needs to hire architect and scrum master who are able to design and granularise the project within the skills of the team as well as the expectations of the customers and the technological constraints of the project.
I think there are management elements and their scrum master who do not realise how crucial a good architect is even for a scrum environment and refuse to hire one. A good architect who is able to listen and work with the team is invaluable to the scrumming process because he/she has to constantly adapt the architecture to changing granularities and expectation.
I also think there are management elements and their scrum master who belongs to the other spectrum of the programming universe due to bad experiences with longer development cycles like waterfall, who therefore think that scrum is meant to produce a product within a month and therefore meticulous investigation into cross-modules effects is not really necessary. They sit down, wet their fingers in the air and come up with a great sprint.
If your team is experiencing frequent thawing of code freezes, you guys might need to code-freeze your whole project and rethink your strategy and see that the cause is due to your refusal to define module contracts that fit the granularity of modules. Or are you guys defining module contracts at all to so that features of a stuck module could be currently rarefied to enable other teams or modules to continue.
Без код-фриза были в стрессе и быстро выгорали: как мы внедрили замораживание кода и что оно дает
Senior Software Engineer в Youshido
Замораживание кода или код-фриз (code freeze) может показаться рудиментом в мире, где активно используются agile-методы и принцип непрерывной разработки. Ведь этот подход предлагает сделать паузу для того, чтобы выделить время исключительно на тестирование. Как замораживание кода может помочь командам сегодня? Поделимся собственным опытом.
Подход предлагает сделать паузу, чтобы выделить время исключительно на тестирование
Какой была наша проблема до код-фриза
Постоянные форс-мажоры, когда недавно добавленный функционал переставал работать или ломал уже работающие участки приложения. Из-за того, что нужно было как можно скорее показать результат клиенту, нам часто не хватало времени на качественное тестирование. Иногда приходилось вносить изменения прямо перед презентацией клиенту, или же была ситуация, когда наш первый «платный» пользователь хотел купить премиум версию, но не смог этого сделать из-за механической ошибки в коде.
Такие проблемы часто воспринимаются как обычное дело, ведь в процессе работы могут случаться сбои.
Но разработка без код-фриза создавала лишний стресс, из-за которого увеличивалось количество ошибок и быстро наступало выгорание.
Как мы вводили код-фриз
Осознав, что разработка как можно большего количества новых фич увеличивает скорость, но на практике же снижает качество и нашу эффективность, мы попробовали альтернативный способ использования времени.
Перестать вносить изменения хотя бы на несколько дней
Первым делом вся команда договорилась выделять несколько дней, когда мы перестаем вносить любые изменения в код, который планируется заливать в следующем релизе. Даже если очень хочется и «мне всего пару строк поменять».
На момент введения код-фриза, вопрос планирования времени и овертаймов уже был наболевшим, мы понимали, что нужно больше времени на тестирование, поэтому такое решение было воспринято позитивно. Впрочем, все равно иногда хотелось «быстро добить» какие-то мелочи, но очень важно не соблазняться на подобные «улучшения», так как они могут привести к очередному сбою на продакшене.
Планировать спринты с учетом времени на заморозку кода
Следующим шагом было планирование спринтов с учетом времени на заморозку кода. Наши спринты длились две недели и теперь, вместо активного тестирования в последний момент, мы установили четкие временные рамки.
На разработку нового функционала выделили 1,5 недели, а остальную часть — исключительно на код-фриз.
Понять, готовы ли заливать обновления
После того, как все было проверено, последним шагом оставалось решить, готовы ли мы заливать обновления с учетом текущего состояния приложения. В нашем случае могло быть три варианта развития событий:
Что нам дал код-фриз?
Недостатки код-фриза
В общем, это универсальный инструмент, ведь это о планировании времени, а не о тонкостях написания кода.
Единственное, такой подход, вероятно, не очень хорошо сработает в условиях постоянной неопределенности, как, например, в стартапах, где срочные задания могут влиять на спланированный процесс.
Тем не менее, когда нам нужно внедрить ключевые обновления, которые влияют на поведение всего продукта, мы «замораживаем» код и много-много тестируем.
Также вначале может быть тяжело принять то, что теперь вы ставите меньшее количество задач на спринт. Представьте ситуацию, когда вы договорились встретиться с товарищем, он приходит раньше и спрашивает, через сколько вы будете. Допустим вам реально идти 12-15 минут. Если вы скажете «через 10 минут» — это то, как мы работали раньше. Нужно чтобы или все пошло идеально, или очень спешить. Теперь же мы отвечаем «20 минут» и точно укладываемся в установленный срок без спешки.
Неправильное планирование — одна из главных причин срыва дедлайнов. Задержки приводят к финансовым убыткам, а разработка в стрессе — к большему количеству ошибок и регрессии. Если подобное хотя бы частично касается вашей команды, код-фриз может стать отличным решением, так как приближает к главной цели любой парадигмы построения процессов — выполнять задания вовремя и качественно.
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Не пишем код целый месяц и нам нормально
Праздничные дни для Додо Пиццы — дни высокой нагрузки. К таким дням мы готовимся заранее и заводим специальные правила.
Самое жаркое время — в декабре: много корпоративов, заказы становятся больше, но и прибыль выше. Во многих городах плохая погода — где-то снег только выпал и дороги не расчищены, где-то очень холодно. Всё вместе это создаёт нагрузку и на IT, и на бизнес. От нагрузки может сломаться что угодно: то очередь задач переполнится, то печь выйдет из строя. Чтобы быть готовыми, мы регулярно проводим нагрузочные тестирования, повышаем закупки ингредиентов, распределяем заказы по пиццериям и много чего ещё.
Для мобильных разработчиков конец года раньше тоже был особенным: с 23 по 27 декабря App Store закрывался на рождественские праздники, приложения не проверялись, опубликовать что-то было невозможно.
Расскажу, как эти ограничения влияют на разработку, какие ошибки мы совершили в прошлые годы и что меняется в расписании. Возможно, что-то из практик пригодится и вам: подсветит риски, поможет договориться о код-фризе с бизнесом.
Опыт прошлых лет
Так получилось, что прошлые декабри проходили у нас довольно стрёмно. Например, пару лет назад мы делали конструктор комбо и зарелизили его в в начале декабря. Оказалось, что фреймворк Dip переполнился от количества связей в DI и приложение стало очень долго запускаться. На новых телефонах это не было заметно, а вот на стареньких iPhone 5 и 6 оно даже не успевало стартануть за 30 секунд!
Мы подозревали, что DI может сломаться, но не подозревали, что это произойдёт так внезапно. Переделать описание всех зависимостей перед последним релизом сулило ещё большие потери, чем могли быть в тот момент. Подробно рассказывали об этом в статье «Бардак на старте: постмортем на скорость запуска iOS-приложения».
На следующий год мы сделали вывод и в начале ноября вспомнили, что надо проверить ключевые показатели заранее. Увы, даже это оказалось поздно для бизнес-планирования: в начале декабря должен был выйти крупный релиз сразу от трёх команд:
в Сыктывкаре запускали заказ через приложение в ресторане, чтобы проверить бизнес-процессы. Отменить было нельзя, потому что маркетинг уже подготовил все активности;
в Великобритании для пиццерии нового формата сделали другой флоу выбора адреса;
начали оповещать пользователя о высокой нагрузке на пиццерию и предлагали сделать отложенный заказ. Фича хорошая — помогает бизнес-процессам и снижает негатив клиентов. Плохо было только то, что выпускали её в середине декабря — к этому времени она была очень нужна и был только один шанс зарелизить. Если в тестировании на продакшене оказалось бы, что в процессах пиццерии что-то идёт не так, то поправить уже ничего не смогли бы.
Вроде бы изменения точечные и касались региональных тестов, но поздний запуск сыграл против нас.
Во-первых, выяснилось, что пиццерия в Сыктывкаре находится в подвале и там плохо ловит связь, поэтому нужно было срочно менять способ загрузки изображений, экономить трафик и переходить с JPEG на более современный формат, что влияет сразу на все приложения. Без этого тестировать в ресторане нечего, приложение у людей совсем не показывает картинки и они не делают заказы.
Во-вторых, флоу Великибритании сильно влияет на старт приложения, хитро переиспользует существующие фреймворки, из-за скорости разработки решение получилось запутанным, в январе пришлось переписывать.
В третьих, визуализация нагрузки на пиццерию была написана в спешке и покрывала лишь самый простой случай, поэтому наше решение задачу решало лишь частично.
В итоге тот релиз вышел не очень стабильный и в декабре мы выпустили аж три хотфикса, а потом ещё в январе доделывали и рефакторили.
Стало понятно, что начало ноября — слишком поздно для планирования. Про Новый год нужно думать в конце сентября, до начала четвёртого квартала.
Планируем даты и размер релизов. Релиз-фриз
Давайте посмотрим на календарь и поймём, какие критичные даты у нас есть. Начнём с конца декабря.
С 23 по 27 декабря нельзя релизить приложения в App Store, в Америке рождество. Apple заранее рассылала письма и предупреждала, что сроки сдвинутся. Для многих компаний Новый год — важное время, все хотят закончить свои задачи, а это значит, что неполная неделя с 20 по 23 будет сложной для ревьюверов и время на ревью может увеличиться.
В этом году Apple перестала уходить на рождественские каникулы, тем не менее, ревью может быть медленнее обычного.
Это не изменило наши планы, нагрузка на пиццерии не зависит от Apple, но напряжение от сроков стало меньше.
По статистике, каждый наш релиз требует хотя бы одного хотфикса. Значит, нужно на неделе с 13 до 15 декабря сделать последний релиз, чтобы успеть исправить, если что-то пойдёт не так.
Проблема не только в том, что мы иногда косячим, но и в том, что в мобильной разработке релизы катятся медленно и фидбэк с продакшена может прийти слишком поздно:
если релиз раскатывается постепенно, то за неделю получим обновление у 40% людей;
если релиз был открыт на 100%, то за неделю приложение обновится лишь у 70% людей;
через месяц обновятся только 90%, а оставшиеся 10% растянуты на годы, хвост старых версий очень долгий.
Получается, что если мы хотим к Новому году закончить фичу и сразу запустить рекламу на неё, то, чтобы не нагружать саппорт вопросами «почему у меня нет такого функционала?», стоит раскатить нужный функционал хотя бы за 2-3 недели до запуска и спрятать его за фича-тоглом до нужного момента.
С другой стороны, если столкнёмся с проблемой, то остановить релиз тоже не получится: приходят новые пользователи и они всегда получают последнюю версию, даже если в ней есть проблемы.
Есть и другие причины отодвинуть релизы подальше от конца декабря и праздников в январе:
некоторые баги воспроизводятся только в редких ситуациях, за полторы недели пользователи достаточно повзаимодействуют с системой, чтобы можно было считать, что все критичные редко встречающиеся баги всплывут и будут исправлены до Нового года;
некоторые проблемы с надёжностью могут иметь накопительный эффект и стрельнуть только при длительной работе под нагрузкой или без перезапуска серверов (как, например, медленное, но уверенное «выжирание» памяти или ЦПУ), поэтому важно посмотреть на работу системы вдолгую, прежде чем со спокойной душой уходить на каникулы;
Если мы хотим, чтобы система прожила без нас полторы недели в январе, то давайте посмотрим, как она проживет полторы недели в декабре хотя бы без релизов.
Исходя из этого, мы приняли несколько правил.
С 1 декабря по 15 не должно выходить очень крупных изменений. Если изменений будет много, то за один хотфикс можно и не успеть всё поправить или изменения не дойдут до пользователя.
Все фичи, которые выходят в декабре, должны быть спрятаны за фича-тоглом и уметь отключаться. У нас есть механизм фича-тоглов, поэтому некоторый функционал можем отключать без релиза. В худшем случаем мы останемся без фичи, но люди смогут заказывать.
Увы, некоторые изменения слишком дорого или невозможно тоглить, например инфраструктурные изменения (переход на Tuist). Получается, что зарелизить их нужно ещё раньше, чтобы успеть исправить до того, как начнётся декабрь и высокий трафик. Крайний срок больших изменений — середина ноября.
У бэкенда процессы немного другие: нет ревью от вендора, а обновление происходит сразу для всех, поэтому релизы можно катить чаще.
В итоге наш график сейчас такой:
15 ноября — последний релиз инфраструктуры в мобильной разработке, когда не можем оттоглить наши изменения;
29 ноября — последний срок большого релиза, все фичи должны быть затоглены. Если нашли баг, то нужно срочно катить фикс;
6 декабря — последний мажорный релиз бэкенда;
13 декабря — последний возможный релиз небольшой фичи.
До изменения режима работы App Store наш график релизов выглядел так, как на картинке выше. По нему видно, что с середины ноября мы не можем катить большие фичи, а это половина квартала. Такое очень важно учитывать при планировании: поменьше взять в работу, запланировать релиз важных фич пораньше. Релизить можно до 13 декабря, но размер и ценность релизов должны плавно снижаться, чтобы сохранять правильный темп, не торопиться, не косячить и в итоге не падать.
Как «продать» код-фриз бизнесу и разрулить конфликты
Неожиданным оказалось то, что продать код-фриз бизнесу несложно: показываете риски, обсуждаете возможные потери, требуете от аналитиков прогноза по доходу от фичи, составляете risk-reward, планируете сроки и как-то быстро приходите к договорённостям.
На деле намного сложнее продать код-фриз программистам: появляются десятки вопросов, уточнений, что можно и что нельзя сделать.
Релизы декабря лидеры направлений и SRE одобряют в ручном режиме. Покажу на примере.
Команда хочет выпустить фичу, которая будет рассказывать о нашей новой программе лояльности и персональных акциях. Виджет должен появиться на экране меню и визуально изменения небольшие.
Сине-фиолетовая плашка в центре экрана — герой примера
Уточнив у разработчика, понимаем, что для добавления простой плашки пришлось переверстать весь экран меню (там накопилось теходолга, нужно было исправить), при этом мы добавили анимации на обновление экрана, а они могут конфликтовать и ломать приложение. Это старт приложения, т.е. критичный путь пользователя до заказа, и если что-то пойдёт не так, то мы заденем большую часть пользователей. Затоглить такой рефакторинг сложно, он только повысит шансы что-то упустить. По-хорошему такая фича должна чуть дольше «помариноваться» в dev-ветке среди тестировщиков и разработчиков.
С другой стороны, мы рассказываем про бонусную программу. Это хорошо для возвращаемости клиентов, но не несёт прямого профита, эффект от фичи будет заметен не сразу.
При этом времени у нас мало: чтобы закончить фичу, нужно отложить все остальные дела и, возможно, подключить другую команду. Не только придётся торопиться, но и поломать процессы, повысить напряжение и количество коммуникаций, что приведёт к меньшей стабильности. При этом релиз — не конец пути, могут быть ещё и хотфиксы, команда должна быть готова к этому, а не выжата под конец сезона.
Хочется всё ровно наоборот: фича может зарелизиться, но только если мы всё сделали спокойно, контролируем и можем безопасно откатиться.
Решение: не торопимся, фича выйдет в январе.
Подготовка к Новому году
Раз новогодние праздники — это время повышенных нагрузок, то нужно к этому подготовиться. Мы постоянно проводим нагрузочное тестирование для бэкенда, хотя бы потому, что пиковые дни в Додо Пицце случаются равномерно круглый год: 14 и 23 февраля, 8 марта, 1 и 9 мая, 1 июня, 1 сентября. Тем не менее, Новый год — продолжительнее. Сначала он даёт высокую нагрузку в декабре, а затем долгий период без релизов в январе, поэтому нужно уделить особое внимание тем местам, до которых обычно руки не доходят.
Повысить качество сервиса
Подумать о кейсах, которые могут всплыть при нагрузке на пиццерии. Например, заказы на отложенное время очень часто приходятся на обед, а это сверхнагрузки на производственную линию. Вместе с корпоративами и большими заказами комбо-наборов это может создавать лавинный эффект, мы не сможем или произвести, или доставить такое количество.
Узнать у саппорта о самых частых проблемах, разобрать кейсы, специфичные для Нового года. Так мы снизим нагрузку на поддержку и дадим им возможность обработать наплыв обращений.
Снизить нагрузку на процессы. Например, если везём заказ дольше часа, то дарим сертификат на следующую бесплатную пиццу. Недавно эти сертификаты стали электронным и теперь они не могут закончиться, курьер не сможет забыть его выдать — это просто больше не его задача.
Повысить прозрачность
Построить дашборды, которые покажут потенциальные проблемы.
Подчистить ошибки в логах, чтобы не отвлекаться на них в случае ЧП.
Убрать старые тоглы, чтобы удалить код и «выпрямить» его. Возможно, так и проблемы покажутся.
Проверить места отказа
Профилировать приложение по скорости и памяти, добавить трейсинг на важные места.
Поднять crash free.
Проверить безопасность приложения.
Проверить старые версии iOS.
Проверить сценарий недоступности бэкенда при высоком количестве заказов.
Обработать недоступность пиццерий 1 и 2 января, когда заказ сделать нельзя.
Таким образом, все задачи делятся на два блока: либо повышаем качество наших проверок, либо готовимся к потенциальной нагрузке (и даже возможным падениям). Лучше перебдеть.
Подойти к задачам можно двумя способами:
если задач много и они важные, то стоит выделить общий спринт-«субботник», когда все команды берут задачи из бэклога подготовки к Новому году и сфокусировано разгребают его, не отвлекаясь на фичевые задачи;
если задач немного или они некритичные, то можно делать их в общем потоке, лишь сместив баланс фичи/теходолг в пользу второго.
В мобильной разработке мы пошли вторым путём, а бэкенд временами устраивает субботник на пару дней.
Не релизишь? Не пиши код. Код-фриз
По расписанию последний релиз 13 декабря, затем две недели до Нового года мы ничего не релизим, а ведь в январе ещё пара недель праздников. Между релизами проходит месяц, за это время обратную связь от пользователей получить невозможно.
Если две недели все будут писать код и не будут его релизить, то после каникул у нас на продакшен поедет туча изменений, что резко повышает риск что-то сломать.
За время каникул могут происходить инциденты, и хотфиксы, с ними связанные. С большой вероятностью придётся решать мёрж-конфликты не только с релизом, который был написан до Нового года, но и со всеми хотфиксами, которые уже на продакшене.
После возвращения с каникул можно просто утонуть и запутаться в своём и чужом коде, который был написан в предпраздничном настроении. А уж если это придётся делать на инциденте после неудачного большого релиза.
Для планирования сроков важно понимать, какое время поставки кода на продакшен.
Мобильные приложения у нас релизятся каждые пару недель, для них остановка релизов в декабре не будет заметна.
Бэкенд релизится несколько раз в день. Для него простой в пару недель превращается в огромную проблему: изменения копятся, риски увеличиваются, миграции выстраиваются в ряд. Ком изменений может быть настолько огромным, что мы останавливаем разработку на этот срок. Не релизишь — не пишешь код.
Релиз-фриз бэкенда влияет на мобильную разработку: довольно мало фич, которые бы мы можем сделать на фронте без изменений бэкенда, поэтому тоже перестаём разрабатывать 13 декабря:
неделю мы оставляем для критичных фиксов;
неделю не могли зарелизить из-за магазинов;
вопросы про остальные две недели надо направить президенту РФ.
Выходит, это целый месяц «ничего-не-делания». Или не совсем?
Что ещё полезного можно делать в код-фриз
Если не пишем фичи, то это не значит, что все уходим в отпуск (хотя отпуск — тоже вариант). Что можно делать в код-фриз:
заняться инфраструктурой переводов, сборки или релиза;
заняться дизайн системой и доступностью;
учиться тестам, писать тесты, профилировать приложение;
составлять или причёсывать бэклог;
удалять лишние файлы с компа, открытые вкладки браузера прочитать и закрыть, заметки разобрать;
писать запросы к аналитике, строить дашборды;
проверять работу приложений на старых версиях телефонов;
читать статьи, писать статьи, готовить презентации, снимать видео;
проходить курсы, готовиться к ним или проводить их;
придумывать идеи для 1 апреля и пробовать их.
Чем ближе к Новому году, тем больше хочется отдыхать и развлекаться, поэтому в последние дни декабря мы уходим в отрыв и устраиваем хакатон. Конкурс проходит как в офисе, так и удалённо: все участники получают промокод на пиццу от компании, в случае победы подарки отправляются адресатам в разные города. Так в прошлом году мы попробовали написать App Clip. До релиза он не дошёл, но сделали прототип и поняли, как нам распиливать приложение. К App Clip мы ещё вернёмся!
Счастливого Нового года!
Весь четвёртый квартал у нас проходит в особом режиме: реального времени на разработку в два раза меньше, нужно заранее учесть задачи для подготовки к высокой нагрузке, а в середине декабря наступает код-фриз.
Основная цель всего этого планирования — чтобы всем было хорошо и спокойно: задачи делались в размеренном темпе и выходили вовремя, «нежданчиков» и горячки минимум, в декабре отличная прибыль, а в январе все отдыхаем и не выбегаем на работу по пейджеру.
Многое из рассказанного — лишь заплатки на те процессы, которых пока нет на регулярной основе. Тем не менее, подготовка раз в год позволяет справиться с текущими проблемами.
Подписывайтесь на канал Dodo Mobile, я напомню о наступающем Новом годе в следующем сентябре.
