70. Конвейеры CI/CD
Содержание
Реализация конвейера CI/CD (Continous Integration/Continous Deployment) является основой современной среды DevOps.
Он устраняет разрыв между разработкой и операциями, автоматизируя сборку, тестирование и развертывание приложений.
Мы много говорили об этой мантре Continous во вступительном разделе задачи. Но повторим еще раз:
Continous Integration (CI) - это более современная практика разработки программного обеспечения, при которой инкрементные изменения кода вносятся чаще и надежнее. Автоматизированные шаги рабочего процесса сборки и тестирования, запускаемые Contininous Integration, обеспечивают надежность изменений кода, сливаемых в репозиторий.
Затем этот код / приложение быстро и беспрепятственно доставляется в рамках процесса непрерывного развертывания.
Важность CI/CD?
- Доставка программного обеспечения быстро и эффективно
- Облегчает эффективный процесс вывода приложений на рынок как можно быстрее.
- Непрерывный поток исправлений ошибок и новых функций без ожидания месяцев или лет выпуска версии.
Возможность для разработчиков регулярно вносить небольшие важные изменения означает, что мы быстрее получаем исправления и новые функции.
Хорошо, так что же это значит?
В День 5 мы рассмотрели много теории, лежащей в основе DevOps, и, как уже упоминалось здесь, CI/CD Pipeline является основой современной среды DevOps.
Я хочу повторить некоторые ключевые моменты на этом изображении выше, теперь, когда мы немного продвинулись в изучении основ DevOps.
Мы имеем в виду жизненный цикл разработки программного обеспечения (SDLC).
Этапы обычно записываются в бесконечном цикле, поскольку этот цикл повторяется вечно.
The steps in the cycle are, developers write the code then it gets built or all compiled together then it’s tested for bugs then it’s deployed into production where it’s used (Operated) by end users or customers then we monitor and collect feedback and finally we plan improvements around that feedback rinse and repeat.
Давайте немного углубимся в CI/CD
CI
CI - это практика разработки, которая требует от разработчиков интегрировать код в общий репозиторий несколько раз в день.
Когда код написан и помещен в репозиторий, такой как github или gitlab, вот тут-то и начинается волшебство.
Код проверяется автоматизированной сборкой, что позволяет командам или владельцу проекта обнаружить любые проблемы на ранней стадии.
После этого код анализируется и подвергается серии автоматизированных тестов.
- Юнит-тестирование - тестирование отдельных частей исходного кода.
- тестирование на валидность - проверяется, что программное обеспечение удовлетворяет или соответствует предполагаемому использованию.
- Тестирование формата проверяет синтаксис и другие ошибки форматирования.
Эти тесты создаются как рабочий процесс и затем запускаются каждый раз, когда вы продвигаете мастер-ветку, поэтому практически каждая крупная команда разработчиков имеет какой-то рабочий процесс CI/CD, и помните, что в команде разработчиков новый код может поступать из команд по всему миру в разное время суток от разработчиков, работающих над самыми разными проектами, поэтому эффективнее построить автоматизированный рабочий процесс тестов, которые убеждаются, что все находятся на одной странице, прежде чем код будет принят. Человеку потребуется гораздо больше времени, чтобы сделать это каждый раз.
Как только мы завершили наши тесты и они прошли успешно, мы можем скомпилировать их и отправить в наш репозиторий. Для примера я использую Docker Hub, но это может быть любое другое хранилище, которое затем будет использовано для CD-аспекта конвейера.
Итак, этот процесс, очевидно, очень похож на процесс разработки программного обеспечения: мы создаем наше приложение, добавляем, исправляем ошибки и т.д., затем обновляем контроль исходных текстов и версионируем их, одновременно тестируя.
Переходим к следующему этапу - элементу CD, который на самом деле все больше и больше является тем, что мы обычно видим от любого готового программного обеспечения, я бы утверждал, что мы увидим тенденцию, что если мы получим наше программное обеспечение от такого поставщика, как Oracle или Microsoft, мы будем потреблять его из репозитория типа Docker Hub, а затем мы будем использовать наши конвейеры CD для развертывания этого в наших средах.
CD
Теперь у нас есть протестированная версия нашего кода, и мы готовы к развертыванию на природе. Как я уже сказал, поставщик программного обеспечения пройдет через этот этап, но я твердо уверен, что именно так мы все будем развертывать готовое программное обеспечение, которое нам понадобится в будущем.
Теперь пришло время выпустить наш код в среду. Это будет включать в себя производственную среду, но также, вероятно, и другие среды, такие как staging.
Следующим шагом, по крайней мере, в день 1 v1 развертывания программного обеспечения, является то, что нам нужно убедиться, что мы переносим правильную кодовую базу в правильную среду. Это может быть извлечение элементов из репозитория программного обеспечения (DockerHub), но более чем вероятно, что мы также извлечем дополнительную конфигурацию из другого репозитория кода, например, конфигурацию для приложения. На диаграмме ниже мы извлекаем последний релиз программного обеспечения из DockerHub, а затем выпускаем его в нашу среду, при этом, возможно, получая конфигурацию из репозитория Git. Наш CD-инструмент выполняет это и передает все в нашу среду.
Скорее всего, это делается не одновременно, т.е. мы переходим в промежуточную среду и запускаем ее с нашей собственной конфигурацией, чтобы убедиться, что все правильно, и это может быть ручным шагом для тестирования или автоматизированным (давайте остановимся на автоматизированном), прежде чем позволить этому коду быть развернутым в продакшн.
После этого, когда выйдет v2 приложения, мы прополощем и повторим шаги, на этот раз мы убедимся, что наше приложение + конфигурация развернуты в staging, убедимся, что все хорошо, и затем развернем в production.
Зачем использовать CI/CD?
Я думаю, мы уже неоднократно рассказывали о преимуществах, но они заключаются в том, что CI/CD автоматизирует то, что в противном случае пришлось бы делать вручную. Он находит небольшие проблемы до того, как они проникнут в основную кодовую базу. Вы, вероятно, можете себе представить, что если вы выкладываете плохой код своим клиентам, то у вас будут плохие времена!
Это также помогает предотвратить то, что мы называем техническим долгом - идею о том, что поскольку основные репозитории кода постоянно дорабатываются с течением времени, то быстрое исправление, сделанное в первый день, становится экспоненциально более дорогим исправлением годы спустя, потому что теперь этот пластырь исправления будет так глубоко переплетен и вплетен во все кодовые базы и логику.
Инструментарий
Как и в других разделах, мы будем работать с некоторыми инструментами, которые обеспечивают процесс конвейера CI/CD.
Я считаю важным отметить, что не все инструменты должны делать и CI, и CD. Мы рассмотрим ArgoCD, который, как вы догадались, отлично справляется с CD-элементом развертывания нашего программного обеспечения в кластере Kubernetes. Но что-то вроде Jenkins может работать на разных платформах.
Я планирую рассмотреть следующее:
- Jenkins
- ArgoCD
- GitHub Actions