Введение
Грамотно налаженные и состоявшиеся процессы — не для нас! Это ведь скучно, когда все уже настроено и работает как часы, но к этому надо стремиться. А уж после порадоваться проделанной работе и очередной раз проверить, как же все хорошо работает…
Очень важно, какой код попадает в продуктивную эксплуатацию. Важна его стабильность и предсказуемость. При использовании жестких регламентов контроля качества скорость внедрения нового функционала будет непременно снижаться.
В связи с этим часты ситуации, когда заказчику поставляется достаточно сырой «разработческий» код, после минимального тестирования. Это влечет за собой множество проблем.
Н.Н.У
Представим себе обычную ситуацию в проекте. Проекту уже полгода, он еще молод и не особо функционален. Изменения вносятся ежеминутно распределенной командой. Заказчик требует новый функционал чуть ли не мгновенно после его реализации.
Возникает соблазн использовать непрерывную интеграцию, выражающуюся в обновлении серверов заказчика кодом из основной ветки разработки.
Постулат 1: Код в основной ветке разработки нестабилен
В этом случае подход обновления кода у заказчика будет приносить лишь проблемы. Надо обязательно фиксировать срез кода, выражающийся в версии и устанавливать у заказчика только код с версией.
Конечно, можно возразить на постулат 1, что код в основной ветке стабилен. Да, такое возможно, если имеется достаточное покрытие модульными тестами, проводится обширное функциональное и интеграционное тестирование. QA-отдел очень суров. Код разрабатывается в ветках и переносится в основную ветку только после тщательного тестирования.
Во множестве проектов нет отдела контроля качества и тестирования, часто нет никаких тестов. Вся разработка ведется в основной ветке. Вот для таких проектов и озвучен постулат 1.
Выпустите версию
Ваш код еле компилируется, имеется множество ошибок, фатальных и не очень, заказчик начинает седеть от вида и поведения системы? Выпускайте версию!
Выпустите версию этого недо-продукта. Объявите заказчику о версии и обрисуйте приблизительную дату выпуска следующего релиза. Это действует магически. Заказчик хочет новую версию продукта, у разработчиков есть целая итерация, чтобы без воплей заказчика и давления руководства писать код и править ошибки.
Мотивация
Речь идет о выпуске первой версии. Она самая важная, так как на основе нее потом будет строиться весь продукт. Без нее не будет остальных версий успешного продукта. Да и команде становится спокойнее за свою работу. Конечно, важно после выпуска первой версии не сбиться с темпа и в кратчайшие сроки выпустить вторую версию продукта, более стабильную и еще более желанную заказчиком.
Плюсы
Из положительных моментов выпуска версии можно выделить:
- Создание «точки отсчета» продукта;
- Регламентированное попадание нового функционала к заказчику;
- Повышение стабильности и качества продукта;
- Нормальный ритм работы команды;
- Широкие возможности планирования развития продукта;
- «Контролируемость» разработки;
- Простое исправление ошибок без внесения большего количества новых.
Минусы
Есть и недостатки выпуска первой версии на ранних этапах работы над проектом:
- «Стрельба трассирующими» по заказчику. Не каждый к этому готов;
- Новые трудозатраты для выпуска версии;
- Замедление поставки нового функционала заказчику на итерацию.
Не исключаю, что каждый читатель сможет привести еще по паре плюсов и минусов выпуска первой сырой версии.
Заключение
В большинстве компаний не найти человека с должностью «build-master». С таким человеком процесс выпуска версий протекает гораздо проще. Но и без него можно выпускать версии своего продукта. Ну а самая первая версия, это только начало долгой жизни программы.
К тому же, выпуск версии рождает в коллективе интересные и забавные традиции. Самые простые из них: походы в бар, вечерние настольных игр, сеансы кино, сетевые игры всей командой.
Н.Н.У — Нулевые Начальные Условия.
Автор: VaiMR
