Что такое непрерывная интеграция

Continuous Integration для самых маленьких

Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.

Работа с VCS

Для начала нам потребуется тестовое окружение для тестирования приложения. Если цикл тестирования достаточно длительный, а разработка ведется быстро, то разумно выделить еще и dev-окружение. Структура VCS будет отражать ваши окружения.
Все разработчики работают с основной веткой разработки, затем определенная версия фиксируется и мержится в тестовую ветку. Из тестовой ветки происходит выкладка на тестовое окружение. Производится тестирование, внесение фиксов и обратный мерж в дев. Протестированная версия отправляется в релизную ветку и от туда публикуется на продакшн. В случае нахождения ляпов на продакшне (к сожалению, такое бывает) чиним в авральном режиме из продакшн ветки и опять мержим в DEV-ветку.

В философии GIT будет немного иначе, так как при работе с GIT не принято комитить в master и даже dev. Вместо этого практикуется подход фича-бренч. Про git workflow можно почитать здесь: habrahabr.ru/post/60030. Вообще, все предлагаемые структуры VCS преследуют одну цель: избежать ситуации, когда ветка разработки не стабильна, а совершенно необходимо что-то быстро «пофиксить» или «допилить» и выложиться. При выборе своей структуры задайте себе вопрос «смогу ли я выложиться на продакшн в течение одного дня и не поломать все. Если ответ «да», то структура вам подходит.

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

Конфигурации

Начинающие разработчики часто впадают в ступор при отладке трансформаций Web.config’а на локальных машинах: в отличие от App.config’ов они хранятся на уровне приложения, а не в папке bin, поэтому при локальной сборке трансформации не происходит. Трансформации применяются при публикации проекта. Если вам действительно нужно обойти это ограничение, можно создать файл Web.template.config и добавить трансформацию на PostBuild приложения. Не забудьте только убрать таск трансформации из проекта, иначе трансформация будет применяться дважды.
Если в приложении используют другие технологии, все-равно лучше иметь один основной конфигурационный файл с общими настройками и дополнительные конфигурационные файлы для изменения эталонного конфига. Это избавит вас от копипаста одинаковых настроек.

Добавление файлов, отсутствующих в проекте к выкладке

Версионирование продукта

Основные подходы

Все современные CI-решения предлагают такую переменную во время сборки. Для того, чтобы этот подход работал, нужно добавить импортировать msbuild-таски из msbuildtasks.tigris.org и добавить в конце проекта:

Версионирование базы данных

SSDT-проект msdn.microsoft.com/ru-ru/data/tools.aspx

Плюсы: процесс создания и редактирования БД напоминает то, как бы вы это делали с Management Studio.
Минусы: сложность написания миграционных скриптов. Т.к. инкрементальные изменения строит сам проект, сохранность данных обеспечивается за счет pre-deploy и post-deploy-скриптов. Придется опираться на наличие/отсутствие полей в БД или «изобретать» таблицу schema version, уже реализованную в миграционных движках.

ECM7 Migrator code.google.com/p/ecm7migrator

Движок миграций с открытым кодом. Проект поддерживает хабраюзер dima117.
Плюсы: поддерживаются разные СУБД, если что-то вас не устраивает, код открыт. Мигратор поддерживается и обрастает новыми функциями. И, пожалуй, самое важное, поддерживает несколько ключей миграций в одной базе данных. Это может быть очень полезно, если ваше приложение модульное и поддерживает плагины в том или ином виде. Каждый плагин может выполнять свои миграции и при этом использовать одну БД
Минусы: нет плюшек Entity Framework Migrations.

Entity Framework Migrations blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

Автоматизация публикации приложения

В 2012 студии система публикации web-проектов была значительно улучшена. В первую очередь это касается профилей публикации. Если вы публикуете приложение в azure, то профиль можно просто скачать с портала. В противном случае его нужно будет создать.

Как видно на скриншотах, в последней версии WebDeploy можно запустить EF-миграции с помощью всего одной галочки. Кроме этого публикация из студии умеет заменять строку подключения без использования трансформации.
Подробно про трансформации и публикации написано у Троя Ханта в статье: www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html. Сейчас нас интересует пятый шаг его гайдлайна, а именно, автоматическая публикация с помощью билд-сервера: www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html. Я большой фанат TeamCity, поэтому рассмотрим именно эту CI.

Автоматизация публикации Windows-служб

