Как создать и развивать процессы CI/CD в команде

Автор статьи: Артем Михайлов

CI/CD – это подход к разработке программного обеспечения, который обеспечивает автоматизацию процессов сборки, тестирования и доставки кода. Он позволяет командам разработчиков сконцентрироваться на написании кода, в то время как процессы сборки, тестирования и доставки автоматизируются, что увеличивает скорость и качество разработки.

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

Определения

Ключевой идеей в этом контексте является автоматизация, и разберемся подробнее, что скрывается за каждой составляющей процессов CI/CD.

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

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

Continuous Deployment (непрерывное развёртывание) — это продвинутая форма непрерывной интеграции и доставки, которая автоматически запускает сборку и доставку приложения в продакшн среду при успешном финальном тестировании. Эта составляющая CI/CD позволяет максимально ускорить процесс доставки изменений в приложении.

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

Причины использования CI/CD

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

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

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

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

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

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

Инструменты CI/CD

Инструменты CI/CD являются незаменимыми для автоматизации и упрощения рутинных разработческих задач.

Среди наиболее важных инструментов CI/CD можно назвать Jenkins, которая является популярной средой с открытым исходным кодом. Этот инструмент позволяет легко создавать и настраивать пакеты приложений, а также упрощает их доставку и развертывание на различных платформах. TeamCity, разработанная компанией JetBrains, отличается открытыми плагинами и удобным интерфейсом. С использованием GitLab CI/CD можно мгновенно создавать пакеты для приложений и автоматически доставлять изменения различным серверам. CircleCI и Travis CI также отличаются удобством и простотой в использовании.

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

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

Этапы работы CI/CD

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

Для того чтобы убедиться, что все изменения успешно интегрированы, используются специальные инструменты, такие как Jenkins, Travis CI, CircleCI и другие. Эти инструменты автоматически собирают код и запускают юнит-тесты для каждого изменения. Следовательно, при наличии ошибок или конфликтов с другими изменениями, выдаются уведомления.

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

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

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

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

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

Continuous Deployment иногда используют вместе с Continuous Delivery, однако, Continuous Deployment включает в себя больше автоматизации и меньше ручного участия команды.

Примером может служить компания Netflix. У них на Continuous Deployment процесс уходит около часа, начиная от merge request и заканчивая такими проверками, как стабильность, функциональность и безопасность. Новые версии приложения попадают в боевое окружение автоматически без каких-либо ручных действий. Этот процесс позволяет Netflix быстро доставлять контент своим пользователям, ускоряет время выпуска и позволяет быстро исправлять возникающие проблемы.

Использование метрик

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

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

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

Примеры использования

Одной из интересных практических частей для создания и развития процессов CI/CD в команде является настройка автоматической сборки и деплоя приложения на сервер.

Для этого можно использовать следующие инструменты:
— Gitlab CI/CD
— Docker

Ниже приведен пример .gitlab-ci.yml файла для настройки автоматической сборки и деплоя приложения на сервер:

image: docker:19.03.5

services:
  - docker:19.03.5-dind

.before_script:
  - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY

.build_job:
  script:
    - docker build -t $CI_REGISTRY_IMAGE .
    - docker push $CI_REGISTRY_IMAGE

.deploy_job:
  script:
    - ssh user@server "docker pull $CI_REGISTRY_IMAGE"
    - ssh user@server "docker rm -f app || true"
    - ssh user@server "docker run -d --name app -p 80:80 $CI_REGISTRY_IMAGE"

stages:
  - build
  - deploy

build:
  extends: .build_job
  stage: build

deploy:
  extends: .deploy_job
  stage: deploy

В этом примере используется Gitlab CI/CD, который имеет интеграцию с Docker — для сборки контейнера в Docker и его отправки в Docker registry.
Далее, на сервере развернут Docker, в который с помощью SSH подключения выполняются команды на деплой созданного образа и его запуск на сервере.

Для запуска этого процесса, нужно настроить сервер для выполнения команд по ssh, создать в Gitlab CI/CD переменные $CIREGISTRYUSER, $CIREGISTRYPASSWORD, $CIREGISTRYIMAGE, в которые мы будем помещать логин, пароль и путь до созданного в Docker registry образа приложения.

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

Для демонстрации данного процесса я выберу пример создания автоматических тестов для простого веб-приложения на ЯП Python с использованием фреймворка Flask.

Для начала необходимо создать файлы и настроить окружение для тестирования. Создадим три файла — app.py (главный файл приложения), apptest.py (файл с тестами) и requirements.txt (файл для установки необходимых библиотек).

В файле app.py напишем простое веб-приложение на Flask, которое будет отображать текст «Hello, world!» при запросе пользователем.

from flask import Flask

app = Flask(name)

@app.route("/")
def home():
     return "Hello, world!"

if name == "main":
     app.run(debug=True)

В файле apptest.py напишем тесты для нашего приложения. В данной реализации мы проверяем, что при запросе на корневой URL сервер возвращает строку «Hello, world!».

import unittest
from app import app

class TestApp(unittest.TestCase):

    def test_home(self):
        with app.test_client() as client:
            response = client.get('/')
            self.assertEqual(response.status_code, 200)
            self.assertEqual(response.get_data().decode(), 'Hello, world!')

if __name__ == '__main__':
    unittest.main()

Чтобы наш код работал по определенным правилам, добавим файл .lint в корневую папку проекта. В файле .lint пропишем правила линтера, с которыми мы будем сравнивать наш код. В данном примере мы используем линтер flake8, который проверяет PEP8 стандарты нашего кода:

[flake8]
exclude = .git,__pycache__,venv
max-line-length = 120

Теперь мы можем настроить автоматическое тестирование с последующей сборкой и деплоем приложения. Для этого используем сервис CircleCI. Создайте файл .circleci/config.yml в корне проекта со следующим содержимым:

version: 2
jobs:
  build:
    docker:
      - image: circleci/python:3.8.0
    steps:
      - checkout
      - run: pip install -r requirements.txt
      - run: pytest app_test.py
        name: Test
      - run:
          name: Flake8
          command: |
            pip install flake8
            flake8 .

В данном примере мы используем Docker-контейнер circleci/python:3.8.0 для сборки и тестирования нашего приложения. После установки необходимых библиотек и запуска тестов, мы также проверяем код на соответствие PEP8 стандартам с помощью линтера flake8.

Теперь, когда мы запушим изменения в наш репозиторий на GitHub, CircleCI автоматически запустит все тесты и линтеры, и если они успешно пройдены, опубликует нашу программу на веб-странице Heroku.

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

Заключение

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

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

• Зарегистрироваться на бесплатный урок