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

Question

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

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

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

Answer 1

Ну, "это зависит":)

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

1. сборка и юнит тест
2. развертывание в одном компьютере, запуск интеграционных тестов и анализ кода
3. развертывание в лабораторной среде
4. запустить приемочные испытания в подобной системе
5. отбрасывание сборок, которые переходят на отбрасывание кода для развертывания prod

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

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

Зачем вам это нужно?

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

Некоторые технические вопросы, с которыми вы должны ответить, прежде чем ответить на них:

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

Я начинаю новый проект на работе, который я действительно с нетерпением жду. Мы все еще на начальной стадии проектирования и совсем недавно завершили разработку архитектуры логической системы. Мы заказали новые серверы для тестирования и промежуточных сред и настраиваем систему сборки Continuous Integration (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/),) и, наконец, не арендовать Simian (http://www.redhillconsulting.com.au/products/simian/). Cruise Control имеет довольно хороший интерфейс веб-сайта для отображения все скомпилированные результаты различных инструментов и могут даже отображать изменения кода от одной сборки к другой. Он также отслеживает все сборки в истории сборки. Я с нетерпением жду разработки, управляемой тестами, и думаю, что этот тип подход в сочетании с nUnit / nCover должен дать нам довольно хорошую идею, прежде чем мы пойдем но изменения, которые мы ничего не сломали. Есть также планы включить некоторый тип автоматического тестирования пользовательского интерфейса, как только мы продвинемся достаточно в проекте. В зависимости от инструмента, это просто вопрос установки инструмента на сервер сборки и вызова его из Cruise Control. Сладкое.

Answer 6

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

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

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

Answer 7

Я смотрел презентацию ThoughtWorks (создателей круиз-контроля), и они фактически решили эту проблему. Их ответ заключается в том, что НИКАКОЕ развертывание не является слишком сложным для тестирования. Зачем? Потому что в противном случае ваши клиенты станут вашими тестерами, и это именно то, чего вы не хотите.

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

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

Answer 8

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

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

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

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