Для автоматического создания windows-служб проще всего воспользоваться командной sc:

TeamCity

Использование средств, описанных выше, сэкономит ваше время. Пойдем дальше и установим билд-сервер. Скачиваем TeamCity: www.jetbrains.com/teamcity и запускаем инсталятор, жмем везде «Ок».
Два основных понятия TeamCity – «проект» и «билд». «Проект» соответствует вашему солюшну, а под билдом понимается любая осмысленная совокупность действий над вашим проектом: будь то сборка, запуск тестов, выкладка на сервер, создание бекапов и так далее.

Автоматизированная выкладка

Первым шагом, дадим возможность выкладывать новую версию тему у кого Visual Studio не устновлена.
Основная идея, это запустить msbuild-шаг с дополнительными параметрами, создайте новый Build Definition и выберите первый шаг Msbuild. В параметры командной строки нужно передать:

Эти параметры укажут, куда нужно публиковать.
Для того, чтобы опубликовать миграции потребуется дополнительный шаг Command Line:

Сохраняете билд. Теперь кто угодно может опубликовать последнюю версию из VCS. Хорошая практика публиковаться на дев-стенд каждый день до начала рабочего дня. Таким образом вы будете отлавливать интеграционные проблемы максимально быстро.

Rolling builds

Еще одна хорошая практика – настроить триггер на запук билда, который просто будет запускать сборку вашего солюшна после каждого изменения в репо или по таймеру (например, каждые 10 минут), если над проектом работает одновременно очень много разработчиков. К этому билду следует подключить нотификацию. TeamCity поддерживает нотификации по почте, jabber, с помощью плагина для VisualStudio и Tray-приложения. Выберите вариант по вкусу. Мне по душе приложение в трее. Если билд сломался – надо срочно чинить.

Как не ломать билд

Какие бы практики вы не вводили, чтобы не делали, не существует никакого способа дать 100% гарантию, что разработчики не будут вносить в VCS код, который даже не собирается. Этот вопрос должен решаться с помощью административных мер: не уходить с работы, не проверив, что билд после твоих изменений собрался, кто сломал, тот и чинит. В одной компании, где я работал проблема со слишком часто сломанным билдом была решена правилом: сломал билд – принеси тортик. Сначала торты ели каждый день, потом перестали.

Автоматический запуск тестов

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

Запуск юнит-тестов

Запуск интеграционных и приемочных тестов

Эти тесты могут зависеть от многих факторов и их запуск может предполагать накатывание бекапов или скриптов инициализации. Возможно, что вы захотите построить дополнительные отчеты о запуске таких тестов. Лучше не захламлять ваш проект с выкладкой и создать для них специальный билд. TeamCity позволяет создавать цепочки билдов. В Build triggers билда с приемочными/интеграционными тестами вы можете добавить триггер, срабатывающий при удачном прохождении билда с выкладкой. Создание такого билда для запуска приемочных тестов я описал в топике: habrahabr.ru/post/182032.

Бекапы

Создание бекапов при выкладке также может быть автоматизировано. Для бекапа файловой системы, лично я не нашел ничего лучше, чем nnbackup: www.nncron.ru/index_ru.shtml.

Команда создает аривирует в zip папку source и копирует архив в destination. Устанавливать nnbackup на целевые машины или вызывать с билд-сервера: вопрос ваших предпочтений, расположения билд сервера, сетевых издержек и безопасности.

Бекапить sql-сервер можно с помощью T-SQL

Т.е. для автоматического бекапа, вам потребуется добавить еще один Command Line-шаг. Или вы можете воспользоваться msbuild-тасками из того-же самого community-пакета, а для nnbackup написать свой msbuild-таск.
Можно пойти дальше и поставить триггер на запуск автоматического отката из бекапа, если приемочные тесты не прошли. Тогда у вас будет цепочка билдов: Выкладка » Приемочные тесты » Откат из бекапа.

Интеграция с системой ведение проекта и баг-трекером

До этого момента, мы уже сделали много полезного. Осталась одна неприятная особенность. Билд-сервер все-еще никак не связан с нашим процессом разработки. Он ничего не знает о задачах текущей итерации разработки.
TeamCity поддерживает интеграцию с YouTrack, Jira и Bugzilla. Интеграция выполняется буквально в 2 клика. После этого, указывая номер задачи в комментарии к комиту, вы увидите ссылки на соответствующие задачи в информации о билде.
YouTrack поддерживает обратную интеграцию. Основное преимущество: YouTrack будет автоматически указывать номер билда, в котором баг или фича были закрыты.

