Так много говорят о системных администраторах, разработчиках, тестировщиках… Захотелось поговорить про тех, без кого не обходится ни одна энтерпрайз-разработка. Build Manager, так-же известный как Release Engineer, остается героем в тени — мало кто о нем знает. Кто же он?
Это одна из первых моих публикаций в сети. Я не претендую на звание специалиста в области, о которой пойдет речь, и ни в коем случае не позиционирую статью как руководство к действию. Я лишь попытался собрать воедино свой маленький опыт, и хочу попробовать поделиться своими мыслями с хабрасообществом.
Все хорошо, пока продукт маленький. Пока маленькая команда, и все друг друга знают в лицо. Но как только продукт разрастается до нескольких десятков здоровенных модулей, каждым из которых занимается отдельная команда разработчиков, а под самые важные модули даже выделяется отдельная команда QA — все становится очень печально. В разработке начинают применяться методологии, например Scrum. Инстоллер продукта начинает разрабатывать отдельная команда. Сам продукт весит более 2ГБ, и компиляция занимает порядка трех часов. Сборка дистрибутива продукта для конечных пользователей уже давно перестала быть тривиальной задачей, ведь у многих кастомеров есть персональные фичи или патчи, которые не вносятся в мэйнстрим, а разработка основных модулей продукта ведется полностью независимо. К этому времени вы уже вряд-ли найдете человека, который помнит этот продукт в зародыше, и прошел вместе с ним весь путь. Пора с этим что-то делать, а именно — создать новую команду. Назовем ее Build Factory.
Чем может заняться эта команда? Разработкой. Только не самого продукта, и не инстоллера, а так называемого Build Framework. Пора начинать вести документацию, придумывать правила, какой модуль за каким собирать, и как паковать это все потом в инстоллер. Ну и, соответственно, автоматизировать весь процесс. Называется это Continious Integration. Рассмотрим более детально.
Build Factory может взять на себя следующую ответственность:
Конечно, все зависит от спецификации проекта, языка, выбранной методологии разработки, размера штата, географической отдаленности команд друг от друга и еще кучи факторов. Но все-же, есть общие черты.
Такой подход существенно увеличивает скорость разработки. Вместо по разному собранных модулей продукта единый Build Framework собирает каждый модуль унифицированно. А с помощью CI команда QA получает в свое распоряжение новую версию продукта настолько быстро, насколько это возможно. Другими словами, Build Factory помогает находить Dev & QA командам общий язык.
Disclaimer
Это одна из первых моих публикаций в сети. Я не претендую на звание специалиста в области, о которой пойдет речь, и ни в коем случае не позиционирую статью как руководство к действию. Я лишь попытался собрать воедино свой маленький опыт, и хочу попробовать поделиться своими мыслями с хабрасообществом.
Проблема
Все хорошо, пока продукт маленький. Пока маленькая команда, и все друг друга знают в лицо. Но как только продукт разрастается до нескольких десятков здоровенных модулей, каждым из которых занимается отдельная команда разработчиков, а под самые важные модули даже выделяется отдельная команда QA — все становится очень печально. В разработке начинают применяться методологии, например Scrum. Инстоллер продукта начинает разрабатывать отдельная команда. Сам продукт весит более 2ГБ, и компиляция занимает порядка трех часов. Сборка дистрибутива продукта для конечных пользователей уже давно перестала быть тривиальной задачей, ведь у многих кастомеров есть персональные фичи или патчи, которые не вносятся в мэйнстрим, а разработка основных модулей продукта ведется полностью независимо. К этому времени вы уже вряд-ли найдете человека, который помнит этот продукт в зародыше, и прошел вместе с ним весь путь. Пора с этим что-то делать, а именно — создать новую команду. Назовем ее Build Factory.
Build Factory
Чем может заняться эта команда? Разработкой. Только не самого продукта, и не инстоллера, а так называемого Build Framework. Пора начинать вести документацию, придумывать правила, какой модуль за каким собирать, и как паковать это все потом в инстоллер. Ну и, соответственно, автоматизировать весь процесс. Называется это Continious Integration. Рассмотрим более детально.
Ответственность
Build Factory может взять на себя следующую ответственность:
- Скрипты сборки
Не секрет, что уже давно де-факто стандарт использовать специальные инструменты для сборки, такие как Ant, Maven, CMake и прочие. Отныне написанием и поддержкой скриптов может заняться Build Factory. Благодаря этому со временем они начинают полностью контроллировать процесс интеграции модулей между собой, потому что раньше, когда каждая команда писала свой скрипт для своего модуля — все было не особо унифицировано и усложняло интеграцию модулей между собой.
- Поддержка SCM
Контроллировать брэнчи продукта, и, фактически, контролировать версионность продукта — задача, с которой Build Factory отлично справиться. Опять-же, версионность разных модулей продукта станет выглядеть однородно, что снова облегчит интеграцию модулей между собой.
- Continious Integration
Это основная часть работы Build Factory. Идея такова — разработчики просто коммитят код в SCM, не более. Всем остальным занимаются билд-сервера в автоматическом режиме. Есть отличные CI Systems, такие как Jenkins\Hudson, Electriс Commander, Cruise Control, etc… Все они по сути представляют собой один большой кроссплатформенный планировщик с веб-интерфейсом, возможностью кластеризации и прочими плюшками. Подробности могу написать отдельной статьей, если кому интересно, пока лишь для затравки скажу следующее. После выполнения пунктов 1 и 2, настройки CI System процесс разработки будет выглядеть следующим образом. Разработчики коммитят код, CI System по расписанию или триггеру (например, если есть новые коммиты в SCM с момента последнего успешного билда) запускает юнит-тесты, запускает скрипты сборки модулей (возможно параллельно, если это позволяет архитектура проекта), дожидается результатов, пакует их в инстоллер, и заливает на инстолл-сервер. Так-же можно запустить после успешной сборки на каком-нибудь тестовом environment автоматическое тестирование, которое любезно предоставит команда QA, а так-же подготовить продукт для ручного тестирования (например в случае Java web-приложения, задеплоить продукт на тестовый Tomcat, наполнить базу тестовыми данными и прочее в таком духе). Пользоваться CI System может каждый, кому это нужно в рамках выбранной методологии разработки. Например, QE, может нажать одну большую кнопку «BUILD IT!», подождать, и получить готовый к тестированию продукт на тестовом сервере. Иногда очень удобно таким образом, после ряда манипуляций, сбросить состояние продукта к исходному.
- Поиск виновников
Когда билд падает, именно Build Factory в состоянии оперативно найти того, кто сделал фатальный коммит (если пункт 3 выполнен правильно). Это ускоряет процесс фикса и восстановления обычного жизненного цикла продукта.
- Саппорт разработчиков
Не секрет, что не все разработчики знают именно ту SCM, которая используется в компании. Build Factory в состоянии саппортить таких людей, а так-же организовывать тренинги для них.
- Релизы продуктов
В зависимости от методологии разработки, в принципе любой успешный билд может быть назван релизным. Но если по каким то причинам это не может произойти, то созданием специального релизного билда (и дистрибутива) может заниматься Build Factory.
Что должен знать Build Manager
Конечно, все зависит от спецификации проекта, языка, выбранной методологии разработки, размера штата, географической отдаленности команд друг от друга и еще кучи факторов. Но все-же, есть общие черты.
- Понимать, как происходит процесс разработки в рамках выбранной методологии.
- Уметь писать скрипты для сборки.
- Уметь работать с CI System.
- Далеко не все задачи можно выполнить с помощью скриптов сборки или CI System, потому знание скриптового или (даже лучше) нативного языка приветствуется.
- Нужно много общаться, коммуникативный скилл очень важен. Только представьте, вам может понадобиться уговорить несколько команд сразу перейти с Ant на Maven, или с SVN на Git.
Выводы
Такой подход существенно увеличивает скорость разработки. Вместо по разному собранных модулей продукта единый Build Framework собирает каждый модуль унифицированно. А с помощью CI команда QA получает в свое распоряжение новую версию продукта настолько быстро, насколько это возможно. Другими словами, Build Factory помогает находить Dev & QA командам общий язык.
