Цель этого руководства — дать общее представление о GitLab CI / CD, который поможет людям начать работу за 30 минут, не читая всю документацию GitLab.
Это руководство предназначено для начинающих, которые хотят работать с инструментами CI / CD, такими как GitLab CI / CD.
В этом уроке я кратко расскажу, что такое CI / CD, почему я решил использовать инструмент GitLab и пошаговое руководство по созданию .gitlab-ci.yaml с примером приложения.

CI/CD

CI / CD — это сокращение Continuous Integration/ Continuous Delivery / Continuous Deployment (т.е. непрерывной интеграции / непрерывной доставки / непрерывного развертывания).
Процесс позволяет командам создавать, тестировать и выпускать программное обеспечение с большей скоростью.
CI / CD устраняет ручное взаимодействие с человеком, где это возможно, автоматизируя все, кроме окончательного ручного развертывания кода в производство.
Одной из проблем реализации этой практики является интеграция различных инструментов и систем, необходимых для построения пайплайна CI / CD.
Например, вы можете хранить свой код в Bitbucket, тестировать его в наборах автоматических тестов в частной инфраструктуре и развертывать приложение в AWS или Microsoft Azure.
Сложные приложения, расположенные в нескольких системах, способствовали тому, что не все организации внедрили цельный пайплайн CI / CD.

Почему GitLab CI/CD?

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

С помощью GitLab CI / CD я могу создавать заявки, мёрдж реквесты, писать код и настраивать инструменты CI / CD без какого-либо другого приложения.

По сути, это универсальный магазин.

GitLab CI / CD  запускает сбору GitLab Runners.

Раннеры — это изолированные виртуальные машины, которые выполняют предопределенные шаги через API GitLab CI.

Вы можете узнать больше информации о GitLab раннерах по этой ссылке.

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

Сценарий

Допустим, у нас есть API-интерфейс Node.js, который извлекает список книг в базе данных.

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

Пайплайн — это группа шагов, которые сгруппированы по сходным характеристикам.

Пайплайн проекта устанавливает зависимости, запускает линтеры и любые скрипты, которые работают с кодом.

Пайплайн непрерывной интеграции запускает автоматизированные тесты и создает распределенную версию кода.

Наконец, Deploy Pipeline развертывает код для назначенного облачного провайдера и среды.

Шаги, выполняемые тремя конвейерами, называются заданиями.

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

Рабочие места являются основным строительным блоком для трубопроводов.

Они могут быть сгруппированы по этапам, а этапы могут быть сгруппированы в конвейеры.

Вот пример иерархии заданий, этапов и конвейеров:

А.) Сборка
      я. Установка зависимостей NPM
      II. Запуск ES-Linter
      III. Запуск Code-Minifier

B.) Тест
      I. Выполнить юнит, функциональный и сквозной тест.
      II. Запустите pkg для компиляции приложения Node.js
C.) Развертывание
      I. производство
         1.) Запустить экземпляр EC2 на AWS
      II. инсценировка
         1.) Запустить на локальном сервере разработки
В этой иерархии все три компонента рассматриваются как три разных пайплайна.
Основные маркеры — сборка, тестирование и развертывание — этапы, а каждый раздел в этих разделах — задания.
Давайте разберем это в файле yaml GitLab CI / CD.

Использование GitLab CI / CD

Чтобы использовать GitLab CI / CD, создайте файл с именем .gitlab-ci.yml в корне проекта в своем репозитории GitLab и добавьте следующий yaml:

image: node:10.5.0

stages:
  - build
  - test
  - deploy

before_script:
  - npm install

Как я упоминал ранее, GitLab CI / CD использует раннеры для выполнения пайплайнов.

Мы можем определить, на какую операционную систему и предопределенные библиотеки мы хотим, чтобы наш раннер основывался, используя директиву image.

В нашем случае мы будем использовать последнюю версию Node.js.

Директива stages позволяет нам заранее определить этап для всей конфигурации.

Задания будут выполняться в порядке, указанном в директиве stages.

Директива before_script используется для запуска команды перед всеми заданиями.

Теперь давайте начнем с нашей работы, посвященной этапу сборки.

Мы собираемся назвать эту работу build-min-code.

В этой джобе мы хотим установить зависимости и минимизировать код.

Мы можем начать с использования директивы script.

Директива script — это скрипт оболочки, который выполняется внутри раннера.

Затем мы собираемся назначить эту работу на этап «build». Чтобы назначить работу на этап, используйте директиву stage.

build-min-code:
  stage: build
  script:
    - npm install
    - npm run minifier
Теперь у нас есть джоба, связанная с нашей стадией сборки, и мы собираемся сделать это для нашей стадии тестирования.
Наше тест джоба будет называться run-unit-test, и мы собираемся использовать скрипт npm в нашем API для запуска тестового теста npm.
run-unit-test:
  stage: test
  script:
    - npm run test
Наконец, мы собираемся добавить задание для обработки этапа развертывания: deploy-production, deploy-staging.
В этом случае у нас будет два разных задания для развертывания (подготовка и производство).
Эти джобы будут отражать ту же схему, что и наши предыдущие, но с небольшими изменениями.
В настоящее время все наши задания автоматически запускаются при любом нажатии или переходе кода.
Мы не хотим, чтобы это было, когда мы внедряем наш код в стадии staging и production..
Чтобы этого не случилось, мы используем директиву only.
Эта директива определяет имена веток и тегов, для которых будет выполняться задание.
Джоба будет выглядеть следующим образом:
deploy-staging:
 stage: deploy
 script:
   - npm run deploy-stage
 only:
   - develop

deploy-production:
 stage: deploy
 script:
   - npm run deploy-prod
 only:
   - master
В нашем задании deploy-staging раннер выполнит его только в том случае, если произошли изменения в ветке develop и deploy-production — master ветви.
Ниже приведен пример, на котором показан переход кода в master ветку.
Запускаются все три этапа и задания, за исключением deploy-staging, поскольку передача кода осуществлялась в master ветку.
GitLab CI / CD поставляется с интуитивно понятным интерфейсом, который помогает показать, какие задания и этапы выполняются, а также какие ошибки возникают в процессе сборки.
Ниже приведена окончательная версия файла .gitlab-ci.yaml.
Если вы хотите проверить это самостоятельно, вот ссылка на пример приложения.
image: node:10.5.0

stages:
  - build
  - test
  - deploy

before_script:
  - npm install

build-min-code:
  stage: build
  script:
    - npm install
    - npm run minifier

run-unit-test:
  stage: test
  script:
    - npm run test

deploy-staging:
  stage: deploy
  script:
    - npm run deploy-stage
  only:
    - develop

deploy-production:
  stage: deploy
  script:
    - npm run deploy-prod
  only:
    - master

Заключение

Приведенные выше пункты представляют собой общий обзор возможностей, которые может предложить GitLab CI / CD.

GitLab CI / CD обладает более глубоким контролем автоматизации баз кодов, создавая и публикуя образы Docker для интеграции со сторонними инструментами.

Я надеюсь, что вы нашли этот материал полезным. Спасибо за прочтение!

 

 

Поделитесь статьей:

Добавить комментарий