Артефакты билда

Если ваше приложение коробочное, то вам, наверняка нужно озаботиться созданием инсталляторов или deploy packages для отгрузки клиентам. Создание инсталляторов – отдельная тема, я не буду ее рассматривать в рамках этого топика. Важно, что для коробочного продукта, инсталлятор или пакет публикации – это самая важная часть релиза. Как раз для этого и придуманы артефакты билда.

Артефакт – это любой файл, являющийся значимым результатом выполнения билда. Для билдов с инсталляторами вы можете указать my-installer.exe или my-package.zip, как маску для артефактов билда и TeamCity отобразит их в соответствующей вкладке.
Вот здесь и пригодится интеграция с Issue Tracker’ом. Тестировщик или менеджер может посмотреть закрытую задачу, перейти по ссылке с билдом и забрать версию с исправлениями из артефактов билда.

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

Источник

Что такое CI/CD? Разбираемся с непрерывной интеграцией и непрерывной поставкой

В преддверии старта курса «CI/CD на AWS, Azure и Gitlab» подготовили для вас перевод полезного материала.

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.

CI/CD — это одна из DevOps-практик. Она также относится и к agile-практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес-требований, на качестве кода и безопасности.

Определение CI/CD

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

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

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

Инструменты CI/CD помогают настраивать специфические параметры окружения, которые конфигурируются при развертывании. А также CI/CD-автоматизация выполняет необходимые запросы к веб-серверам, базам данных и другим сервисам, которые могут нуждаться в перезапуске или выполнении каких-то дополнительных действий при развертывании приложения.

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

Зрелая практика CI/CD позволяет реализовать непрерывное развертывание: при успешном прохождении кода через CI/CD-конвейер, сборки автоматически развертываются в продакшн-окружении. Команды, практикующие непрерывную поставку, могут позволить себе ежедневное или даже ежечасное развертывание. Хотя здесь стоит отметить, что непрерывная поставка подходит не для всех бизнес-приложений.

Непрерывная интеграция улучшает коммуникации и качество

Непрерывная интеграция — это методология разработки, основанная на регламентированных процессах и автоматизации. При внедренной непрерывной интеграции разработчики часто коммитят свой код в репозиторий исходного кода. И большинство команд придерживается правила коммитить как минимум один раз в день. При небольших изменениях проще выявлять дефекты и различные проблемы, чем при больших изменениях, над которыми работали в течение длительного периода времени. Кроме того, работа с короткими циклами коммитов уменьшает вероятность изменения одной и той же части кода несколькими разработчиками, что может привести к конфликтам при слиянии.

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

Многие используют фича-флаги (feature flag) — механизм для включения и выключения функционала в рантайме. Функционал, который еще находится в стадии разработки, оборачивается фича-флагами и развертывается из master-ветки в продакшн, но отключается до тех пор, пока не будет полностью готов к использованию. По данным недавнего исследования 63 процента команд, использующих фича-флаги, говорят об улучшении тестируемости и повышении качества программного обеспечения. Для работы с фича-флагами есть специальные инструменты, такие как CloudBees Rollout, Optimizely Rollouts и LaunchDarkly, которые интегрируются в CI/CD и позволяют выполнять конфигурацию на уровне фич.

Другой способ работы с фичами — использование веток в системе контроля версий. В этом случае надо определить модель ветвления (например, такую как Gitflow) и описать как код попадает в ветки разработки, тестирования и продакшена. Для фич с длительным циклом разработки создаются отдельные фича-ветки. После завершения работы над фичей разработчики сливают изменения из фича-ветки в основную ветку разработки. Такой подход работает хорошо, но может быть неудобен, если одновременно разрабатывается много фич.

Этап сборки заключается в автоматизации упаковки необходимого программного обеспечения, базы данных и других компонент. Например, если вы разрабатываете Java-приложение, то CI упакует все статические файлы, такие как HTML, CSS и JavaScript, вместе с Java-приложением и скриптами базы данных.

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

Большинство CI/CD-инструментов позволяет запускать сборку вручную, по коммиту или по расписанию. Командам необходимо обсудить расписание сборки, которое подходит для них в зависимости от численности команды, ожидаемого количества ежедневных коммитов и других критериев. Важно, чтобы коммиты и сборка были быстрыми, иначе долгая сборка может стать препятствием для разработчиков, пытающихся быстро и часто коммитить.

