Состав релизов
Состав и график релизов ведут:
- либо отдельно в системе документации;
- либо через файл change.log;
Не факт, что то что описано, было на самом деле единственным изменением в рамках релиза. Иногда, мы можем автоматически получить более достоверное описание собрав информацию в логах системы контроля версий. Как правило, ветки релизов имеют характерный префикс "release". Например:
Обнаружив такую ветку в логах мы можем:
- зафиксировать дату создания;
- состав релиза (ветки, которые в неё были влиты);
- возможную дату поставки (когда с веткой релиза перестали совершать какие-либо манипуляции)
Состав релиза
Отображать состав релиза в каком-либо документе важно потому что:
- это показывает прогресс команды;
- клиентам понятна разница между версиями;
- можно отследить путь, когда в проде появилась та или иная ошибка;
Т.к. у нас есть возможность увидеть состав релиза в логах, мы можем не только отобразить его для просмотра статистики, но и автоматически сформировать "release note" (технический документ с описанием релиза):
Какие проблемы может показать статистика
Разрыв времени между поставками.
Если наши релизу идут с разницей +/- 3 рабочих дня, а потом появляется релиз, который сдвинул следующий на пару недель, это повод провести разбор причин срыва поставки.
Важно понять какие событие к этому привели и как избежать их в будущем.
Несоответствие состава.
Т.к. состав релиза система сформирует автоматически, он может не совпасть с тем, который заполнили руками. Самая частая причина этого явления: команда (или часть команды) льет скрытый функционал или исправляет неопубликованные ошибки.
Почему так происходит? Однозначно ответить нельзя. Где-то пытаются сократить отставание тестирования от разработки, где-то проводят рефакторинг (на который не выделило время руководство), где-то пытаются исправить аварии, которые еще не успели эскалировать или вовсе не заметили.
Долгие поставки.
Если процесс поставки в команде не налажен и происходит редко, то, как правило, это приводит к долгим поставкам. Это увеличивает показатель "Time-to-market" и является негативным фактором для бизнеса, т.к. он становится менее гибким.
Кроме того, это существенно увеличивает вероятность багов. Если релиз легко собрать, то и фикс критического бага в нем занимает очень мало времени. А в этом случае картина обратная. Даже если мы легко исправили баг, сам процесс докатки обновления до прода займет очень много времени.
Если вы оказались в данной ситуации — поговорите с командой и узнайте, что вы можете изменить, чтобы сократить время поставки в вашей компании.