CI означает Continuous Integration, что переводится как "Непрерывная интеграция", а CD - это Continuous Delivery/Deployment, что переводится как "Непрерывная доставка/развертывание". "Доставка" и "Развертывание" отличаются лишь одной вещью. Позже покажу в чем разница.
Изначально, до появления методологии CI/CD, развертывание нового кода/приложений на конечных серверах происходило вручную. Были команды программистов. Допустим написали код, закинули на DEV-сервер, протестировали, все у них работает, собрали это в пакет. Загрузили пакет на какой-то NAS-сервер. Допустим где другие люди могут у этот пакет скачать либо перенести на другие сервера. В нашем случае это были админы, они брали этот пакет и загружали это все на STAGING-сервера. Там админы проводили финальные тесты, и если что-то шло не так, то программисты переписывали код, тестировали, собирали пакет, и так до тех пор по кругу, пока админы не были довольны. И только после этого загружали РУЧКАМИ это все в PRODUCTION-сервера, прикручивали мониторинг, всякое такое. Это все длилось очень долго.
Если базово, то CI/CD это подход, в котором мы выстраиваем процесс разработки программ так, чтобы можно было регулярно выливать свой код с новыми фичами в проект, который ты делаешь, а затем, все это дело должно автоматически собираться, тестироваться и развертываться. Под CI у нас подразумевается та часть, где мы сливаем свой код в общий репозиторий и у нас запускается автоматическая сборка, различные тесты, чтобы проверить, что наш новый код успешно и ничего не поломав ИНТЕГРИРУЕТСЯ с текущим кодом. Понимаешь теперь, что значит буква I в CI?
Ну, а в CD части, после того, как твоя фича успешно интегрировалось с основным кодом, вся эта БАЛАЛАЙКА начинает автоматически разворачиваться там, где нужно - будь то тестовые серваки или продакшн. Если все хорошо, идет развертывание в STAGING. И ВОТ ТУТ в процесс подключаются, либо НЕ подключаются админы. В случае, если подключаются, то они тестируют как новое приложение работает на STAGING, если все "ОК", то нажимаю кнопочку "DEPLOY" и идет развертывания в PRODUCTION. Это будет Continuous DELIVERY. То есть тут мы ДОСТАВЛЯЕМ нашу фичу, до конечного пользователя. Да-да, та самая Delivery в CD.
Если админы НЕ включаются в эту схему, то все происходит от программистов до PRODUCTION, то это будет Continuous DEVELOPMENT. То есть, если полностью весь процесс автоматизирован, то это будет РАЗВЕРТЫВАНИЕ. Когда код или приложение доставляется на конечные сервера.
Все это происходит параллельно со многими задачами, потому что правильно настроенный CI/CD процесс гарантирует, что ничего не сломается, когда все будут запушивать свой код. Раньше все делали ручками: сливали код, тесты запускали тоже вручную, ну и развернуть все это на серваках тоже было той еще задачей. Вся эта петрушка была гораздо дольше и релизить было сложнее и трудозатратнее, а релизы были реже и больше. CI/CD, кстати, хорошо работает с модными нынче методологиями Скрам (Scrum) и Аджайл (Aglie), когда мы быстро выпускаем какую-то фичу, быстро разворачиваем, быстро получаем обратную связь и по жопе, если конечный пользователь недоволен, и затем все по новой. Поэтому, CI/CD часто на картинках изображают в виде петли.
И ещё, стоит рассказать тебе про такую штуку, которая называется пайплайн (Pipeline), что в одном из вариантов перевода означает конвейер. Он настроен так, что в нем есть несколько этапов, которые выполняются последовательно - один за одним. Например, мы можем настроить пайплайн таким образом, что когда мы заливаем код в определенную ветку, у нас тригеррится процесс сборки приложения, который в случае успеха, запускает тесты, после успешного прохождения которых, приложение разварачивается на определенном серваке. Можно настроить посложнее или попроще, все как тебе хочется. А теперь давай посмотрим какие бывают CD/CD инструменты, и где можно настраивать эти ваши пипелины (Pipeline). Самые популярные ребята тут, это Jenkins (Дженкинс) и GitLab CI/CD (Гитлаб cи ай си ди). Дженкинс может интегрироваться с различными системами контроля версий и позволяет создавать различные гибкие пайплайны под наши нужды, а GitLab CI/CD является частью платформы GitLab, поэтому, очень удобно интегрировать пайплайны непосредственно с репозиторием GitLab. Кстати, еще можно назвать такие штуки как: Travis CI (трэвис си ай), CircleCI (сёркл си ай), TeamCity (тим сити), GitHub Actions (гитхаб экшенс) и Bamboo(бамбу). Ну, а под CD часть можно записать докер, кубернетис, ансибл, терраформ и много всего, тут нет строгой классификации и границы размыты.
После того, как развернули в продакшене - все идет все к админам. Они включают мониторинг и разные необходимые вещи. Если посмотреть со стороны DevOps, то когда они подключаются, то они смотрят как нужно пакет разворачивать на TEST/STAGING/PROD, и какие тесты им необходимо проделать. Иногда DevOps подключается раньше, они получают код и смотрят как его собрать, либо проверяют качество кода, либо начинают с тестов. Опять таки границы и тут размыты.
Вот такие пироги! CI/CD позволяет нам уменьшить сроки разработки и доставки софта до пользователя, повышает качество тестирования, и добавляет то что мы любим больше всего - автоматизацию, ну и скорее всего - силу земли! Ну и напоследок как всегда вопрос: если CI/CD так все фантастически автоматизирует, то почему manual-тестировщики все равно проверяют релизы?