Непрерывное тестирование — это больше, чем автоматизация тестирования

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

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

Регрессионные тесты — это только начало. Тестирование производительности, тестирование API, статический анализ кода, тестирование безопасности — эти и другие виды тестирования тоже можно автоматизировать. Ключевым моментом является возможность запуска этих тестов из командной строки, через веб-хук (webhook) или через веб-сервис и возврат результата выполнения: успешный был тест или нет.

Непрерывное тестирование подразумевает не только автоматизацию, но и интеграцию автоматического тестирования в конвейер CI/CD. Модульные и функциональные тесты могут быть частью CI и выявлять проблемы до или во время запуска CI-конвейера. Тесты, требующие развертывания полного окружения, такие как тестирование производительности и безопасности, часто являются частью CD и выполняются после разворачивания сборок в целевых средах.

CD-конвейер автоматизирует поставку изменений в различные окружения

Непрерывная поставка — это автоматическое развертывание приложения в целевое окружение. Обычно разработчики работают с одним или несколькими окружениями разработки и тестирования, в которых приложение развертывается для тестирования и ревью. Для этого используются такие CI/CD-инструменты как Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI.

Типичный CD-конвейер состоит из этапов сборки, тестирования и развертывания. Более сложные конвейеры включают в себя следующие этапы:

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

При использовании CI/CD-инструмента разработчики должны убедиться, что все параметры сконфигурированы вне приложения через переменные окружения. CI/CD-инструменты позволяют устанавливать значения этих переменных, маскировать пароли и ключи учетных записей, а также настраивать их во время развертывания для конкретного окружения.
Также в CD-инструментах присутствуют дашборды и отчетность. В случае сбоя сборки или поставки они оповещают об этом. При интеграции CD с системой контроля версий и agile-инструментами облегчается поиск изменений кода и пользовательских историй, вошедших в сборку.

Реализация CI/CD-конвейеров с Kubernetes и бессерверными архитектурами

Многие команды, использующие CI/CD-конвейеры в облаках используют контейнеры, такие как Docker, и системы оркестрации, такие как Kubernetes. Контейнеры позволяют стандартизировать упаковку, поставку и упростить масштабирование и уничтожение окружений с непостоянной нагрузкой.

Есть множество вариантов совместного использования контейнеров, инфраструктуры как код и CI/CD-конвейеров. Подробнее изучить это вы можете в статьях Kubernetes with Jenkins и Kubernetes with Azure DevOps.

Архитектура бессерверных вычислений представляет собой еще один способ развертывания и масштабирования приложений. В бессерверном окружении инфраструктурой полностью управляет поставщик облачных услуг, а приложение потребляет ресурсы по мере необходимости в соответствии с его настройками. Например, в AWS бессерверные приложения запускаются через функции AWS Lambda, развертывание которых может быть интегрировано в CI/CD-конвейер Jenkins с помощью плагина.

CI/CD обеспечивает более частое развертывание кода

Итак, подведем итоги. CI упаковывает, тестирует сборки и оповещает разработчиков, если что-то пошло не так. CD автоматически разворачивает приложения и выполняет дополнительные тесты.

CI/CD-конвейеры предназначены для организаций, которым необходимо часто вносить изменения в приложения с надежным процессом поставки. Помимо стандартизации сборки, разработки тестов и автоматизации развертываний мы получаем целостный производственный процесс по развертыванию изменений кода. Внедрение CI/CD позволяет разработчикам сосредоточиться на улучшении приложений и не тратить силы на его развертывание.

CI/CD является одной из DevOps-практик, поскольку направлена на борьбу с противоречиями между разработчиками, которые хотят часто вносить изменения, и эксплуатацией, требующей стабильности. Благодаря автоматизации, разработчики могут вносить изменения чаще, а команды эксплуатации, в свою очередь, получают большую стабильность, поскольку конфигурация окружений стандартизирована и в процессе поставки осуществляется непрерывное тестирование. Также настройка переменных окружения отделена от приложения и присутствуют автоматизированные процедуры отката.

