CI/CD — это устоявшаяся догма разработки программного обеспечения. В Интернете полно статей и страниц, посвященных CI/CD. У них всегда один и тот же образ   . Могу поспорить, вы знаете образ, о котором я говорю. CI/CD  Я прочитал десятки статей на эту тему и испытал на себе реализацию сквозного конвейера CI/CD. Реальность такова, что реализация   гораздо сложнее, чем чтение статей, понимание общей картины CI/CD и использование теории. Разработка конвейера CI/CD требует междисциплинарных и опытных команд. конвейера CI/CD  В этой статье объясняется, как создать минимально жизнеспособный конвейер CI для приложения Python. Вы можете адаптировать содержание статьи к другим языкам и требованиям. В образце используются действия FastAPI и GitHub.  Пример GitHub:  https://github.com/joan-mido-qa/continous-integration-example  CI: Непрерывная интеграция  Позвольте мне добавить свои два цента к существующим описаниям непрерывной интеграции. Непрерывная интеграция означает регулярное слияние автоматически протестированных, утвержденных и готовых к доставке изменений кода в репозиторий проекта.  В этом примере   используются для автоматического выполнения необходимых проверок для каждого события «Pulll Request» или «Push to Main», чтобы гарантировать соответствие кода стандартам качества репозитория. Рынок предлагает разнообразную коллекцию инструментов CI/CD:   ,   ,   , GitLab и т. д. Выберите тот, который лучше всего соответствует вашим требованиям к конвейеру. действия GitHub Jenkins Travis CircleCI  Пример рабочего процесса проверяет, соответствует ли новый код правилам форматирования, выполняемым   . Затем он выполняет небольшие тесты с использованием   и, наконец, средние, устанавливая приложение   в кластере   D. pre-commit Pytest Helm Chart Kin  Ваш рабочий процесс непрерывной интеграции будет зависеть от размера вашей команды, зрелости, требований к приложениям и стратегии ветвления.  Статический анализ кода  Анализируйте изменения кода, не выполняя их. Инструменты статического анализа проверяют, что ваш код соответствует правилам форматирования, не использует устаревшие или поврежденные зависимости, а также является читабельным и достаточно простым. Они также предлагают кодировать антишаблоны и ошибки в зависимости от языка программирования.  Мы объясним, как установить, настроить и запустить Pre-commit. Вы можете комбинировать Pre-commit с другими инструментами анализа, такими как   или   . Sonar Synk  Предварительная фиксация    — это инструмент, написанный на Python. Настроить его в своем репозитории так же просто, как создать файл YAML и добавить версионные перехватчики, которые вы хотите запускать перед каждым коммитом. Pre-commit автоматически управляет зависимостями, необходимыми для перехватчиков, и автоматически исправляет найденные ошибки. Он поддерживает несколько типов файлов: JSON, YAML, tf, py, ts и т. д. Pre-commit  Экономьте затраты на инфраструктуру, локально выполняя проверки кода перед их отправкой. Вы можете запустить Pre-commit на своем CI, чтобы проверить формат отправленного кода.  Установите, настройте и запустите инструмент предварительной фиксации:   repos: - repo: https://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  Предложения Python Hook:    проверка статического типа для Python Mypy:    средство проверки статического формата для Python Ruff:    предложите лучшие практики программирования на Python. Обновление:    обеспечение стандартного использования коммитов и управления версиями. Commitizen:  Тест  Определения и объемы модульного, интеграционного и сквозного тестирования иногда размыты. Как и в случае с описанием непрерывной интеграции, я добавлю свои два цента к типам тестов   »: «Разработка программного обеспечения в Google    : быстрые тесты. Тестируйте небольшие фрагменты кода. Используйте тестовые двойники или макетированные среды (например, SQLite). Не требуется создавать какой-либо артефакт. Время: ~ 60 секунд. Маленький    : проверьте взаимодействие между несколькими частями кода. Они могут включать в себя создание артефактов, использование сторонних артефактов (например,   ) и подключение к локальной сети. Использование поддельных сред (например, docker-compose, Kind, Minikube и т. д.) или внешних сервисов (например, Azure Blob Storage или AWS S3). Время: ~ 300 секунд. Средний базы данных    : они используют среды, аналогичные производственным (например, тестирование производительности). Время: + 900 секунд. Большой  Наличие или отсутствие средних/крупных тестов в вашем конвейере непрерывной интеграции зависит от ваших требований.  Маленький  В примере используется Pytest для запуска тестов и клиент тестирования FastAPI для имитации среды. Никаких секретов; ваш инструмент тестирования языка программирования должен предоставить вам все необходимые зависимости для тестирования вашего приложения.  Кроме того, вы можете добавить проверку минимального тестового покрытия и загрузить ее как часть результатов. Тестовое покрытие — сложный показатель. Высокое покрытие тестами не подразумевает наличие хорошо протестированного кода, но 50 % — это больше, чем 0 % протестированного кода.  Середина    D — это легкий кластер Kubernetes «докер-в-докер», используемый для локальной разработки или CI. Мы используем Kind для настройки среды тестирования и запуска тестов: Kin  Создайте кластер Kind  Создайте образ Docker  Загрузите образ Docker в Kind  Установите MetalLB и примените необходимые CDR.  Установите Ingress-Nginx  Установите Helm Chart  Настройте хост вашей ОС  Загрузка изображений Docker  Kind не сможет загрузить ваше изображение, поскольку его нельзя загрузить из реестра. Kind требует, чтобы изображение было загружено перед его использованием.  МеталлЛБ    — это балансировщик нагрузки Kubernetes на «голом железе». Узнайте больше о том, зачем нужен балансировщик нагрузки, на веб-странице   . MetalLB MetalLB  После установки с помощью 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 можно найти на веб-странице   . Kind  Открыть приложение  Установите Ingress-Nginx Helm Chart. Затем установите приложение Helm Chart, определив объект Ingress. Установите для свойства ingressClassName значение nginx и определите хост (например, api.local). Наконец, измените   , добавив следующую строку: /etc/host  192.168.1.10 api.local  Вы можете определить столько хостов, сколько захотите, указывая на один и тот же адрес. Nginx сделает все остальное.  Разработайте инструмент для запуска, обновления и удаления локальной среды с помощью Kind. Разработчики могут использовать его для легкой отладки приложения, локального воспроизведения обнаруженных ошибок или запуска теста на CI.  Этот пример работает для дистрибутивов на базе Linux. Для Windows/MacOS может не работать как есть, могут потребоваться изменения.  Доставка  Прежде чем доставить необходимые артефакты, рабочий процесс выполняет этапы проверки и тестирования.  Мы используем   для управления выпусками артефактов. Commtizen автоматически обновляет версию артефакта и отправляет изменения. Он создает новый тег git с настроенным форматом тега. Вы также можете настроить Commtizen для обновления журнала изменений с учетом последних изменений. Commitizen   [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] Скоро…

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Этот звук создан на языке оригинала истории!

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

About Author

КОММЕНТАРИИ

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В

Related Stories

Утечка информации о системе Claude Sonnet 3.5: судебно-медицинский анализ

Повысьте свою производительность с помощью этих 18 инструментов разработчика 🚀🔥

Полное руководство по успешной миграции в облако: стратегии и лучшие практики

Создание криптопродуктов, ориентированных на пользователя: важность отзывов клиентов

Утечка информации о системе Claude Sonnet 3.5: судебно-медицинский анализ

Повысьте свою производительность с помощью этих 18 инструментов разработчика 🚀🔥

Полное руководство по успешной миграции в облако: стратегии и лучшие практики

Создание криптопродуктов, ориентированных на пользователя: важность отзывов клиентов

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps