Как подойти к КИ - PullRequest
       62

Как подойти к КИ

6 голосов
/ 05 декабря 2011

Я нахожусь в процессе создания компании с нуля (Tomcat + Spring Rest + Java), поэтому у нас есть роскошь делать некоторые вещи правильно (или в списке, не повторяя наших прошлых ошибок), одна из целей, которые мы хотим достичь - это возможность автоматически создавать, тестировать (объединять, интегрировать) и развертывать.

Наша платформа построена на одном статическом сайте с интерфейсом HTML / JS, который обслуживается NGiNX, и несколькими API-серверами (различными приложениями), некоторые из них доступны, а некоторые доступны из фермы только доступным приложениям API.

Я выбрал TeamCity в качестве CI-сервера, так как я немного знаком с ним, и у меня до сих пор был отличный опыт со всеми продуктами Jetbrain.

На данный момент я определил две конфигурации сборки

  1. Разумность разработки: проверяет из git, запускает сценарии БД для подготовки базы данных, выполняет maven цели чистой установки (поэтому выполняется наш комплект testng), выполняет покрытие кода и статический анализ кода Эта конфигурация выполняется и отлично работает.

  2. Интеграция: Проверяет из git, запускает сценарии БД для подготовки базы данных, выполняет maven цели чистой установки (поэтому выполняется наш набор тестов)

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

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

Кстати - развертывание на AWS

Спасибо, ребята.

1 Ответ

4 голосов
/ 05 декабря 2011

Во-первых, я настоятельно рекомендую вам прочитать «Непрерывная доставка» (Джез Хамбл, Дэвид Фарли), там есть много информации по этому вопросу. Здесь есть пример главы .

С тех пор, как я прочитал это, я начал реализовывать конвейер сборки, где каждый коммит svn проходит через каждый этап конвейера, а среда постепенно становится похожей на производство по мере продвижения сборки. Мы используем Дженкинс для этого.

  1. Стадия коммита - dev sanity - компилировать, модульный тест и некоторые метрики. это На начальном этапе также создаются двоичные файлы, необходимые для остальной части трубопровод
  2. Этап интеграции - это те же файлы, что и предыдущий этап (не новая проверка) и запускает интеграционные тесты БД в память
  3. Этап автоматического приемочного испытания - принимает двоичные файлы из этап фиксации и развертывание на сервере, где мы запускаем тесты на селен
  4. Стадия QA - она ​​используется qa, который просто нажимает кнопку, чтобы потянуть независимо от того, какую сборку они хотят, она просто развертывает двоичные файлы от этапа фиксации к серверу QA
  5. UAT - то же самое, что QA, но более производительная среда, где мы также проводим тесты производительности
  6. Производство - переводит двоичные файлы из этапа фиксации и развертывает их в производство.

Каждый из этих этапов выступает в качестве «шлюза качества» - сборка не может продолжаться до тех пор, пока не пройдет некоторый порог - сбои тестирования, показатель% 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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...