Проверочный список на качество управления релизами.
Управление релизами складывается из нескольких практик, практики в большей степени технические и инструментальные, но простые, а потому будут понятны даже тем менеджерам проектов, которые выросли не из программистов, а из каких-то других областей. Кроме того, практически все они так или иначе работают на одну главную идею: распространение информации между участниками проекта.
1. Весь код проходит через репозитарий. Все кусочки проекта, созданные руками людей, должны лежать в репозитарии. Тесты, например. Или инсталляционные скрипты. Или системная документация: требования, спецификации, диаграммы. Вот логи, например, в репозитарий класть не надо — вам не потребуется управление версиями логов. Как не надо класть и упакованный (скомпилированный) код вашего проекта или документацию, собранную по исходому коду. Потому что логи и пакеты собираются автоматически и в любой момент можно эту процедуру повторить. Чтобы повторить необходимый вам набор логов, вам нужен сценарий тестирования (автоматического или ручного — второй вопрос), пройдясь по которому вы получите от системы необходимые журналы. Чтобы получить пакет или скомпилировать код, вам должно быть достаточно запустить одну команду — команду сборщика. Maven это будет, make или rake — это уже на ваше усмотрение.
2. Команда видит изменения в репозитарии. Заведите почтовый лист, подпишите всех разработчиков на него, и настройте отправку в этот лист сообщений об изменениях в репозитарии и комментариях к этим изменениям. Это первый шаг к рецензированию кода и хорошая основа для внедрения всех остальных практик работы с системой контроля версий. Кроме того, наглядность событий, происходящих в проекте, позволит участникам проекта учиться друг у друга хорошим подходам. Надо только не забывать помогать с определением, какой подход хороший, а какой — так себе.
3. Проект автоматизированно собирается двумя командами. Первой (и единственной) командой он вынимается из репозитария, вторая команда — сборщик. В итоге вы можете в любой момент максимально быстро и без шаманств получить проект, готовый к публикации. Если вы готовите проект к проведению тестов, то для этого создается отдельная задача сборщику, которая запустит все тесты, которые вы на текущий момент наавтоматизировали.
4. У проекта есть версии. Существуют ветки разработки и есть четко зафиксированные версии проекта. Подробнее про это — в тексте Как управляться с версиями проекта.
4. Багтрекер используется для отслеживания задач. Если есть задача, ей должен соответствовать тикет. У вас есть багтрекер? Научите его работать с задачами, а сами возьмите за правило — как только ставите кому-то задачу, пишите сразу про это тикет и назначайте за него ответственного.
5. Каждому изменению в репозитарии соответствовует тикет. Номер тикета или ссылку на багтрекер указывайте в комментариях к ревизии. После это сильно облегчит разбор полетов — какие именно изменения вносились в проект для решения той или иной задачи. При внесении изменений в репозитарий указывайте в комментариях к соответствующему тикету номер ревизии, соответствующей этому изменению. Как следствие: одно изменение — один тикет. Не стоит вносить в репозитарий сразу несколько изменений и решать тем самым несколько тикетов, это усложнит исследование и анализ проведенных изменений.
6. У проекта есть Changelog — история изменений проекта от версии к версии. Данные в нем актульны (еще лучше — собираются автоматически, например, багтрекером), участники команды знают, где его найти, как им пользоваться.
7. Проект обновляется автоматически. Исталляция боевого кода вообще должна уметь обновляться, а также откатываться к предыдущей версии без каких-либо потерь данных. Кроме того, желательно, чтобы это можно было делать максимально автоматизированно. Чем меньше времени простаивает обновляемый сервис, тем более густыми и шелковистыми будут волосы на голове у менеджера проекта.
Управление релизами складывается из нескольких практик, практики в большей степени технические и инструментальные, но простые, а потому будут понятны даже тем менеджерам проектов, которые выросли не из программистов, а из каких-то других областей. Кроме того, практически все они так или иначе работают на одну главную идею: распространение информации между участниками проекта.
1. Весь код проходит через репозитарий. Все кусочки проекта, созданные руками людей, должны лежать в репозитарии. Тесты, например. Или инсталляционные скрипты. Или системная документация: требования, спецификации, диаграммы. Вот логи, например, в репозитарий класть не надо — вам не потребуется управление версиями логов. Как не надо класть и упакованный (скомпилированный) код вашего проекта или документацию, собранную по исходому коду. Потому что логи и пакеты собираются автоматически и в любой момент можно эту процедуру повторить. Чтобы повторить необходимый вам набор логов, вам нужен сценарий тестирования (автоматического или ручного — второй вопрос), пройдясь по которому вы получите от системы необходимые журналы. Чтобы получить пакет или скомпилировать код, вам должно быть достаточно запустить одну команду — команду сборщика. Maven это будет, make или rake — это уже на ваше усмотрение.
2. Команда видит изменения в репозитарии. Заведите почтовый лист, подпишите всех разработчиков на него, и настройте отправку в этот лист сообщений об изменениях в репозитарии и комментариях к этим изменениям. Это первый шаг к рецензированию кода и хорошая основа для внедрения всех остальных практик работы с системой контроля версий. Кроме того, наглядность событий, происходящих в проекте, позволит участникам проекта учиться друг у друга хорошим подходам. Надо только не забывать помогать с определением, какой подход хороший, а какой — так себе.
3. Проект автоматизированно собирается двумя командами. Первой (и единственной) командой он вынимается из репозитария, вторая команда — сборщик. В итоге вы можете в любой момент максимально быстро и без шаманств получить проект, готовый к публикации. Если вы готовите проект к проведению тестов, то для этого создается отдельная задача сборщику, которая запустит все тесты, которые вы на текущий момент наавтоматизировали.
4. У проекта есть версии. Существуют ветки разработки и есть четко зафиксированные версии проекта. Подробнее про это — в тексте Как управляться с версиями проекта.
4. Багтрекер используется для отслеживания задач. Если есть задача, ей должен соответствовать тикет. У вас есть багтрекер? Научите его работать с задачами, а сами возьмите за правило — как только ставите кому-то задачу, пишите сразу про это тикет и назначайте за него ответственного.
5. Каждому изменению в репозитарии соответствовует тикет. Номер тикета или ссылку на багтрекер указывайте в комментариях к ревизии. После это сильно облегчит разбор полетов — какие именно изменения вносились в проект для решения той или иной задачи. При внесении изменений в репозитарий указывайте в комментариях к соответствующему тикету номер ревизии, соответствующей этому изменению. Как следствие: одно изменение — один тикет. Не стоит вносить в репозитарий сразу несколько изменений и решать тем самым несколько тикетов, это усложнит исследование и анализ проведенных изменений.
6. У проекта есть Changelog — история изменений проекта от версии к версии. Данные в нем актульны (еще лучше — собираются автоматически, например, багтрекером), участники команды знают, где его найти, как им пользоваться.
7. Проект обновляется автоматически. Исталляция боевого кода вообще должна уметь обновляться, а также откатываться к предыдущей версии без каких-либо потерь данных. Кроме того, желательно, чтобы это можно было делать максимально автоматизированно. Чем меньше времени простаивает обновляемый сервис, тем более густыми и шелковистыми будут волосы на голове у менеджера проекта.
