CI/CD Половина ведра воды (1)

Адрес столбца:Конвейер CI/CD

Серия статей:CI/CD Половина ведра воды (2),CI/CD Половина ведра воды (3)

Автор этой статьи:Clfeng

гид

CICD — это сокращение от Continuous Integration, Continuous Delivery и Continuous Deployment. Относится к автоматическому выполнению серии сценариев в процессе разработки, чтобы снизить вероятность внесения ошибок в разработку и свести к минимуму ручное вмешательство в процесс нового кода от разработки до развертывания. Я считаю, что все часто соприкасаются с ними на работе, но, возможно, из-за характера работы, хотя они используются каждый день, они мало что о них знают.Когда возникает проблема с конвейером CI/CD , они могут только просить о помощи. Чтобы выйти из этой дилеммы, давайте углубимся в CI/CD с помощью серии статей.

Содержание этой главы проведет нас шаг за шагом от создания начального проекта до установки среды CI/CD и написания простого конвейера, чтобы мы могли понять, как построить собственный CI/CD. Наконец, он объяснит его самые основные концепции и позволит нам получить четкое представление о содержании первого написанного нами пайплайна.

Создайте проект GitLab

Установка среды

Примечание. На предприятии среда Linux в основном используется в качестве средства запуска CI/CD, поэтому для следующей установки среды используется среда Linux;

Информация об операционной системе:

Linux version 3.10.0-1160.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

Примечание. Linux-среда автора — это система centos:7, установленная на локальной macOS через виртуальную машину.

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

установить докер

Раннер, который мы будем использовать позже, будет использовать docker в качестве исполнителя, поэтому давайте сначала установим docker в системе.

Установку докера можно установить в соответствии с руководством на официальном сайте.docs.docker.com/engine/Inst…

Основной процесс установки:

1. Удалите старую версию докера

sudo yum remove docker \
                docker-client \
                docker-client-latest \
                docker-common \
                docker-latest \
                docker-latest-logrotate \
                docker-logrotate \
                docker-engine

2. Начните установку докера

sudo yum install -y yum-utils
sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

# 安装docker引擎
sudo yum install docker-ce docker-ce-cli containerd.io

3. Запустите докер

sudo systemctl start docker

4. Установка прошла успешно

установить бегун

docs.git lab.com/runner/Inst…

1. Выполните скрипт для установки gitlab-runner

# 1. 添加官方的GitLab仓库
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash

# 2. 安装gitlab-runner
sudo yum install gitlab-runner

2. Установка прошла успешно

зарегистрировать бегуна

Войдите на страницу CI/CD репозитория проекта, чтобы просмотреть соответствующий URL-адрес и токен.

воплощать в жизнь`gitlab-runner register`команду и следуйте инструкциям, чтобы зарегистрировать бегун

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

На данный момент мы готовы изучить базовую среду CI/CD~

Затем мы пытаемся написать простой конвейер

Примечание. Пока не нужно понимать содержимое .gitlab-ci.yml, оно будет объяснено шаг за шагом позже.

первый трубопровод

Добавить файл конфигурации конвейера

В корневом каталоге проекта добавьте файл .gitlab-ci.yml и отправьте его в удаленную ветку.Содержимое файла выглядит следующим образом:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build_job:
  stage: build # 指定job所属stage
  image: centos:7 # 指定执行job的所使用docker镜像
  tags: 
    - clf-centos-runner # 指定执行job的runner（即机器）
  script: # job执行时运行的脚本
    - echo "build project"

test_job:
  stage: test
  image: centos:7
  tags: 
    - clf-centos-runner
  script:
    - echo "test project"

deploy_job:
  stage: deploy
  image: centos:7
  tags: 
    - clf-centos-runner
  script:
    - echo "deploy project"

Просмотр выполнения конвейера

понимать основные понятия

В главе «Первый конвейер» мы добавили .gitlab-ci.yml и написали кучу конфигураций. Затем, после отправки файла и отправки его в GitLab, вы можете увидеть, что конвейер выполняется. Так что же означает конфигурация, которую мы написали ранее в файле .gitlab-ci.yml? Как написать конфигурацию пайплайна?

