Существуют правила, которые определяет методология разработки, а есть такие, которые команда выработала в процессе работы, на основе своего опыта.
Не допускается публикация релиза или патча в последний рабочий день перед выходными или праздниками
Любой релиз может потребовать каких-то дополнительных действий. Пострелизные тесты придуманы не просто так. То, что они выявят, может потребовать дополнительных усилий и времени. Если сделать обновление к вечеру пятницы, времени на изменения не остается. По закону Мерфи критичность проблем, выявленных в вечер пятницы, выше среднего.
Ветка нового релиза создается автоматически, утром, в первый день спринта
Автоматическое создание ветки, во-первых, стимулирует разработчика соблюдать свои оценки и избегать лишней работы. Во-вторых, создание дополнительной области, в которую нужно чекинить, порождает дополнительные трудности для тех, кто поленился и затянул решение задачи/бага.
При разработке с использованием веток (бранчей) найденные баги в виде копий заводятся во все текущие бранчи
После того как в разработке продукта мы доросли до использования веток, было обнаружено, что иногда реализованный функционал чудесным образом пропадает в последующих релизах. Забыть зачекинить в соседний бранч – это любимые грабли тех времен. Поэтому мы тратим немного времени на копирование задач, но больше на эти грабли не наступаем.
Команду на публикацию релиза дает отдел тестирования
С этим трудно поспорить, однако в истории было и по-другому. «Ускорение» публикации со стороны заказчика или менеджера, или тимлида – все эти действия лишь ухудшают качество продукта. Только отдел тестирования, который отвечает за качество, может принять решение и разрешить обновление боевой площадки.
Никаких изменений боевой СУБД без участия отдела тестирования быть не может
СУБД не является частью кода проекта, и иногда возникает желание что-то в ней «подкрутить». Как правило, причиной является желание добавить производительности или другая оптимизация. И даже если «крутит» знающий человек, все последствия его действий могут быть ему не видны. Но они обязательно проявятся, если провести тестирование. Недавно произошел классический случай: вне релиза, без проверок, добавили новое поле в конец таблицы боевой БД. Казалось бы, что в нашем, написанном по всем правилам коде может поломаться? Но нашелся-таки кусок, в котором все поля таблицы выгребались через *. И порядок столбцов в результатах запроса «поехал».
Структура базы при публикации релиза должна меняться скриптом, который протестирован на совместимость не только с новой версией, но и с предыдущей. Скрипты бывают предрелизные и пострелизные, в зависимости от времени выполнения по отношению к состоянию площадки.
К релизу пишется файл комментариев, в котором указаны все сопутствующие релизу настройки
В файле комментариев для каждого пункта должен быть указан ответственный исполнитель. Комментарии к релизу выполняет и контролирует администратор при публикации. Неправильный порядок выполнения скриптов, отсутствие настройки в конфигурации, недозаполненный контент – все это может вызвать ошибки при тестировании. Чтобы релиз прошел по плану, порядок действий нужно соблюдать как на тестовой, так и на боевой площадке.
Каждая задача в системе управления должна быть связана с номером чекина (коммита)
На первый взгляд это правило не должно влиять на качество кода или релиза. Однако в нашей практике это правило оказалось ключевым для процесса разработки, оно позволяет проследить задачу от описания до реализации, быстро найти место в коде, которое менялось в рамках задачи. Вместе с договоренностью писать комментарий к чекину, указание в нем номера задачи обеспечивает целостность процесса, оно позволяет быстро обнаруживать и решать проблемы, находить автора ошибки, понимать список задач, которые включены в релиз или патч.