Что составляет хороший процесс сборки CI?
Мы используем CI, но это развертывание для производства даже реалистичной цели CI, когда у вас есть зависимости от нескольких служб, которые также должны быть развернуты, и другие приложения также могут зависеть от них.
Достаточно ли хорош хороший процесс сборки CI, если он автоматизирован до QA и оттуда выполняется вручную?
Смотря как" :)
Мы используем нашу систему CI для:
Это новый проект, включающий около десятка служб и баз данных, развернутых на более чем 20 серверах, которые также зависят от полдюжины других «внешних» служб.
Использование инструмента непрерывной интеграции для развертывания продукта в производственной среде в качестве реальной цели? снова ... "это зависит от обстоятельств"
Зачем тебе это нужно?
Прежде чем ответить на этот вопрос, необходимо решить некоторые технические вопросы:
Вот несколько недавних ссылок по теме автоматизация и создание необходимых вам инструментов.
Когда дело доходит до того, что чем сложнее ваша система, тем сложнее все автоматизировать, но это не значит, что это не достойная цель, просто требуется гораздо больше усилий и силы воли, чтобы ее выполнить - все от знания трудности, с которыми вы столкнетесь, проблемы, которые вы должны учитывать (отказ будет случиться), политические проблемы построения инфраструктуры (по сравнению с большим количеством функций продукта).
Вот большой секрет ... технические проблемы сложны, но не невозможны ... политические проблемы могут оказаться непреодолимыми. Все, что связано с этим, стоит денег, будь то время разработки или покупка сторонних решений. Итак, действительно ли вы можете создать решение за 1 000, 10 000, 100 000 или 1 миллион долларов?
Какое бы решение вы ни выбрали, сначала убедитесь, что автоматизация является надежной, а затем завершенной ... т.е. убедитесь, что у вас есть максимально надежное решение для развертывания в тестовой среде, а не хрупкое решение, развертываемое в производственной среде.
CI не предназначен для использования в качестве механизма развертывания. хорошо, если ваш CI выполняет любое автоматическое развертывание на сервере QA / Test, чтобы гарантировать эти аспекты вашей работы по сборке, но я бы не стал использовать систему CI, такую как круиз-контроль или Bamboo, в качестве средства развертывания.
CI предназначен для периодического создания базы кода для автоматизации выполнения автоматических тестов, проверки базы кода с помощью статического анализа и других проверок подобного рода.
Убедитесь, что вы понимаете идею построения CI. CI означает непрерывную интеграцию, а сборки CI действительно предназначены для одноразовых сборок, которые выполняются, когда разработчик проверяет код в системе управления версиями (или через некоторый указанный интервал), чтобы гарантировать, что новейшие изменения не нарушают базу кода. (отсюда и идея непрерывной интеграции изменений в кодовую базу).
С этой целью технология, используемая для фактического процесса сборки сервера, в значительной степени не имеет значения по сравнению с тем, что на самом деле происходит во время сборки. Как упоминалось в @pdavis, сборка CI должна компилировать базу кода, выполнять некоторый анализ кода (FxCop, StyleCop, Lint и т. Д.), Выполнять модульные тесты и покрытие кода, а также выполнять любой другой настраиваемый анализ, который вы хотите выполнить, который должен повлиять на концепцию "успешной" или "неудачной" сборки.
Автоматическое развертывание сборки CI в среде действительно не подпадает под контроль сервера сборки. При этом вы всегда можете создать отдельный проект, который запускается на сервере сборки, который обрабатывает развертывание при обнаружении определенных условий (например, успешное завершение сборки), но это всегда должно выполняться как полностью независимая вещь.
Я начинаю новый проект на работе, которого очень жду. Мы все еще находимся на начальной стадии проектирования и совсем недавно завершили архитектуру логической системы. Мы заказали новые серверы для тестовых и промежуточных сред и настраиваем систему сборки с непрерывной интеграцией (CI) на основе круиз-контроля (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/). Круиз-контроль имеет довольно хороший интерфейс веб-сайта для отображения всех скомпилированных результатов различных инструментов и даже может отображать изменения кода от одной сборки к другой. Он также отслеживает все сборки в истории сборок. Я с нетерпением жду разработки, основанной на тестировании, и думаю, что этот тип подхода в сочетании с nUnit / nCover должен дать нам довольно хорошее представление, прежде чем мы будем внедрять изменения, которые мы ничего не сломали. Также есть планы по внедрению некоторого типа автоматизированного тестирования пользовательского интерфейса, когда мы достаточно продвинемся в проекте. В зависимости от инструмента, это должно быть просто установкой инструмента на сервере сборки и его вызовом из круиз-контроля. Сладкий.
Хороший процесс CI будет иметь полное или почти полное покрытие модульного тестирования. Модульные тесты тестовые классы и методы по сравнению с интеграционными тестами, которые тестируют несколько частей системы. Когда вы настраиваете свои сборки CI, пусть они автоматизируют модульные тесты. Таким образом, сборки CI могут запускаться несколько раз в день. Наш настроен на запуск каждые 2 часа.
У вас могут быть более продолжительные сборки, которые запускаются один раз в день. Они могут использовать другие службы и запускать интеграционные тесты.
Я смотрел презентацию ThoughtWorks (создателей круиз-контроля), и они действительно решили эту проблему. Их ответ заключается в том, что НИКАКОЕ развертывание не является слишком сложным для тестирования. Почему? Потому что в противном случае ваши клиенты станут вашими тестировщиками, а вы именно этого не хотите.
Если у вас сложная структура развертывания, настройте сервер визуализации. Сделайте вид, что это все системы, с которыми вам нужно поговорить. Они всегда могут запуститься в заведомо исправном состоянии, потому что вы можете выполнить сброс до чистого образа.
Чтобы ответить на ваш первоначальный вопрос, хороший процесс - это тот, который обеспечивает связь между репозиторием и разработчиками. Если репозиторий находится в плохом состоянии (некомпилированный код, неудачные тесты и т. Д.), Разработчики узнают об этом как можно скорее, чтобы они могли исправить это.
Чем позже обнаруживается ошибка, тем дороже ее исправление. Так что ошибки следует обнаруживать как можно раньше. Это мотивация CI.
Хороший CI должен гарантировать отлов как можно больше ошибок. Все приложение состоит из кода (часто на нескольких языках), схемы базы данных, файлов развертывания и т. Д. Ошибки в любом из них могут вызвать ошибки, поэтому CI должен попытаться использовать как можно больше из них.
CI не заменяет надлежащую дисциплину QA. Кроме того, в первый день проекта CI не обязательно должен быть всеобъемлющим. Можно начать с простого процесса CI, который изначально выполняет базовую компиляцию и модульное тестирование. По мере того, как вы обнаруживаете больше классов ошибок в QA, вам следует адаптировать процесс CI, чтобы попытаться отловить будущие появления этих ошибок. Он также может включать проверки статического анализа кода, чтобы вы могли реализовать согласованные идеалы кодирования и проектирования во всей кодовой базе.