Эффект от внедрения CI/CD-конвейеров можно измерить в виде ключевых показателей эффективности (KPI) DevOps. Такие KPI как частота поставки (deployment frequency), время реализации изменений (change lead time) и среднее время восстановления после инцидента (mean time to recovery) часто улучшаются при внедрении CI/CD с непрерывным тестированием. Однако CI/CD — это лишь один из процессов, который может способствовать этим улучшениям. Есть и другие условия для увеличения частоты поставки.

Для начала работы с CI/CD команде разработчиков и эксплуатации необходимо совместно определиться с технологиями, практиками и приоритетами. Команды должны выработать консенсус в отношении правильных подходов к своему бизнесу и технологиям, чтобы после внедрения CI/CD команда постоянно придерживалась выбранных практик.

Источник

Что такое непрерывная интеграция?

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

Непрерывная интеграция (CI) направлена на автоматизацию интеграции изменений кода от нескольких участников в единый программный проект. Это основная рекомендация DevOps, позволяющая разработчикам регулярно объединять изменения кода в центральном репозитории, где затем запускаются сборки и тесты. Автоматизированные инструменты используются для проверки нового кода перед интеграцией.

В основе процесса CI лежит система контроля версий исходного кода. Система контроля версий дополняется другими средствами, такими как автоматизированные проверки качества кода, инструменты проверки стиля синтаксиса и многими другими.

Статьи о непрерывной интеграции

Как перейти к непрерывной интеграции

Узнайте, как внедрить непрерывную интеграцию и автоматизированное тестирование за пять шагов.

Три скрипта Git hook для непрерывной интеграции

Знакомство со сценариями hook в Git, а также три сценария hook, которые можно использовать для непрерывной интеграции и непрерывной поставки.

5 Tips for CI-Friendly Git Repos

Five tips to make the best out of Git and your continuous integration tool!

Инструменты непрерывной интеграции

Пять советов о том, как извлечь максимум пользы из Git и вашего инструмента непрерывной интеграции.

Магистральная разработка

Подробнее о магистральной разработке — методе управления версиями, при котором разработчики объединяют небольшие частые обновления с центральной «магистралью», или основной веткой

Continuous Integration Tutorial

This tutorial will show you how to get started with continuous integration in three simple steps.

Важность непрерывной интеграции

Чтобы понять важность CI, полезно сначала обсудить ряд проблем, возникающих при отсутствии CI. Без CI разработчики вынуждены самостоятельно координировать действия и общаться при внесении кода в конечный продукт. Координация выходит за рамки команд разработчиков и затрагивает отдел эксплуатации и остальные отделы организации. Проектировщики должны согласовывать последовательный выпуск функций и исправлений, а также распределять ответственность между участниками.

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

Без надежного конвейера CI может возникнуть разлад между командой инженеров и остальными сотрудниками организации. Коммуникация между проектировщиками и инженерами может быть затруднена. Разработка становится черным ящиком, в который остальные участники команды вносят требования и функции (и получают нужные результаты, если сошлись звезды). Инженерам становится трудно прогнозировать скорость обработки запросов, поскольку не удается определить время интеграции новых изменений.

Зачем нужна непрерывная интеграция (CI)

CI помогает расширить персонал и нарастить эффективность команд инженеров. Внедрение CI по упомянутому сценарию позволяет разработчикам программного обеспечения параллельно вести независимую работу над функциями. Так они смогут самостоятельно и без задержек объединить эти функции в конечный продукт, когда все будет готово. CI — важная и надежная технология, используемая современными, высокоэффективными организациями в сфере разработки ПО.

Как можно использовать непрерывную интеграцию (CI)

CI обычно используется вместе с рабочим процессом Agile-разработки ПО. Организация подготавливает список заданий, составляющих дорожную карту продукта. Эти задания затем распределяются между участниками команды инженеров с целью поставки. С помощью CI ответственные разработчики могут выполнять эти задания по разработке ПО независимо и параллельно с коллегами. После завершения задания разработчик внесет проделанную работу в систему CI для интеграции с остальной частью проекта.

Непрерывная интеграция, непрерывное развертывание и непрерывная поставка

Непрерывная интеграция, развертывание и доставка образуют три стадии автоматизированного конвейера выпуска ПО (с учетом конвейера DevOps) Эти три стадии охватывают разработку программного обеспечения от идеи до доставки конечному пользователю. Стадия интеграции — это первый шаг в этом процессе. Непрерывная интеграция охватывает этап, на котором несколько разработчиков пытаются объединить изменения кода с главным репозиторием кода проекта.

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

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

