Блог

Всеволод Фролов
Начальник отдела управления проектами

Правила, сложившиеся в команде, или «Технику безопасности я знаю, как свои три пальца»

Существуют правила, которые определяет методология разработки, а есть такие, которые команда выработала в процессе работы, на основе своего опыта.

Не допускается публикация релиза или патча в последний рабочий день перед выходными или праздниками

Любой релиз может потребовать каких-то дополнительных действий. Пострелизные тесты придуманы не просто так. То, что они выявят, может потребовать дополнительных усилий и времени. Если сделать обновление к вечеру пятницы, времени на изменения не остается. По закону Мерфи критичность проблем, выявленных в вечер пятницы, выше среднего.

Ветка нового релиза создается автоматически, утром, в первый день спринта

Автоматическое создание ветки, во-первых, стимулирует разработчика соблюдать свои оценки и избегать лишней работы. Во-вторых, создание дополнительной области, в которую нужно чекинить, порождает дополнительные трудности для тех, кто поленился и затянул решение задачи/бага.

При разработке с использованием веток (бранчей) найденные баги в виде копий заводятся во все текущие бранчи

После того как в разработке продукта мы доросли до использования веток, было обнаружено, что иногда реализованный функционал чудесным образом пропадает в последующих релизах. Забыть зачекинить в соседний бранч  это любимые грабли тех времен. Поэтому мы тратим немного времени на копирование задач, но больше на эти грабли не наступаем.

Команду на публикацию релиза дает отдел тестирования

С этим трудно поспорить, однако в истории было и по-другому. «Ускорение» публикации со стороны заказчика или менеджера, или тимлида  все эти действия лишь ухудшают качество продукта. Только отдел тестирования, который отвечает за качество, может принять решение и разрешить обновление боевой площадки.

Никаких изменений боевой СУБД без участия отдела тестирования быть не может

СУБД не является частью кода проекта, и иногда возникает желание что-то в ней «подкрутить». Как правило, причиной является желание добавить производительности или другая оптимизация. И даже если «крутит» знающий человек, все последствия его действий могут быть ему не видны. Но они обязательно проявятся, если провести тестирование. Недавно произошел классический случай: вне релиза, без проверок, добавили новое поле в конец таблицы боевой БД. Казалось бы, что в нашем, написанном по всем правилам коде может поломаться? Но нашелся-таки кусок, в котором все поля таблицы выгребались через *. И порядок столбцов в результатах запроса «поехал».

Структура базы при публикации релиза должна меняться скриптом, который протестирован на совместимость не только с новой версией, но и с предыдущей. Скрипты бывают предрелизные и пострелизные, в зависимости от времени выполнения по отношению к состоянию площадки.

К релизу пишется файл комментариев, в котором указаны все сопутствующие релизу настройки

В файле комментариев для каждого пункта должен быть указан ответственный исполнитель. Комментарии к релизу выполняет и контролирует администратор при публикации. Неправильный порядок выполнения скриптов, отсутствие настройки в конфигурации, недозаполненный контент  все это может вызвать ошибки при тестировании. Чтобы релиз прошел по плану, порядок действий нужно соблюдать как на тестовой, так и на боевой площадке.

Каждая задача в системе управления должна быть связана с номером чекина (коммита)

На первый взгляд это правило не должно влиять на качество кода или релиза. Однако в нашей практике это правило оказалось ключевым для процесса разработки, оно позволяет проследить задачу от описания до реализации, быстро найти место в коде, которое менялось в рамках задачи. Вместе с договоренностью писать комментарий к чекину, указание в нем номера задачи обеспечивает целостность процесса, оно позволяет быстро обнаруживать и решать проблемы, находить автора ошибки, понимать список задач, которые включены в релиз или патч.