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

Справочная: как устроен процесс Continuous Integration

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

/ Flickr / Altug Karakoc / CC BY / Фото изменено

Термин

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

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

Впервые термин Continuous Integration появился в 1991 году. Его ввел в употребление создатель языка UML Гради Буч (Grady Booch). Инженер представил концепцию CI как часть собственной практики разработки — метода Буча. Он подразумевал инкрементальное уточнение архитектуры при проектировании объектно-ориентированных систем. Гради не описал каких-то требований к непрерывной интеграции. Но позже в своей книге «Object-Oriented Analysis and Design with Applications» он сказал, что задача методики — ускорить выпуск «внутренних релизов».

История

В 1996 году CI переняли создатели методологии экстремального программирования (XP) — Кент Бек (Kent Beck) и Рон Джеффрис (Ron Jeffries). Непрерывная интеграция стала одним из двенадцати ключевых принципов их подхода. Основатели XP уточнили требования к методологии CI и отметили необходимость проводить сборку проекта несколько раз в день.

В начале 2000-х методологию непрерывной интеграции стал продвигать один из основателей Agile Alliance Мартин Фаулер (Martin Fowler). Его эксперименты с CI привели к появлению первого программного инструмента в этой сфере — CruiseControl. Утилиту создал коллега Мартина — Мэттью Фоммель (Matthew Foemmel).

Цикл сборки в инструменте реализован в виде демона, периодически проверяющего систему управления версиями на изменения в кодовой базе. Решение можно скачать и сегодня — оно распространяется под BSD-подобной лицензией.

С появлением софта для CI практику начали перенимать всё больше компаний. Согласно исследованию Forrester [стр.5 отчёта], в 2009 году 86% из пятидесяти опрошенных технологических компаний использовали или внедряли CI-методы.

Сегодня практика Continuous Integration применяется организациями из самых разных индустрий. В 2018 году крупный облачный провайдер провёл опрос среди ИТ-специалистов компаний из сферы услуг, образования и финансов. Из шести тысяч респондентов 58% ответили, что используют в работе инструменты и принципы CI.

Как это работает

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

Общую схему процесса можно представить следующим образом:

Методология CI предъявляет ряд требований к разработчикам:

Сложности внедрения

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

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

Согласно опросам [стр.14 статьи], непрерывная интеграция повышает нагрузку на сотрудников компании (по крайней мере первое время). Им приходится осваивать новые инструменты, а коллеги не всегда помогают с обучением. Поэтому приходится разбираться с новыми фреймворками и сервисами «на ходу».

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

/ Flickr / theilr / CC BY-SA

Кто использует

Одними из первых преимущества методики оценили ИТ-гиганты. Google использует непрерывную интеграцию с середины 2000-х. CI внедрили для решения проблемы с задержками в работе поисковой системы. Непрерывная интеграция помогла оперативно обнаруживать и устранять неполадки. Сейчас CI используют все подразделения ИТ-гиганта.

Непрерывная интеграция помогает и небольшим компаниям, а еще инструменты CI используют финансовые и медицинские организации. Например, в Morningstar сервисы непрерывной интеграции помогли патчить уязвимости на 70% быстрее. А медицинская платформа Philips Healthcare смогла в два раза ускорить тестирование обновлений.

Инструменты

Вот нескольких популярных инструментов для CI:

Источник

Что такое 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.

Источник