ПОЧЕМУ НЕОБХОДИМО ИСПОЛЬЗОВАТЬ CONTINUOUS INTEGRATION В ПРОЦЕССЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

Непрерывная интеграция (CI) – это процесс автоматизации сборки и тестирования кода каждый раз, когда член команды вносит изменения в систему управления версиями. CI предполагает, что разработчики выполняют делиться, объединение написанного ими кода и модульных тестов в общем репозитории системы контроля версий после каждого небольшого выполнения задачи. Слияние кода запускает автоматизированную систему сборки для получения последнего кода из общего репозитория, а также для сборки, тестирования и проверки полной ветки (также называемой магистральной или основной), в которую произошло слияние кода. Данный термин (CI) впервые назван и предложен Гради Бучем в 1991 г [1].

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

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

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

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

Непрерывная доставка (CD, от англ. Continuous Delivery) – это подход к разработке программного обеспечения, при котором команды производят программное обеспечение в короткие циклы, гарантируя, что программное обеспечение может быть выпущено надежно в любое время, а при выпуске программного обеспечения – вручную. Другими словами, непрерывная доставка – это практика автоматизации всего процесса релиза ПО. Идея заключается в том, чтобы выполнять CI, а также автоматически готовить и вести релиз к production. При этом желательно добиться следующего: любой, кто обладает достаточными привилегиями для развертывания нового релиза может выполнить развертывание в любой момент, и это можно сделать в несколько кликов. Следовательно, программист, избавившись практически от всей ручной работы, трудится продуктивнее.

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

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

Непрерывное развертывание располагается «на уровень выше» непрерывной доставки. В данном случае все изменения, вносимые в исходный код, автоматически развертываются в production, без явной отмашки от разработчика. Как правило, задача разработчика сводится к проверке запроса на слияние сделанных изменений в коде с основной веткой разработки (pull request) от коллеги и к информированию команды о результатах всех важных событий.

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

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

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

• использовать облачную систему контроля версий для исходного кода (BitBucket, GitHub, GitLab);
• обеспечить покрытие всего функционала тестами и рассматривайте ваши тесты как код production уровня;
• использовать подходящую систему непрерывной интеграции и доставки, которая позволит запускать тесты во время любых изменений кода в репозитории, а также развертывать ваши сборки там, где вам необходимо.

Внедрение методологии "Continuous Integration" несет за собой несколько преимуществ:

• быстрый цикл обратной связи;
• повышение прозрачности;
• избегание «интеграционного ада»;
• обнаружение и устранение проблем на ранней стадии;
• улучшение качества программного обеспечения и его тестируемости.

Continuous integration и continuous delivery – это практики, без которых современная разработка программного обеспечения не представляется возможным. Данные практики позволяют очень хорошо экономить время всей команды и держать руку на пульсе во время интеграции нового кода с уже существующим. Сегодня на рынке существует широкое многообразие систем CI/CD, решающие любые проблемы интеграции. Однако использование одной лишь системы CI/CD не может обеспечить полный автоматизированный цикл реализации какого-либо функционала от идеи до появления его в production.

Быстрый цикл обратной связи. В разработке программного обеспечения то, чего вы не знаете, может вам навредить. Отсутствие обратной связи о качестве и влиянии сделанных вами изменений – это то, что действительно тормозит процесс разработки программного обеспечения. Может складываться ощущение, что все двигается быстро, если код быстро интегрируется в основную ветку и происходит переход к другой задаче без выполнения каких-либо тестов или проверок работоспособности. Однако, реальность другая и чем придет осознание этого, тем лучше. Обычно оно приходит, когда появляется необходимость выяснить, какие изменения, когда и кем что-то сломали. Инструменты непрерывной интеграции при правильном использовании устранят большую часть этой головной боли, предоставляя быстрые ответы на вопрос «Сломал ли я что-либо?» для каждого изменения кода разработчиком.

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

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

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

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

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

Список литературы:

1. Object-oriented analysis and design [электронный ресурс] — Режим доступа. — URL: http://kmvportal.co.in/Course/OOAD/object-oriented-analysis-and-design-with-applications-2nd-edition.pdf (дата обращения 30.12.2018)
2. Непрерывная интеграция // Википедия: свободная энциклопедия [электронный ресурс] — Режим доступа. — URL: https://ru.wikipedia.org/wiki/Непрерывная_интеграция (дата обращения 30.12.2018)
3. Что такое непрерывная интеграция // Amazon Web Services [электронный ресурс] — Режим доступа. — URL: https://aws.amazon.com/ru/devops/continuous-integration/ (дата обращения 30.12.2018)