Continuous Integration. Разработка программного обеспечения,

Идеологически CI базируется на следующих соглашениях
часто (не менее 1 раза в день) «заливать» свой код в репозиторий
писать автоматические тесты
запускать private builds (процесс сборки, который выполняется с использованием исходного кода, в данный момент находящегося в локальном репозитории разработчика)
не «заливать» неработающий код
чинить сломанный build немедленно
следить за тем, чтобы все тесты и проверки проходили
не выкачивать из репозитория сломанный код

Continuous Integration

Continuous Integration
Базовый процесс интеграции выглядит следующим образом:
Триггер. Событие, при котором запускается сборка продукта. Таким событием может быть: изменения в коде (push), определенное время, нажатие на кнопку.
После срабатывания триггера стартует сборка проекта из исходников.
Развертывание базы данных.
Развертывание приложения.
Тесты. Авто-тесты не являются обязательными, но их выполнение крайне желательно. Это один из важных пунктов хороших практик CI.
Статус, отчеты, уведомления по результатам сборки. После прогона тестов получаем результат сборки, детальные отчеты по каждому из этапов интеграции

Build script
Скрипт сборки — это набор команд, которые будут выполнены при запуске процесса интеграции. Чаще всего он выглядит как следующий набор шагов:
Очистка от результатов предыдущего запуска
Компиляция (или статический анализ кода для интерпретируемых языков)
Интеграция с базой данных
Запуск автоматических тестов
Запуск других проверок (соответствие код стандартам, проверка цикломатической сложности и т. д.)
Разворачивание программного обеспечения

Автоматические тесты в CI
В CI используются тесты всех уровней за исключением исследовательских:
модульные (unit) тесты
компонентные тесты
функциональные тесты
системные тесты
По написанию и запуску тестов также принят ряд соглашений:
более быстрые тесты должны запускаться первыми
тесты должны быть разделены по категориям
на все баги должны писаться тесты
тест кейсы стоит ограничивать одной проверкой
тесты должны выполняться без ошибок при повторном запуске

Преимущества CI
Прежде всего, это регулярная интеграция всего приложения.
Все делается автоматически, люди избавлены от рутины.
Экономия времени.
Работа над проектом прозрачна для всех участников команды. Становится проще ответить на вопросы что? где? когда?
Уменьшаются риски получить «гранату». Дефекты находятся раньше. Это достигается путем запуска тестов и ранней отдачи нового/измененного функционала на тестирование.
У нас есть всегда развернутое окружение для тестирования и демонстрации работы заказчику и прочим заинтересованным. Если ваша команда большая, и вы работаете одновременно в разных ветках репозитория. То теперь буквально в несколько движений вы можете настроить ветку кода на нужное окружение или собрать новое с нужной веткой.
Можно безболезненно эмитировать процесс деплоя на тестовых серверах.
Хорошая CI система позволяет поддерживать ряд инженерных практик (анализ кода, покрытие кода, юнит-тесты).

Узкие места CI
В любом инструменте существует ряд нюансов. Чтобы эффект от использования непрерывной интеграции был наибольшим рекомендуется использовать ряд общепринятых практик.
Частая синхронизация. В этом заключается основной смысл CI. Нельзя позволять разработчикам длительное время не интегрировать изменения. Хорошей практикой является создание отдельных веток кода и окружений для длительных фич и рефакторинга.
Решать все проблемы со сборкой максимально быстро. Это позволит избежать простоев. Настройте автоматические нотификации в случае упавшего билда. Это позволит разработчикам своевременно знать о проблемах. Не экономьте на железе. Сервер должен быть мощный.
Должным образом настройте инфраструктуру. Процесс сборки должен быть надежным.
Процесс сборки должен быть быстрым, не более 10 минут. Поэтому имеет смысл оптимизировать все шаги сборки. Во время сборки выполняйте только необходимые действия, ничего лишнего. Приемочные тесты не должны занимать много времени, т.к. любые простои не желательны. Пишите и прикручивайте к сборке авто-тесты. Тогда интеграция будет наиболее безопасной.
CI будет эффективен только тогда, когда вся команды его принимает.
Расширяйте возможности (анализ покрытия, статические анализаторы, статистика тестов).
Максимально адаптируйте окружение под production-версию.

Создание проекта в Jenkins

Создание проекта в TeamCity

Создаем новый проект

Создание «build configuration» (конфигурации сборки)

Добавление нового репозитория

Добавление нового репозитория

Добавление нового репозитория
Authentication method –способ аутентификации. Тут может быть и доступ без авторизации (если данные лежат на внутреннем сервере, например), и по ключу, и по паролю. Для каждого варианта дополнительные поля будут свои

Настройка автоматического запуска задания

Создание шагов сборки

Создание шагов сборки

Компиляция проекта

Добавление параметров сборки

Общий вид прошедших сборок