Выбор платформы

Речь пойдет о программно-аппаратной платформе, которая позволит в полной мере раскрыть потенциал системы непрерывной интеграции.

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

Выбор железа не менее прост, в случае с системой непрерывной интеграции -- мало ресурсов не бывает. Тем не менее, тратить огромные ресурсы на вспомогательную, на первый взгляд, задачу никто не будет. Рекомендации очень просты: оптимальное (на момент выбора) количество ядер, память из расчета 2Гб на ядро и быстрая, насколько это возможно, дисковая подсистема.

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

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

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

Инсталляция системы

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

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

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

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

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

Начальная инсталляция: тестова и реальная системы

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

Например, некоторые компании запрещают вносить какие-либо изменения в инфраструктуру проекта до его завершения, лишая разработчиков многих преимуществ и неявно подстегивая их к отказу от использования полезных инструментов вообще.

Для основной системы может быть использован кластер

Инсталляция является делом нехитрым и реализуется средствами выбранного контейнера. Автор, в данном конкретном случае, использует Tomcat (http://tomcat.apache.org/), соответственно, после инсталляции двух экземпляров, список активных приложений выглядит следующим образом:

Менеджер приложений

Каждый Jenkins/Hudson, в свою очередь, выглядит следующим образом:

Система непрерывной интеграции

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

1. различать основной и вспомогательный серверы непрерывной интеграции
2. четко понимать к какому именно проекту относится тот или иной Jenkins/Hudson (если их несколько)
3. визуально "интегрировать" инструмент в инфраструктуру проекта

Минимальный набор необходимых действий сводится к замене двух элементов внешнего оформления:

• логотипа  (webapps\<app-name>\images\title.png)
• образа Jenkinsa/Хадсона (webapps\ci-secondary\images\hudson.png)

После выполнения необходимых действий, оба приложения приобретут следующий вид:

Основная система

Вспомогательная система

Стоит помнить о возможности потерять данные изменения при переходе на новую версию путем простой замены файла приложение (war архива).

Выбор инструмента

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

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

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

Автор отдает предпочтение Jenkins/Hudson и во всех последующих примерах будет использовать именно эту систему.

Непрерывная интеграция — зачем?

Начнем с пародии на известный анекдот:
- Папа, папа, а что такое непрерывная интеграция?
- Подожди сынок, сейчас файлы разложу, библиотеки скопирую, скрипты запущу, билд соберу, тесты выполню, версию поправлю, все заархивирую, на FTP выложу и покажу.

Машины должны работать, люди должны думать. Это еще бородатые парни из IBM знали. Для современных разработчиков доступна масса средств и методов принуждения машин к выполнению рутинной работы, а себя любимых — к пространным рассуждениям о прекрасном. Тем не менее, очень часто можно увидеть покрывшегося испариной "спеца", который пытается с помощью вороха скриптов, нескольких заученных команд и чьей-то матери собрать наконец БИЛД.

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

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

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