Во-первых, я настоятельно рекомендую вам прочитать «Непрерывная доставка» (Джез Хамбл, Дэвид Фарли), там есть много информации по этому вопросу. Здесь есть пример главы .
С тех пор, как я прочитал это, я начал реализовывать конвейер сборки, где каждый коммит svn проходит через каждый этап конвейера, а среда постепенно становится похожей на производство по мере продвижения сборки. Мы используем Дженкинс для этого.
- Стадия коммита - dev sanity - компилировать, модульный тест и некоторые метрики. это
На начальном этапе также создаются двоичные файлы, необходимые для остальной части
трубопровод
- Этап интеграции - это те же файлы, что и
предыдущий этап (не новая проверка) и запускает интеграционные тесты БД в
память
- Этап автоматического приемочного испытания - принимает двоичные файлы из
этап фиксации и развертывание на сервере, где мы запускаем тесты на селен
- Стадия QA - она используется qa, который просто нажимает кнопку, чтобы потянуть
независимо от того, какую сборку они хотят, она просто развертывает двоичные файлы
от этапа фиксации к серверу QA
- UAT - то же самое, что QA, но более производительная среда, где мы также проводим тесты производительности
- Производство - переводит двоичные файлы из этапа фиксации и развертывает их в производство.
Каждый из этих этапов выступает в качестве «шлюза качества» - сборка не может продолжаться до тех пор, пока не пройдет некоторый порог - сбои тестирования, показатель% s и т. Д. Некоторые этапы выполняются автоматически, другие запускаются вручную. Любые изменения конфигурации, необходимые для каждой среды, выполняются путем распаковки исходных двоичных файлов, изменения настроек, их повторной упаковки - в идеале я хотел бы отделить конфигурацию от двоичных файлов приложения, но пока не нашел способа сделать это.
Этап автоматического приемочного тестирования просто обновляет существующее приложение на сервере - этап qa полностью выполняет действие остановки, удаления, установки и запуска. Каждый запускает свой скрипт - комбинацию ant & python.
Вот как выглядит конвейер в jenkins с плагином сборки конвейера.
[править]
На самом деле вам не нужно реализовывать каждый этап этого за один раз, довольно просто иметь заполнители для каждого этапа, которые просто переходят на следующий, фактически ничего не делая. Если вы отобразите свой текущий процесс, вы сможете автоматизировать его части и постепенно переходить к конвейеру.
Стадия коммитов - самая легкая для выполнения, это в основном то, что вы делаете при настройке обычного CI-сервера, создании проекта, подключении его к управлению версиями, компиляции, выполнении тестов, запуске какой-либо статистики из ant / maven. задачи. Это займет чуть более 5 минут.
Задача статистики занимает слишком много времени (> 15 минут), поэтому я запускаю подмножество при коммите и выполняю ночной прогон, который выполняет все функции Findbugs, PMD, Checkstyle & Cobertura. Я бы предпочел запустить все это при коммите, но для этого потребовалось бы больше оборудования и работы по настройке какой-либо сетки сборки.
Тесты Selenium на данный момент не находятся в отдельном проекте, но они упакованы как отдельный jar-файл, и это доступно для этапа автоматического приемочного тестирования через плагин jenkins 'copy artifact' - пакет скриптов ant / python файл WAR и развертывание в контейнере, затем ant распаковывает и запускает тесты Selenium (через junit). На данный момент есть только несколько «тестов на дым», и они не зависят от основной WAR, хотя я могу видеть, что это меняется. Мне на самом деле не нравится идея иметь отдельные проекты для кода и тестов - сценарии сборки просто упаковывают классы и библиотеки, необходимые для каждого модуля из основного проекта - для вашей ситуации (и вскоре нашей) вам, возможно, придется что-то сделать разные - как насчет запуска виртуальной машины или двух с нужной вам конфигурацией и ее развертывания. (много информации в книге Непрерывной доставки об этом)
Хорошо, что Jenkins поддерживает многие из них с помощью плагинов - мы перешли с Atlassian Bamboo, потому что большинство того, что мы хотели, не было доступно, и существующие плагины либо не работали, либо не были совместимы с версией Bamboo. Некоторое время я не использовал Team City, поэтому понятия не имею, поддерживает ли он идею «конвейера» [очевидно, нет] . Плагин «Build Pipeline» является довольно новым и имеет несколько грубых краев, но находится в активной разработке - я думаю, что это можно сделать с помощью «продвинутых сборок» Jenkins и «пробных сборок», но я не пытался этого сделать. Если у вас достаточно ресурсов (денег!), Вы можете посмотреть на Go