Что такое хороший процесс сборки CI

https://stackoverflow.com/questions/102902

01-07-2019
|

Вопрос

Что представляет собой хороший процесс сборки CI?

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

Достаточно ли хорош хороший процесс сборки CI, если он автоматизирован до контроля качества, а затем вручную?

Решение

Смотря как" :)

Мы используем нашу систему CI для:

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

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

Использование инструмента CI для развертывания вашего продукта в производственной среде в качестве реалистичной цели?снова..."это зависит"

Почему вы хотите это сделать?

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

Прежде чем ответить на этот вопрос, вам необходимо решить некоторые технические вопросы:

Каковы требования к бесперебойной работе вашей системы? Разрешены ли вам простои или она должна работать круглосуточно и без выходных?
Есть ли у вас процессы контроля изменений, требующие вмешательства/одобрения человека?
достаточно ли надежно ваше развертывание, чтобы любой компонент мог вернуться в заведомо исправное состояние в случае сбоя развертывания?
предназначена ли ваша система для работы с различными версиями служб или клиентов в случае сбоя развертывания одного или нескольких компонентов (и у вас есть описанный выше откат до последней известной работоспособности)?
достаточно ли у процесса возможностей для частичного развертывания, когда компонент не может обрабатывать смешанные версии своих зависимостей/клиентов?
как вы справляетесь с развертыванием/обновлением базы данных?
есть ли у вас мониторинг, чтобы вы знали, когда что-то пойдет не так?

Вот пара недавних ссылок по теме автоматизация и создание инструментов, которые вам нужны.

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

Теперь вот большой секрет...технические задачи сложны, но не невыполнимы...тот политический трудности могут оказаться непреодолимыми.Все в этом вопросе стоит денег, будь то время на разработку или покупка сторонних решений.Итак, действительно ли вы можете создать решение стоимостью 1000, 10000, 10000 или 1 миллион долларов?

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

Другие советы

CI не предназначен для использования в качестве механизма развертывания.Это является Хорошо, если ваш CI выполняет любое автоматическое развертывание на сервере контроля качества/тестирования, чтобы гарантировать эти аспекты вашей работы по сборке, но я бы не стал использовать систему CI, такую как Cruise Control или Bamboo, в качестве средства развертывания.

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

Убедитесь, что вы понимаете идею сборки CI.CI означает «непрерывная интеграция», а сборки CI на самом деле предназначены для одноразовых сборок, которые выполняются, когда разработчик проверяет код в системе контроля версий (или через определенный интервал), чтобы гарантировать, что новейшие изменения не нарушат базу кода. (отсюда и идея постоянной интеграции изменений в базу кода).

В связи с этим технология, используемая для фактического процесса сборки сервера, в значительной степени не имеет значения по сравнению с тем, что на самом деле происходит во время сборки.Как упоминал @pdavis, сборка CI должна скомпилировать базу кода, выполнить некоторый анализ кода (FxCop, StyleCop, Lint и т. д.), выполнить модульные тесты и покрытие кода, а также выполнить любой другой пользовательский анализ, который вы хотите выполнить, который должен повлиять на концепцию. «успешной» или «неудачной» сборки.

Автоматическое развертывание CI-сборки в среде на самом деле не подпадает под контроль сервера сборки.При этом вы всегда можете создать отдельный проект, который запускается на сервере сборки и который обрабатывает развертывание при обнаружении определенных условий (например, успешного завершения сборки), но это всегда следует делать как совершенно независимую вещь.

Я начинаю новый проект на работе, которого очень жду.Мы все еще находимся на начальной стадии проектирования и совсем недавно завершили разработку логической архитектуры системы.Мы заказали новые серверы для тестовых и промежуточных сред и настраиваем систему сборки непрерывной интеграции (CI) на основе Cruise Control (http://cruisecontrol.sourceforge.net/) и MSBuild (http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx), который по сути является улучшенным портом ANT.Похоже, что все файлы проекта и решения Visual Studio 2005 теперь имеют формат MSBuild.Круиз-контроль автоматически извлечет исходный код из Visual Source Safe (хорошо, это не Subversion, но мы справимся), скомпилируем его, а затем запустим через fxCop (http://www.gotdotnet.com/Team/FxCop/), nUnit (http://www.nunit.org/), nCover (http://ncover.org/site/) и, наконец, сдать в аренду Симиан (http://www.redhillconsulting.com.au/products/simian/).Cruise Control имеет довольно хороший интерфейс веб-сайта для отображения всех скомпилированных результатов с помощью различных инструментов и даже может отображать изменения кода от одной сборки к другой.Он также отслеживает все сборки в истории сборок.Я с нетерпением жду разработки через тестирование и думаю, что этот тип подхода в сочетании с nUnit/nCover должен дать нам довольно хорошее представление, прежде чем мы внедрим изменения, которые мы ничего не сломали.Есть также планы включить некоторый тип автоматизированного тестирования пользовательского интерфейса, когда мы продвинемся в проекте достаточно далеко.В зависимости от инструмента, это должно быть просто установкой инструмента на сервер сборки и вызовом его из Cruise Control.Сладкий.

Хороший процесс CI должен иметь полное или почти полное покрытие модульными тестами.Юнит-тесты тестируют классы и методы, vs.интеграционные тесты, которые тестируют несколько частей системы.Когда вы настраиваете сборки CI, попросите их автоматизировать модульные тесты.Таким образом, сборки CI могут выполняться несколько раз в день.У нас настроен запуск каждые 2 часа.

Вы можете иметь более длительные сборки, которые запускаются один раз в день.Они могут использовать другие сервисы и запускать интеграционные тесты.

Я смотрел презентацию ThoughtWorks (создатели круиз-контроля), и они действительно рассмотрели эту проблему.Их ответ заключается в том, что развертывание NO слишком сложно для тестирования.Почему?Потому что в противном случае ваши клиенты станут вашими тестировщиками, а это именно то, чем вы не хотите быть.

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

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

Чем позже обнаружена ошибка, тем дороже ее исправить.Поэтому ошибки следует обнаруживать как можно раньше.Это мотивация CI.

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

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

Достаточно ли хорош хороший процесс сборки CI, если он автоматизирован до контроля качества, а затем вручную?

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

Эту задачу можно устранить при автоматическом тестировании процесса развертывания в среде, похожей на продукт. Также необходимо протестировать механизм отката после развертывания.

Когда эти функции будут достаточно протестированы, вы обретете уверенность в этом процессе и инструменте, который вы используете.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow