CI/CD process - breaking down the steps
Этой статьей я хочу развернуть бесконечную восьмерку и подсобрать для себя значение каждой ступени. Я беру материал из источников, поэтому нижеизложенное не предтендует на уникальность и ссылается на них ниже.
CI/CD описывается как одна из практик, описывающая процессы непрерывной интеграции проекта (continious integration) и непрерывной поставки обновлений (continious delivery, ну или, что собственно мы в рамках нее делаем - continious deployment). Если почитать историю развития, то практика непрерываной интеграции появилась из-за …., а практика поставки -
Непрерывная интеграция (CI) — это рекомендация Agile и DevOps, с учетом которой разработчики интегрируют код в основную ветку или репозиторий кода как можно раньше и достаточно часто. Цель состоит в том, чтобы избежать стресса при интеграции, который случается, когда все разработчики ожидают окончания проекта или спринта, чтобы выполнить слияние своих частей работы. Непрерывная интеграция автоматизирует развертывание, а также помогает командам выполнять бизнес-требования, улучшать качество кода и повышать безопасность.
Одним из основных преимуществ внедрения CI является то, что этот подход экономит ваше время в течение всего цикла разработки благодаря раннему выявлению и устранению конфликтов. Кроме того, это отличный способ сократить время, затрачиваемое на устранение багов и ухудшений, путем создания качественного комплекта тестов. Наконец, это помогает всей команде лучше понимать базу кода и возможности, которые разрабатываются для клиентов.
Первый шаг на пути к непрерывной интеграции — настройка автоматического тестирования.
Отсюда,
нам нужна была скорость разработки → скорость интегрирования
→ скорость поставки
Начнем же разматывать этот фламандский узел:
Путь сборки: от push до deploy
- push в удаленный репозиторий
- merge в мастер
- сборка Jenkins/TeamCity (при использовании Maven или Gradle)
- закачка билда в репозиторий artifactory (от jfrog.com)
- деплой на сервер: Ansible, Udeploy, Bamboo или что то внутреннее
github flow (посмотреть разные flow) github actions
- релиз не связан с деплоем на прод
- мажор/минор/патч - это скоупы релиза
- релиз - мердж ветки в мастер и создание тега
Continuous integration vs Continuous delivery
- Continuous integration is focused on automatically building and testing code as compared to
CI (Continuous Integration, непрерывная интеграция) – начальная стадия «конвейера» по сборке кода и загрузке собранного ПО в среду разработки.
ядро это CI - непрерывная интеграция
- Continuous delivery, which automates the entire software release process up to production непрерывное развертывание/доставка
CD (Continuous delivery, непрерывная поставка) – является продолжением CI. В этой практике производится автоматизированное развертывание на тестовую среду продукта и разнообразные тесты над ним.
на примере Git! Какие бывают подходы ведения Git-репозиториев?
- GitFlow
- GitHubFlow Непосредственно связан с непрерывной поставкой
- GitLabFlow
- Trunk-Based Development
что такое пайплайн и как его писать?
- подготовительный этап
- сборка докер образа
- пуш докер образа в наше хранилище
- стадия деплоя в kuber
недостаточно просто внести файл Jenkinsfile в github, нужно настроить его еще и в дженкинсе
Ваша, познавшая философию CI/CD, Анжелика