Чтобы написать базовую конфигурацию конвейера, нам нужно изучить следующее:

синтаксис yaml
Что такое CI/CD
Ключевые понятия CI/CD
- pipeline
- stage
- job

синтаксис yaml

Файл конфигурации конвейера CI/CD написан с синтаксисом yaml, поэтому сначала вам нужно понять соответствующий синтаксис. Здесь рекомендуется изучить статью учителя Жуань Ифэн:

Вууху. Руан Ифэн.com/blog/2016/0…

Что такое CI/CD

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

Непрерывная интеграция (CI) 【Непрерывная интеграция】
Непрерывная доставка (CD) 【Непрерывная доставка】
Непрерывное развертывание (CD)【Непрерывное развертывание】

Конечно, это введение может быть немного проще, поэтому следующее более подробное введение взято из выдержки.Если вам интересно, вы можете взглянуть.

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

Современная разработка приложенийЦель состоит в том, чтобы несколько разработчиков работали над разными функциями одного и того же приложения одновременно. Однако, если предприятие запланировало день для слияния исходного кода всех ветвей (так называемый "Дата слияния"), что в конечном итоге может оказаться громоздким, трудоемким и ручным. Это связано с тем, что когда независимый разработчик вносит изменения в приложение, есть вероятность, что оно будет конфликтовать с одновременными изменениями, внесенными другими разработчиками. Каждый разработчик настраивает свои собственный местныйИнтегрированная среда разработки (IDE), вместо того, чтобы команда согласовала облачную IDE, усугубила бы проблему.

Непрерывная интеграция (CI) помогает разработчикам чаще объединять изменения кода в общую ветку или «ствол» (иногда даже ежедневно). После объединения изменений, внесенных разработчиками в приложение, система проверяет эти изменения, автоматически создавая приложение и запуская различные уровни автоматических тестов (обычно модульных и интеграционных тестов), чтобы убедиться, что они не нарушили работу приложения. Это означает, что тесты охватывают все, от классов и функций до различных модулей, составляющих все приложение. Если автоматизированное тестирование обнаруживает конфликты между новым и существующим кодом, CI упрощает быстрое исправление этих ошибок.

непрерывная поставка

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

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

Непрерывное развертывание

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

По сути, непрерывное развертывание означает, что изменения, внесенные разработчиком в приложение, вступают в силу в течение нескольких минут после его написания (при условии, что оно проходит автоматизированные тесты). Это упрощает постоянное получение и интеграцию отзывов пользователей. В совокупности все эти связанные этапы CI/CD помогают снизить риск развертывания вашего приложения, упрощая выпуск изменений в приложении небольшими частями, а не всеми сразу. Тем не менее, первоначальные вложения по-прежнему велики, поскольку также необходимо написать автоматизированные тесты для соответствия различным этапам тестирования и выпуска в конвейере CI/CD.

Персональное резюме:

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

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

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

Ключевые понятия CI/CD

Пояснение с официального сайта:

Pipelines are the top-level component of continuous integration, delivery, and deployment.

Jobs, which define what to do. For example, jobs that compile or test code.
Stages, which define when to run the jobs. For example, stages that run tests after stages that compile the code.

In general, pipelines are executed automatically and require no intervention once created. However, there are also times when you can manually interact with a pipeline.

Перевод:

Конвейеры — это компоненты верхнего уровня для непрерывной интеграции, доставки и развертывания.

Работа, определениеделать что. Например, задания, которые компилируют или тестируют код.
Этапы, определитькогдаЗапустите работу. Например, этап, на котором выполняются тесты, следует за этапом, на котором компилируется код.

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

понимать

Конвейеры — это компонент верхнего уровня CI/CD.После создания конвейера он автоматически выполняет ряд задач.Вмешательство человека не требуется. Под компонентом конвейера будет несколько подкомпонентов задания и этапов, среди которых этапы определяют, сколько этапов (ссылок) имеет весь конвейер и каков порядок выполнения этих этапов (ссылок). Задание — это конкретная задача в каждом звене [в одном этапе (ссылке) может быть несколько задач], при определении задачи нужно четко описать, при каких обстоятельствах выполняется задача и что делать.

