Непрерывные конфигурации сборки интеграции

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

Исходные заметки конференции здесь . Вместе с фотопотоком Flickr . Очищенная версия также доступна в блоге urbancode.

Австралийцы вновь обратились к этой теме на CITCON в Брисбене, и доступна версия этой темы.

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

У нас есть конфигурации сборки для

• компиляции + модульных тестов + статического анализа (в нашем случае - поиск ошибок) + покрытия кода (запускается при фиксации)
• интеграционных тестов (запускается по расписанию как пока есть фиксация)
• развертывание для тестирования (запускается вручную)

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

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

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

Я работаю над этим в данный момент. Наша конфигурация сборки выполняет следующие функции:

Сборка:

• Компиляция.
• Тест.
• Объединение различных значений конфигурации, специфичных для среды, с базовой конфигурацией (остается Staging.config, Test.config и т. Д.)
• Создайте файл с именем VERSION.txt, в котором перечислены времена сборки, номера ревизий и т. Д.
• Опубликуйте все это в чистый каталог. Затем teamcity воспринимает это как артефакт сборки.

Теперь у нас есть приложение, которое можно опубликовать на любом сервере, просто скопировав его в каталог развертывания и переименовав соответствующий файл конфигурации в web.config

. затем подготовьте еще 3 конфигурации для развертывания. Первый развертывается в среде разработки после каждой успешной сборки. Это всегда дает нам рабочую версию последней кодовой базы. Второй запускается на постановку вручную. Он настроен на развертывание из последней закрепленной сборки разработки. Наконец, существует конфигурация динамического развертывания, которая затем развертывается из последней развернутой промежуточной сборки. Это делает ряд дополнительных вещей:

• Отметьте выпущенную версию
• Создайте ее архив и поместите в каталог для сохранения.
• Просмотрите все комментарии к отметке с момента последней сборки в реальном времени и извлеките их с помощью тикета числа. Затем используйте названия билетов для создания предварительного списка изменений. Это редактируется PM перед сохранением для потомков.

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

Первая группа, работающая над источниками:

• чистый рабочий каталог
• обновление до новейших источников, получение всего из SVN
• источников компиляции, rmic и т. Д.
• оценка ресурсов XML (как по крайней мере, в Java их было много, например дескрипторы развертывания, таблицы стилей и т. д.)
• выполняет статический анализ кода, доступный для источников, например, проверка пробелов, присвоение имен кодов, имена файлов или более сложные проверки, выполняемые в AST источника (например, PMD делает это для Java).
• проверьте соглашения об именах других файлов, например мы проверили имена всех зависимых библиотек, чтобы они содержали номер версии.

Вторая группа работает над созданным кодом, только если первый шаг был успешным:

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

Это основная сборка, которая запускается время от времени для коммитов. Это было сделано очень много, но с некоторыми мощными машинами, использующими несколько ядер, это было около 4 минут для 500k LOC. Тестировщики могут получить новейшие сборки моментальных снимков, если захотят.

Длительные интеграционные тесты (по 2 часа каждый) запускались один раз за ночь и выполняли только

• компиляцию
• запускали длительные тесты

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

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