Разработка любого современного программного продукта не обходится без использования системы управления версиями программного кода (например, Subversion). Данный пост о том, что в некоторых случаях для успешного выпуска продукта одной только системы управления версиями становится недостаточно, и необходимо использовать некоторый инструмент для расширения ее функциональности.
Разработчики имели разный опыт работы в нашем проекте Intel® Media SDK, и, как следствие, разное понимание рисков и последствий, которые несли их коммиты. Коммиты не тестировались разработчиками вовсе, или объем их тестирования был недостаточен.
Некоторые некорректные/не вовремя сделанные коммиты (например, ориентированные не на текущую, а на следующую версию продукта) приводили к появлению существенных (show stopper) ошибок на стадии, непосредственно предшествующей выпуску продукта. В условиях ограниченного временного ресурса разработчики испытывали немалые трудности в установлении причин их появления. Так как ошибки не могли быть исправлены немедленно, это приводило к сдвигу даты выпуска продукта.
Все это усложнялось еще и тем, что не всегда коммиты в системе управления версиями достаточно хорошо комментировались. Любые попытки изменить такое положение дел в нашем проекте были безуспешными.
Как решение вышеназванных проблем в нашем проекте был разработан CCB – Change Control Board tool с использованием Apache, MySQL, PHP на основе open source Emergenices Personnel Information System (EMPRIS) (распространяемого под Artistic License).
CCB “включается” обычно за 2-3 недели перед запланированным выпуском Beta версии продукта. Специальный скрипт отслеживает появление новых коммитов в Subversion и заносит их в базу данных CCB. Автору коммита приходит e-mail приглашение с ссылкой на web форму. После ее заполнения коммит переводится в инструменте в состояние “SUBMITTED”. В инструменте все коммиты достаточно хорошо описываются автором коммита, включая информацию, зачем коммит сделан, что было изменено, как было протестировано, какой риск несет коммит для продукта.
Все коммиты инспектируются рядовыми разработчиками — ревьюерами (peers) и лидером проекта. Имена ревьюеров назначаются инструментом автоматически или могут быть выбраны автором коммита. Ревьюер получает e-mail приглашение, следует по ссылке из письма, принимает или отклоняет коммит. Если коммит принимается, то он переводится в состояние “ACCEPTED”.
Только промоутер (лидер проекта) наделен правами переносить коммит в специальный тег, из которого в конечном итоге по последней ревизии берется исходный код продукта. Промоутеру приходит e-mail приглашение на инспектирование коммита. Если коммит принимается промоутером, то он переводится в состояние “PROMOTED”, а изменения исходного кода коммита добавляются в тег.
Хотя CCB не исправляет ошибки в продукте, инструмент значительно упрощает процесс локализации коммита, приведшего к возникновению обнаруженных ошибок. С помощью CCB удобно получать дополнительную информацию о коммитах. Инструмент обладает удобным search engine для того, чтобы по запросу отбирать коммиты, сделанные:
CCB стал хорошим примером эффективного “административного ресурса”, когда другие методы повысить “культуру” коммита программного кода в проекте не работали. Фактически даже когда разработчик исправляет какую-нибудь обнаруженую ошибку, то для полного выполнения данной задачи ему недостаточно просто закоммитить свои изменения в Subversion, коммит обязан пройти все шаги инспектирования в CCB. Если коммит не пройдет всю процедуру инспектирования в инструменте, то он не попадет в продукт. В тег попадают только нужные лидеру проекта коммита.
Таким образом, CCB существенно увеличивает ответственность авторов за коммиты. CCB также выполняет функции peer code review и служит инструментом для создания логов и индикаторов.
CCB используется в течение 4 лет в нашем проекте и за это время получил немало отзывов от пользователей и соответственно улучшений функциональности. Привожу некоторые из них из числа наиболее запомнившихся.
1. коммит по CCB шаблону (печатается в комментарии в Subversion). Является альтернативой входу в инструмент и заполнению полей в web форме.
CCB шаблон:
2. внеочередной промоут коммитов. При промоуте строится список зависимостей коммита. Коммит не может быть перенесен в тег (запромочен), если другие коммиты с ранней ревизией еще не прошли инспектирование. Когда одновременно инспектируются два или более зависимых коммита, то инструмент не позволяет запромоутить коммит, сделанный позже, первым, чтобы не вызвать конфликт ревизий. Однако, в случае, когда делается выборочный промоут коммитов, и промоутер полностью уверен в правильности такого промоута, то он может запромоутить более поздний, не дожидаясь более ранних коммитов.
3. упрощенное инспектирования для отдельных коммитов. Если автор по каким-то уважительным причинам не предоставил описание своего коммита в CCB, следовательно, не отослал коммит на инспектирование (например, отсутствовал на месте). Напоминание не помогает, а коммит нужно запромоутить срочно. То лидер проекта может изменить состояние любого коммита.
4. несколько промоутеров с равными правами. Если лидер проекта по каким-то причинам не может запромоутить коммит, то это могут сделать другие назначенные промоутеры.
5. промоут в несколько выбранных тегов. Два проекта могут использовать одинаковую ветку программного кода и отличаться в некотором ограниченном наборе коммитов. Для таких проектов удобно использовать разные теги. Тогда по умолчанию код промоутится сразу оба тега, а для отдельных коммитов по выбору промоутера только в один тег.
Упрощение инспектирования коммитов для отдельных компонентов. Если компонент не особенно важен, то для экономии времени было бы лучше переносить коммиты в этом компоненте сразу в тег без их инспектирования.
А какими инструментами пользуетесь вы?
Гладко было на бумаге
Разработчики имели разный опыт работы в нашем проекте Intel® Media SDK, и, как следствие, разное понимание рисков и последствий, которые несли их коммиты. Коммиты не тестировались разработчиками вовсе, или объем их тестирования был недостаточен.
Некоторые некорректные/не вовремя сделанные коммиты (например, ориентированные не на текущую, а на следующую версию продукта) приводили к появлению существенных (show stopper) ошибок на стадии, непосредственно предшествующей выпуску продукта. В условиях ограниченного временного ресурса разработчики испытывали немалые трудности в установлении причин их появления. Так как ошибки не могли быть исправлены немедленно, это приводило к сдвигу даты выпуска продукта.
Все это усложнялось еще и тем, что не всегда коммиты в системе управления версиями достаточно хорошо комментировались. Любые попытки изменить такое положение дел в нашем проекте были безуспешными.
Как решение вышеназванных проблем в нашем проекте был разработан CCB – Change Control Board tool с использованием Apache, MySQL, PHP на основе open source Emergenices Personnel Information System (EMPRIS) (распространяемого под Artistic License).
Как инструмент работает?
CCB “включается” обычно за 2-3 недели перед запланированным выпуском Beta версии продукта. Специальный скрипт отслеживает появление новых коммитов в Subversion и заносит их в базу данных CCB. Автору коммита приходит e-mail приглашение с ссылкой на web форму. После ее заполнения коммит переводится в инструменте в состояние “SUBMITTED”. В инструменте все коммиты достаточно хорошо описываются автором коммита, включая информацию, зачем коммит сделан, что было изменено, как было протестировано, какой риск несет коммит для продукта.
Все коммиты инспектируются рядовыми разработчиками — ревьюерами (peers) и лидером проекта. Имена ревьюеров назначаются инструментом автоматически или могут быть выбраны автором коммита. Ревьюер получает e-mail приглашение, следует по ссылке из письма, принимает или отклоняет коммит. Если коммит принимается, то он переводится в состояние “ACCEPTED”.
Только промоутер (лидер проекта) наделен правами переносить коммит в специальный тег, из которого в конечном итоге по последней ревизии берется исходный код продукта. Промоутеру приходит e-mail приглашение на инспектирование коммита. Если коммит принимается промоутером, то он переводится в состояние “PROMOTED”, а изменения исходного кода коммита добавляются в тег.
Процесс оправдал результат
Хотя CCB не исправляет ошибки в продукте, инструмент значительно упрощает процесс локализации коммита, приведшего к возникновению обнаруженных ошибок. С помощью CCB удобно получать дополнительную информацию о коммитах. Инструмент обладает удобным search engine для того, чтобы по запросу отбирать коммиты, сделанные:
- в определенный отрезок времени;
- в определенном компоненте;
- определенным разработчиком;
- для определенной ошибки;
- для определенной компоненты;
- для определенной платформы.
CCB стал хорошим примером эффективного “административного ресурса”, когда другие методы повысить “культуру” коммита программного кода в проекте не работали. Фактически даже когда разработчик исправляет какую-нибудь обнаруженую ошибку, то для полного выполнения данной задачи ему недостаточно просто закоммитить свои изменения в Subversion, коммит обязан пройти все шаги инспектирования в CCB. Если коммит не пройдет всю процедуру инспектирования в инструменте, то он не попадет в продукт. В тег попадают только нужные лидеру проекта коммита.
Таким образом, CCB существенно увеличивает ответственность авторов за коммиты. CCB также выполняет функции peer code review и служит инструментом для создания логов и индикаторов.
Усложнять просто, упрощать сложно
CCB используется в течение 4 лет в нашем проекте и за это время получил немало отзывов от пользователей и соответственно улучшений функциональности. Привожу некоторые из них из числа наиболее запомнившихся.
Добавленные функции после получения отзыва от пользователей (в порядке их поступления):
1. коммит по CCB шаблону (печатается в комментарии в Subversion). Является альтернативой входу в инструмент и заполнению полей в web форме.
CCB шаблон:
summary: краткое описание коммита в том числе зачем сделан коммит [необязательное поле]
bug: номер бага [обязательное поле]
what changed: краткое описание изменений в исходнм коде [обязательное поле]
how tested: краткое описание действий по тестированию коммита [обязательное поле]
reviewer: email ревьюера [необязательное поле]
comments: другие комментарии [необязательное поле]
2. внеочередной промоут коммитов. При промоуте строится список зависимостей коммита. Коммит не может быть перенесен в тег (запромочен), если другие коммиты с ранней ревизией еще не прошли инспектирование. Когда одновременно инспектируются два или более зависимых коммита, то инструмент не позволяет запромоутить коммит, сделанный позже, первым, чтобы не вызвать конфликт ревизий. Однако, в случае, когда делается выборочный промоут коммитов, и промоутер полностью уверен в правильности такого промоута, то он может запромоутить более поздний, не дожидаясь более ранних коммитов.
3. упрощенное инспектирования для отдельных коммитов. Если автор по каким-то уважительным причинам не предоставил описание своего коммита в CCB, следовательно, не отослал коммит на инспектирование (например, отсутствовал на месте). Напоминание не помогает, а коммит нужно запромоутить срочно. То лидер проекта может изменить состояние любого коммита.
4. несколько промоутеров с равными правами. Если лидер проекта по каким-то причинам не может запромоутить коммит, то это могут сделать другие назначенные промоутеры.
5. промоут в несколько выбранных тегов. Два проекта могут использовать одинаковую ветку программного кода и отличаться в некотором ограниченном наборе коммитов. Для таких проектов удобно использовать разные теги. Тогда по умолчанию код промоутится сразу оба тега, а для отдельных коммитов по выбору промоутера только в один тег.
Не добавленная еще функция:
Упрощение инспектирования коммитов для отдельных компонентов. Если компонент не особенно важен, то для экономии времени было бы лучше переносить коммиты в этом компоненте сразу в тег без их инспектирования.
А какими инструментами пользуетесь вы?