Лучшая практика для непрерывной интеграции и развертывания

Концепция непрерывной интеграции только что была интегрирована в мою команду.

Предположим, что мы имеем ветвь интеграции с именем Dev.

Из него получены 3 ветки, по одному для каждого конкретного текущего проекта:

Проект A
Проект B
Проект C

Во-первых, Teamcity настроен на выделенном сервере, и его цели:

Скомпилирует и запускает тесты модулей и интеграции из версий с версией из каждой ветки, включая Dev

Затем, конечно, каждая ветвь проекта (A, B и C) должна быть протестирована в клонированной производственной среде, чтобы UAT можно было выполнить.

Но мне интересно, на какой частоте мы должны развертываться? Каждый раз, когда изменяется исходный код?

Должны ли мы развертывать только Dev, который содержит смесь из трех проектов после слияния каждого из них с ним (что соответствует реальности в следующей производственной версии) или 3 проекта независимо?

Если Dev развернут, потенциально будущие изменения в Dev не должны приниматься во внимание. В самом деле, может возникнуть новый проект, начинающийся с Project D, который не должен быть частью следующей версии. Поэтому принятие Dev для интеграции (UAT) сопряжено с риском, потому что разработчик может недобровольно интегрировать контент Project D, и поэтому среда не будет раскрывать реальность следующего выпуска.

Другое решение: мы не принимаем Dev, но независимо от трех проектов, так что параллельно должна быть 3 клонированных производственных среды?

Если да, UAT не может быть надежным, так как поведение среды интеграции может меняться очень часто...

Концепция непрерывного развертывания для UAT для меня непонятна...

Ответ 1

О, мальчик. Вы сталкиваетесь с проблемами CD в реальном мире. Действительно хорошие вопросы.

Ответ немного зависит от очень тесно связанных разработок по различным проектам.

В моей идеальной ситуации для вас было бы иметь несколько "особых" условий тестирования. В одном случае вы можете рассмотреть тестовую среду для каждого проекта. Когда будет завершена сборка проекта A, вы подталкиваете ее в среду A, которая имеет последние одобренные/производственные версии для B/C, и вы можете проводить там базовые интеграционные тесты. Если они пройдут, вы продвигаете сборку в среду тестирования интеграции, где последняя хорошая A, развертывается по последним B и C для той же версии. Когда тестовая среда интеграции проходит тесты, вы можете продвигать ее содержимое в виде набора релизов, содержащего известные версии A, B и C. Этот набор релизов будет развернут в любых средах UAT, Staging или Production.

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

На самом деле это тема, о которой я рассказываю довольно много. Если вы не возражаете, я приведу несколько презентаций, которые я рассказывал по этим темам.

1) Масштабирование CI для параллельной разработки (совместно с Крисом Луккой из Accurev)

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

2) Использование uDeploy с Jenkins (требуется регистрация)

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

3) Слайды, визуализирующие многокомпонентный конвейер:

http://www.slideshare.net/Urbancode/adapting-deployment-pipelines-for-complex-applications