Далее разберемся с конфигурацией в «Первом пайплайне»:

stages:
  - build
  - test
  - deploy

build_job:
  stage: build # 指定job所属stage
  image: centos:7 # 指定执行job的所使用docker镜像
  tags: 
    - clf-centos-runner # 指定执行job的runner（即机器）
  script: # job执行时运行的脚本
    - echo "build project"

test_job:
  stage: test
  image: centos:7
  tags: 
    - clf-centos-runner
  script:
    - echo "test project"

deploy_job:
  stage: deploy
  image: centos:7
  tags: 
    - clf-centos-runner
  script:
    - echo "deploy project"

Приведенная выше конфигурация представляет собой конфигурацию полного конвейера, так как же этапы и задания конвейера отражены в этой конфигурации?

Прежде всего, когда мы определяем конвейер, нам нужно учитывать, сколько этапов этот конвейер имеет и каков порядок этапов? Возьмем в качестве примера пайплайн «Первого пайплайна»:

Всего есть три этапа: сборка, тестирование и развертывание; вместе эти три этапа описывают обработку, которую необходимо выполнить после добавления кода в библиотеку, а именно сборку кода, тестирование и развертывание.

Это отражено в конфигурации:

stages:
  - build
  - test
  - deploy

Порядок — это порядок каждого элемента в массиве: сборка => тест => развертывание.

После определения каждого этапа нам необходимо дополнительно определить соответствующую работу (задачу) для каждого этапа, взяв в качестве примера этап сборки:

stages:
  - build

build_job: # 这是job的名称
  stage: build # 指定job所属stage
  image: centos:7 # 指定执行job的所使用docker镜像
  tags: 
    - clf-centos-runner # 指定执行job的runner（即机器）
  script: # job 做什么
    - echo "build project"

Как упоминалось ранее, нам нужно определить соответствующую работу (задачу) для каждого этапа. Так как же работа соответствует соответствующему этапу? Соответствует ключевому слову этапа:

stages:
  - build

build_job: # 这是job的名称
  stage: build # 指定job所属stage

Значение build of stage соответствует одному из значений build под массивом stages, который мы определили ранее, а это значит, что build_job — задача этапа build.

Мы также упомянули, что задание используется для определения того, что делать, так что же делает задание build_job? Взгляните на ключевое слово скрипта:

stages:
  - build

build_job: # 这是job的名称
  stage: build # 指定job所属stage
  script: # job 做什么
    - echo "build project"

эммм, просто введите «проект сборки».

В предыдущей конфигурации есть несколько других конфигураций, давайте, кстати, посмотрим на их соответствующие функции.

tags: В этом поле указывается раннер (машина), используемая для выполнения задания, мы указываем ранее зарегистрированный раннер с именем clf-centos-runner

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

На данный момент, я полагаю, мы уже можем приблизительно понять конфигурацию «Первого трубопровода»;В целом так:

Весь пайплайн состоит из трех этапов build=>test=>deploy, для каждого этапа мы определяем задачу. Каждая задача указывает машину (бегун), используемую для выполнения задачи, и указывает образ centos:7, используемый исполнителем (executor). В настоящее время задача выполнения каждого задания очень проста для вывода соответствующего текста.

Подождите немного, кажется, чего-то не хватает. Почему мы видим конвейер сразу после того, как написали файл .gitlab-ci.yml, отправили его и отправили? Как gitlab знает, что нужно выполнить конвейер в это время? Запускается ли конвейер только при изменении файла .gitlab-ci.yml? Теперь, когда я это написал, я больше не буду изменять файл .gitlab-ci.Может ли конвейер все еще запускаться?

Это включает в себя механизм запуска конвейера.Вообще говоря, пока есть отправка кода, конвейер будет запущен. Когда код будет отправлен в удаленный репозиторий GibLab, GibLab увидит, существует ли файл конфигурации конвейера. Помимо отправки кода, у нас есть другие способы запуска конвейера. Например: запланированные задачи, запуск вручную, вызов API GibLab и т. д.

Эпилог

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

Ссылка на ссылку

docs.git lab.com/ohoh/this/index…

Woohoo. RedHat.com/this/topics/ The…