Как работает ваша непрерывная интеграция?

Question

Я создаю CI-сервер и буду очень признателен за реальный опыт и обзор того, что используют люди.

Итак, каковы ваши процессы сборки? Есть ли что-то вроде:

• один час для кода и тестов,
• еще один день для построения MSI и метрик кода,
• и др.,

а также, что использует ваш полный процесс сборки? Используете ли вы что-то вроде:

• командный город,
• MSBuild
• nunit - для тестов,
• ncover - для тестового покрытия,
• ndepend - для метрик кода,
• sandcastle - для документирования кода комментариями,
• testcomplete - для тестов QA,
• и др.?

Доля! ;)

Answer 1

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

Оригинальные заметки конференции здесь . Наряду с фотопотоком Flickr . * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Стр. 9

Австралийцы вновь обратились к теме в CITCON Brisbane и pencast , который доступен

Надеюсь, некоторые из этих ресурсов полезны.

Answer 2

Процессы сборки - у нас есть 4 в настоящее время активных ветви большой базы кода, для которых мы постоянно выполняем сборки. Для каждой ветви у нас есть сборки, разбитые на два этапа:

• Сборка Quick Continuous Integration, которая запускается после каждой фиксации, чтобы мы могли как можно быстрее получать отзывы о сломанном коде или сломанных тестах
• Полная автоматизированная сборка, которая выполняется дважды в день, что гарантирует, что код будет создаваться с нуля, начиная с конца и до конца.

Наш процесс сборки координируется Zed Builds And Bugs и включает Ant, Make, Maven, JUnit, Findbugs, сценарии оболочки (исторические) для Windows, Linux, AIX, HP и Solaris.

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

Answer 3

Мы используем CruiseControl.net в качестве нашего CI-сервера в сочетании с NANT. Большинство сборок (у нас около 30 сборок) запускаются при изменениях. Некоторые менее важные тяжелые сборки запускаются только один раз каждую ночь, это также относится и к поддерживающим сборкам, которые очищают большинство обычных сборок.

Для наших сборок кода на C / C ++ мы используем запатентованную систему сборки, которая способна распространять сборки кода на каждую машину, имеющуюся в компании (например, IncrediBuild, но гораздо более гибкую). Для наших сборок C # мы напрямую называем devenv.com, но мы используем NUnit для запуска модульных тестов. Наши модульные тесты C ++ используют нашу собственную платформу, результаты которой в xml очень похожи на NUnit. Для некоторых дополнительных проверок кода мы запускаем pclint каждую ночь. На данный момент покрытие кода пока не выполнено, что немного обидно.

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

Answer 4

В моем предыдущем проекте у нас было два luntbuild сервера плюс сервер SVN.

Первая машина luntbuild использовалась для сборки проекта - инкрементная сборка + модульные тесты для каждого коммита, а затем чистая сборка + модульные тесты + полная установка пакета в течение ночи.

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

Answer 5

Для Java у нас есть экземпляр Hudson , проверяющий коммиты в репозитории SVN , для каждого коммита есть сборка, в которой все компилируется и все тестовые модули запустить с помощью Maven2 . Также Hudson связан с экземпляром Sonar , который сообщает нам статистику о стиле кодирования и охвате тестирования.

Снимок экрана сонара http://nemo.sonarsource.org/charts/trends/60175?sids=1024412,1025601,1026859,1073764,1348107,2255284&metrics=complexity,mandatory%5Fviolations%5Fdensity,lines,coverage&format=png&ts=1244661473034

Сладкий:)

Answer 6

CI из Instagram работает следующим образом:

В Instagram мы используем наш бэкэнд-код 30-50 раз в день ... всякий раз, когда инженеры вносят изменения в мастер-версию, в большинстве случаев без участия человека. Это может звучать безумно, особенно в наших масштабах, но это работает очень хорошо. В этом посте рассказывается о том, как мы внедрили эту систему и добились ее бесперебойной работы ...

Answer 7

Jenkin - лучший инструмент для непрерывной интеграции (CI). CI - это не что иное, как частая интеграция кода в вашем хранилище (SCM). Далее, интеграция SCM в jenkins для построения вашего кода.

Вы можете установить частоту опроса в jenkins. так что всякий раз, когда изменения вносятся и фиксируются в SCM, Jenkins будет пытаться сделать сборку. Этот способ работает .. непрерывная интеграция.

Answer 8

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

Каждый экземпляр CB отвечает на запрос CB, выполняя шаги по сборке и тестированию, которые он настроил (обрабатывая их параллельно «облаку» распределенных серверов, совместно используемых всеми экземплярами CB), регистрируя результаты сборки и тестирования, и иногда (не чаще, чем настроенная частота) запускает "тяжелые тесты" (которые могут выполняться ОЧЕНЬ долго и НЕ будут блокировать входящие запросы CB - тяжелые тесты полностью отменяются, хотя журналы очень четко дают понять против в какую сборку они бежали).

"sync to head" (что "head" будет "trunk" в других VCS ;-), поскольку зависимости, которые не являются частью дерева, отслеживаемого CB, могут происходить каждый раз (они будут легкими, не -производственные или экспериментальные сборки), или только по очень явным запросам интеграции (это другая крайность, для "веток релиза" для сборок / проектов, критичных к производству), или с промежуточным допуском.

Я думаю, что это не вершина практики разработки релизов, но в своем наборе вариантов она хорошо работает для нас, для действительно широкого спектра проектов с очень различной критичностью, степенью зависимости и т. Д.).