Плюсы и минусы непрерывной интеграции

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

Масштабируемость

CI позволяет организациям масштабировать команду инженеров, кодовую базу и инфраструктуру. CI помогает создавать рабочие процессы DevOps и Agile, минимизируя бюрократию при интеграции кода и избыточную коммуникацию. Благодаря этому каждый участник команды может внести изменение кода вплоть до выпуска. CI позволяет выполнять масштабирование благодаря удалению организационных зависимостей при разработке отдельных функций. Разработчики могут создавать функции самостоятельно и с полной уверенностью в том, что слияние их кода с остальной частью кодовой базы пройдет без проблем. Это основной процесс DevOps.

Улучшение цикла обратной связи

Использование CI имеет полезные побочные эффекты, например быстрая обратная связь по бизнес-решениям. Проектировщики могут быстрее тестировать идеи и подбирать дизайн продукта с помощью оптимизированной платформы CI. Изменения можно быстро продвинуть и оценить. Ошибки и другие проблемы можно оперативно выявить и устранить.

Улучшение коммуникации

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

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

Внедрение и установка

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

Время на освоение технологии

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

Рекомендации по непрерывной интеграции (CI)

Разработка на основе тестов

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

Разработка на основе тестов (TDD) — это практика написания тестового кода и примеров перед фактическим программированием функции. Проектировщики могут активно использовать методику TDD как таковую для описания ожидаемого поведения бизнеса, на основе которого можно позже создать контрольные тесты. В «чистом» сценарии TDD разработчики и проектировщики встречаются и обсуждают спецификацию или список требований. Этот список требований преобразуют в перечень проверочных утверждений в коде. Затем разработчики пишут код с учетом этих утверждений.

Запросы pull и проверка кода

Большинство современных команд разработчиков ПО практикуют рабочий процесс, включающий запросы pull и проверку кода. Запросы pull критически важны для эффективной работы CI. Такой запрос создается, когда разработчик готов объединить новый код с основной кодовой базой. Запрос pull уведомляет других разработчиков о новых изменениях, подготовленных к интеграции.

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

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

Оптимизация скорости конвейера

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

Быстрый конвейер CI обеспечивает быстрый цикл обратной связи по продукту. Разработчики могут быстро продвигать изменения и экспериментировать с новыми идеями в сфере функциональности, чтобы повысить удобство использования. Любые ошибки можно быстро исправить и устранить по мере обнаружения. Ускорение работы не только дает вашим клиентам конкурентное преимущество, но и в целом повышает удобство использования.

Начало работы с непрерывной интеграцией

В основе CI лежит система контроля версий (VCS). Если целевая кодовая база для установки CI не имеет системы VCS, для начала нужно ее установить. Современные кодовые базы практически всегда оснащены системой VCS. Популярные решения включают Git, Mercurial и Subversion.

После установки системы VCS следует найти хостинг-площадку контроля версий. Большинство современных инструментов для хостинга контроля версий поддерживают CI и соответствующие функции. К популярным хостинг-площадкам контроля версий относятся Bitbucket, GitHub и GitLab.

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

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

Бизнес-процесс CI используется не только при разработке ПО. Конвейер CI будет полезен и другим сотрудникам организации, например командам по маркетингу и продажам, а также проектировщикам. Проектировщикам нужно будет подумать над тем, как обеспечить параллельную и одновременную разработку. Проектировщики и инженеры вместе определят соответствующие бизнес-ожидания в сфере функциональных возможностей, с учетом которых и будет создан набор автоматизированных тестов.

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

Заключение

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

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

Существует множество инструментов для установки и управления CI от сторонних разработчиков. К популярным решениям относятся Codeship, Bitbucket Pipelines, Semaphore, CircleCI, Jenkins, Bamboo, Teamcity и многие другие. Эти инструменты снабжены подробными руководствами по настройке и документацией, которые помогут начать работу.

Одни из лучших инструментов CI предоставляются Atlassian. Bitbucket Pipelines и Bamboo — отличные утилиты, позволяющие использовать в проекте современные функции CI. Jira — один из самых популярных в мире инструментов по управлению проектами, которые следуют принципам Agile и DevOps. Jira тесно интегрируется с другими проектами Bitbucket и в сочетании с конвейером CI может дать очень четкое представление о том, как в организации обстоят дела с выполнением проектов.

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

Источник