Рабочий процесс Jenkins CI с отдельной сборкой и автоматическим тестированием как в системе управления версиями

Question

Я пытаюсь улучшить наш процесс непрерывной интеграции, используя Jenkins и нашу систему управления версиями (в настоящее время svn, но git скоро).

Возможно, я думаю об этом слишком сложном, а может быть, я не но видел правильные подсказки. изменения кода для фактического программного обеспечения («основное программное обеспечение»), а также модульные тесты в системе управления версиями (git или что-то еще). Дженкинс должен собрать программное обеспечение, запустить модульные тесты и, возможно, некоторые другие шаги (например, анализ кода stati c). Если ничего из этого не вышло, работа разработчиков сделана. Как часть сборки, номер сборки встроен в само основное программное обеспечение как часть номера версии.

один или несколько инженеров-испытателей впоследствии заберут сборку и проведут тесты. Некоторые из них могут быть ручными, большинство из них желательно автоматизировать / тестировать по сценариям. В конечном итоге они также должны быть переданы в систему контроля версий и выполняться через сервер сборки. Однако это не приведет к запуску новой сборки основного программного обеспечения (поскольку ничего не изменилось). Если ничего из этого не вышло, инженеры-испытатели закончили. Обратите внимание, что наши автоматические тесты в настоящее время занимают несколько часов. В качестве последнего шага менеджер проекта разрешает выпуск программного обеспечения, которое выполняет все необходимые шаги по доставке / развертыванию. Кроме того, исходный код основного программного обеспечения, модульных тестов и сценариев автоматического тестирования, сценарий сборки jenkins - и в идеале все артефакты сборки («двоичные файлы») - заархивированы (помечены) в системе управления версиями.

В идеале разработчики могут также вручную запускать выполнение автоматических тестов, чтобы «предварительно просмотреть» результат своей сборки.

Мне не удалось понять, как это сделать с Jenkins и Git - или любая другая система контроля версий.

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

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

Answer 1

Я постараюсь ответить по некоторым пунктам. Это действительно концептуальный подход, так как здесь много деталей и разных подходов, это только один.

1. Вам нужно git:)

2. Вам необходимо настроить стратегию разветвления git, которая позволит нескольким разработчикам работать одновременно, проталкивая код и проверяя его на основе анализа кода c. Я бы посоветовал вам начать с Git Flow , он широко используется и может быть адаптирован к любой реальности, которая у вас есть - вам не нужно использовать его в чистом виде, поэтому подумайте, как адаптировать его. По сути, это позволит протестировать каждую функцию. Затем каждый разработчик может объединить его в ветке разработки - с этого момента ваши функции проверены, и вы можете начать развертывание и тестирование.

3. Посмотрите на многоотраслевые трубопроводы. Это позволит вам протестировать несколько веток функций, которые могут быть у вас, и иметь разные потоки для других веток - разработка, выпуск и мастер - в зависимости от ваших потребностей в развертывании. Итак, когда у вас есть слияние в ветке разработки, вы можете запустить тестирование или просто использовать его для запуска анализа кода stati c.

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

5. Если у вас все еще есть выполняется ручное тестирование, конвейеры могут быть приостановлены, что означает, что вы можете приостановить конвейер, запросив разрешение на продолжение. Перед утверждением тестировщики должны сделать все, что они должны сделать, и, когда они будут готовы продолжить, просто утвердите сборку, чтобы перейти к следующим шагам.

6. Что касается авторизации развертываний, это сделано так же, как я упоминал в последнем пункте, с утверждениями, но в этом случае вы можете указать, каким пользователям / ролям разрешено утверждать этот шаг.

7. Все, что вам нужно убрать из своих сборок, у Jenkins есть утилита архивных артефактов . Позвольте мне просто отметить, что в идеале вы должны изучить соответствующий репозиторий артефактов, такой как Nexus .

8. Чтобы запустить набор тестов вручную ... У вас может быть запускаемое вручную задание на Jenkins, кроме вашего конвейера CI / CD, которое будет выполнять только автоматические тесты. Вы даже можете запустить это же задание как одну стадию конвейера - как запускать другие задания

Наконец, позвольте мне сказать, что стратегия ветвления является отправной точкой. Подумайте о своей общей картине, какие потоки SDL C вам нужны, и настройте эти потоки на своем многоотраслевом конвейере. Различные ветки git будут поддерживать любые потоки, которые вам нужны, в одном Jenkinsfile - определении вашего конвейера. Это действительно зависит от того, в скольких средах вам нужно выполнить развертывание и какие шаги вам нужны.