Практический курс CI/CD: простой, но функциональный рабочий процесс непрерывной интеграции [Часть 1]

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

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

В этой статье объясняется, как создать минимально жизнеспособный конвейер CI для приложения Python. Вы можете адаптировать содержание статьи к другим языкам и требованиям. В образце используются действия FastAPI и GitHub.

CI: Непрерывная интеграция

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

В этом примере используются для автоматического выполнения необходимых проверок для каждого события «Pulll Request» или «Push to Main», чтобы гарантировать соответствие кода стандартам качества репозитория. Рынок предлагает разнообразную коллекцию инструментов CI/CD: , , , GitLab и т. д. Выберите тот, который лучше всего соответствует вашим требованиям к конвейеру.

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

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

Статический анализ кода

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

Мы объясним, как установить, настроить и запустить Pre-commit. Вы можете комбинировать Pre-commit с другими инструментами анализа, такими как или .

Предварительная фиксация

— это инструмент, написанный на Python. Настроить его в своем репозитории так же просто, как создать файл YAML и добавить версионные перехватчики, которые вы хотите запускать перед каждым коммитом. Pre-commit автоматически управляет зависимостями, необходимыми для перехватчиков, и автоматически исправляет найденные ошибки. Он поддерживает несколько типов файлов: JSON, YAML, tf, py, ts и т. д.

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

Установите, настройте и запустите инструмент предварительной фиксации:

 repos: - repo: //github.com/pre-commit/pre-commit-hooks rev: v2.3.0 hooks: - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace

 $ pip install pre-commit $ pre-commit install $ pre-commit run --all-files

Тест

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

• Маленький : быстрые тесты. Тестируйте небольшие фрагменты кода. Используйте тестовые двойники или макетированные среды (например, SQLite). Не требуется создавать какой-либо артефакт. Время: ~ 60 секунд.

• Средний : проверьте взаимодействие между несколькими частями кода. Они могут включать в себя создание артефактов, использование сторонних артефактов (например, базы данных ) и подключение к локальной сети. Использование поддельных сред (например, docker-compose, Kind, Minikube и т. д.) или внешних сервисов (например, Azure Blob Storage или AWS S3). Время: ~ 300 секунд.

• Большой : они используют среды, аналогичные производственным (например, тестирование производительности). Время: + 900 секунд.

  
  

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

Маленький

В примере используется Pytest для запуска тестов и клиент тестирования FastAPI для имитации среды. Никаких секретов; ваш инструмент тестирования языка программирования должен предоставить вам все необходимые зависимости для тестирования вашего приложения.

Кроме того, вы можете добавить проверку минимального тестового покрытия и загрузить ее как часть результатов. Тестовое покрытие — сложный показатель. Высокое покрытие тестами не подразумевает наличие хорошо протестированного кода, но 50 % — это больше, чем 0 % протестированного кода.

Середина

D — это легкий кластер Kubernetes «докер-в-докер», используемый для локальной разработки или CI. Мы используем Kind для настройки среды тестирования и запуска тестов:

1. Создайте кластер Kind
2. Создайте образ Docker
3. Загрузите образ Docker в Kind
4. Установите MetalLB и примените необходимые CDR.
5. Установите Ingress-Nginx
6. Установите Helm Chart
7. Настройте хост вашей ОС

Загрузка изображений Docker

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

МеталлЛБ

— это балансировщик нагрузки Kubernetes на «голом железе». Узнайте больше о том, зачем нужен балансировщик нагрузки, на веб-странице .

После установки с помощью Helm Chart мы можем создать необходимые CRD:

 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: kind-advertisement --- apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: kind-address-pool spec: addresses: - "172.26.255.0/24"

Docker создает подсеть для кластера Kind (например, 172.26.0.0/16). Проверьте сетевой интерфейс Kind, чтобы узнать назначенный диапазон IP-адресов, и используйте этот адрес в качестве значения для ресурса IPAddressPool. Более подробную информацию о конфигурации MetalLB можно найти на веб-странице .

Открыть приложение

Установите Ingress-Nginx Helm Chart. Затем установите приложение Helm Chart, определив объект Ingress. Установите для свойства ingressClassName значение nginx и определите хост (например, api.local). Наконец, измените /etc/host , добавив следующую строку:

 192.168.1.10 api.local

Вы можете определить столько хостов, сколько захотите, указывая на один и тот же адрес. Nginx сделает все остальное.

Доставка

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

Мы используем для управления выпусками артефактов. Commtizen автоматически обновляет версию артефакта и отправляет изменения. Он создает новый тег git с настроенным форматом тега. Вы также можете настроить Commtizen для обновления журнала изменений с учетом последних изменений.

 [tool.commitizen] tag_format = "v$major.$minor.$patch" version_scheme = "semver" version_provider = "pep621" major_version_zero = true update_changelog_on_bump = true version_files = [ "charts/ci-example/Chart.yaml:version", "charts/ci-example/Chart.yaml:appVersion" ]

Рабочий процесс использует выходную версию Commitizen для установки тега Docker Image и Helm Chart.

Выводы

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

Практическое руководство по CI/CD: непрерывное развертывание [Часть 2] Скоро…