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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 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