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

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

Снимок экрана Sonar http://nemo.sonarsource.org/charts/trends/60175?sids= 1024412,1025601,1026859,1073764,1348107,2255284 & metrics = сложной, обязательной% 5Fviolations% 5Fde density, lines, охват & формат = png & ts = 1244661473034

Sweet:)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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