Практика автоматизированной сборки и выпуска интерфейса на основе GitLab CI/CD

CI/CD

После того, как компания создала внутреннюю платформу GitLab, активные интерфейсные проекты были перенесены из SVN в GitLab. В этой статье описывается, как автоматизировать сборки и выпуски на основе GitLab CI/CD.

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

1. Текущий процесс сборки и выпуска

В этом разделе мы сначала расскажем о преимуществах использования GitLab CI/CD, а затем представим процессы сборки и выпуска до и после использования GitLab CI/CD.

1. Командные преимущества

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

2. Соберите и выпустите перед использованием GitLab CI/CD

2.1 Процесс

  1. После завершения разработки выполните сборку локально и отправьте упакованный HTML-файл после сборки.
  2. Откройте систему публикации и опубликуйте файл HTML.

2.2 Болевые точки

  1. Операционный процесс публикации кода длительный и трудоемкий. После завершения разработки, когда код выпущен, с ним нужно пройти много ручных операций, а система выпуска медленная, и каждый выпуск занимает около 5 минут.
  2. Локальная среда каждого человека непоследовательна, и существует риск несогласованности при выпуске различных онлайн-кодов.

Требуется примерно 2,3 пункта вручную

Всего по крайней мере в 8 раз ручной операции

Локальная сборка:

  1. Выполните команду сборки и дождитесь завершения сборки.
  2. После завершения сборки отправьте упакованный HTML-файл.

Почтовый индекс:

  1. Откройте систему публикации
  2. Выберите проект выпуска и среду
  3. Откройте страницу выпуска
  4. Выберите файл релиза
  5. Заполните информацию о выпуске
  6. Нажмите, чтобы подтвердить выпуск

3. Сборка и выпуск с использованием GitLab CI/CD

Выпуск кода за один шаг: просто объедините ветку разработки с веткой, соответствующей среде выпуска, и после отправки ветки GitLab CI/CD автоматически соберет и выпустит.

2. Что такое GitLab CI/CD

В этой части мы сначала кратко расскажем о GitLab CI/CD, а затем расскажем, как создать GitLab CI/CD с нуля.

1. Краткое введение в GitLab CI/CD

Как показано на рисунке ниже, после отправки кода в GitLab конвейер будет запущен для автоматической сборки и публикации после выполнения указанных условий.

Конвейер можно понимать как задачу сборки, которая может содержать несколько процессов, таких как загрузка зависимостей, выполнение тестов, компиляция и развертывание. Когда конвейер запускается, он делится на несколько процессов, и то, что делает каждый процесс, находится в проекте..gitlab-ci.ymlопределяется в файле.

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

GitLab CI/CD

2. Общий процесс GitLab CI/CD

Конкретный процесс и работа конвейера GitLab CI/CD объявлены в файле .gitlab-ci.yml.После запуска конвейера GitLab Runner запустит его в соответствии с файлом .gitlab-ci.yml и вернуться в систему GitLab после запуска.

2.1 Файл .gitlab-ci.yml

Файл .gitlab-ci.yml — это файл декларации, используемый для определения процесса GitLab CI/CD, разделенного на несколько этапов и того, что делает каждый этап.

Что касается того, что делать и как это делать, в основном используются операции командной строки и сценариев, и подробное введение будет сделано в практической части позже.

Если задействована какая-то логика, то будут использоваться скрипты, в нашем проекте в основном используются скрипты Shell и скрипты Python.

2.1 GitLab Runner

GitLab Runner — это среда выполнения CI, отвечающая за выполнение файла gitlab-ci.yml и возврат результата в систему GitLab. Раннер может принимать разные формы, докер, виртуальную машину или оболочку, и метод выбирается при регистрации раннера.

3. Создайте GitLab CI/CD с нуля

Чтобы понять весь процесс, вы можетеGitLabСоздайте проект и запустите весь процесс CI/CD.

3.1 Создайте новый проект GitLab

  1. Войдите в GitLab:gitlab.com/
  2. Создайте новый собственный проект

3.2 Настройка бегуна

GitLab предоставляет какие-то общие раннеры, мы не можем разобраться с раннерами.

3.3 Создайте новый файл .gitlab-ci.yml

  1. Перетащите проект на локальный
  2. Создайте новый файл .gitlab-ci.yml в корневом каталоге проекта.
  3. Зафиксируйте файл .gitlab-ci.yml
  4. В CI/CD проекта вы можете увидеть работу CI/CD

Пример файла .gitlab-ci.yml

image: node
# 定义 stages
stages:
  - build
  - test
# 定义 job
 build 阶段:
  stage: build
  script:
    - echo "build stage"
# 定义 job
发布到测试环境:
  stage: test
  script:
    - echo "test stage"

3. Доступ нового проекта к процессу GitLab CI/CD

Если у команды есть новый проект, который необходимо подключить к GitLab CI/CD, сначала подайте заявку на проект GitLab, а затем попросите сопровождающего системы GitLab помочь настроить Runner, написать файл .gitlab-ci.yml и запустить сборку, чтобы увидеть ситуацию с CI/CD.

  1. Создайте новый проект GitLab
  2. Настроить GitLab Runner
  3. Файл .gitlab-ci.yml

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

4. Практика GitLab CI/CD

В практической части здесь представлены GitLab Runner и файл .gitlab-ci.yml Основные процессы, проблемы и решения, которые встречаются, включены в процесс введения файла .gitlab-ci.yml.

1. GitLab Runner

GitLab Runner обычно управляется системным мейнтейнером GitLab.После настройки похожие проекты могут быть общими и, как правило, их не нужно изменять. Здесь не дается никакого специального введения, но в основном представлены моменты, на которые следует обратить внимание во время использования.Документация по GitLab Runner.

1.1 Процесс использования GitLab Runner

  1. Скачать GitLab Runner
  2. Зарегистрируйтесь в GitLab Runner
  3. Использование GitLab Runner

1.2 Примечания к GitLab Runner

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

1.2.1 После настройки Runner отправьте код и запустите конвейер, но он находился в состоянии Pending

Сообщение об ошибке: Это задание зависло, потому что у вас нет активных исполнителей, которые могли бы запустить это задание.

Зарегистрированные исполнители по умолчанию не будут использовать задания без тегов.Вы можете перейти в «Настройки» → «CI/CD» → «Настройки исполнителей» и удалить задания бегунов без тегов.

1.2.2 Типы исполнителей GitLab

Существует три типа исполнителей. Общие исполнители можно использовать во всех проектах во всей системе. После регистрации групповых исполнителей различные базы кода в рамках одного проекта становятся общими. Конкретные исполнители необходимо настраивать отдельно для проекта. Бегуны, обратите внимание, нужно ли закрывать Shared Runners и Group Runners.

  • Shared Runners
  • Specific Runners
  • Group Runners
1.2.3 Использование докера в GitLab CI

При развертывании в Alibaba Cloud вам необходимо использовать докер для публикации образов в GitLab CI/CD. может относиться кBuilding Docker images with GitLab CI/CD

1.2.4 Доступ к каталогу хоста Runner в GitLab CI/CD

Используемый нами исполнитель Runner — Dokcer, а каталоги, к которым необходимо получить доступ, настраиваются в томах Dokcer.

2. Файл .gitlab-ci.yml

Файл .gitlab-ci.yml активного проекта выглядит следующим образом. Ниже в основном представлен наш практический процесс и подробное использование .gitlab-ci.yml через файл .gitlab-ci.yml активного проекта. кСправочная документация по настройке конвейера GitLab CI/CD

2.1 Знакомство с файлом .gitlab-ci.yml

imageБазовый образ Docker, реализующий зависимости CI/CD. В зеркале есть Node, Yarn, Dalp (внутренний инструмент rsync).

stagesОпределенный в нашем пайплайне разделяется на следующие процессы:

  1. Загрузить этап pre_build зависимостей
  2. сборка фазы сборки
  3. этап выпуска

stageОбъявить текущий этап, используемый в этапах

variablesиспользуется для определения переменных

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

scriptОперация, которую необходимо выполнить на текущем этапе

changesУкажите условия запуска этапа

refsУкажите ветку, запускаемую стадией

image: registry.huajiao.com/gitlab-ci/node-yarn:v1.4

variables:
  # $CI_PROJECT_PATH  ： 项目id,用于项目唯一区分本项目与其它项目
  # $CI_PROJECT_DIR   ： 本地项目路径
  # $PROCESS_PATH     ： 临时文件目录(包括日志和一些临时文件)
  NODE_MODULES_PATH: /runner-cache/frontend/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME/node_modules

stages:
  - pre_build
  - build
  - deploy

下载依赖:
  before_script:
    # 无 node_modules 文件时，新建 node_modules 文件
    - /bin/bash ./ci/mkdir.sh $NODE_MODULES_PATH
    # 软链 node_modules 到宿主机
    - ln -s $NODE_MODULES_PATH .
    - cd webpack@next
  stage: pre_build
  script:
    - echo "yarn install"
    - yarn install  --network-timeout 60000
  only:
    changes:
      - webpack@next/package.json
    refs:
      - test
      - test-99
      - test-128
      - master
      - ci
      - feature/ci-test

构建:
  stage: build
  variables:
    CI_COMMIT_BEFORE_SHA_PATH: /mnt/gv0/gitlab-runner-cache/$CI_PROJECT_PATH
    CI_COMMIT_BEFORE_SHA_FILE_NAME: $CI_BUILD_REF_NAME.sh
    CI_COMMIT_BEFORE_SHA_FILE: /mnt/gv0/gitlab-runner-cache/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME.sh
  before_script:
    # 建存此次 CI CI_COMMIT_SHA 的文件
    - /bin/bash ./ci/mkfile.sh $CI_COMMIT_BEFORE_SHA_PATH $CI_COMMIT_BEFORE_SHA_FILE_NAME
    # 软链 node_modules 到宿主机
    - ln -s $NODE_MODULES_PATH .
    - rm -rf php/share/*
    - cd webpack@next
  script:
    # 缓存上次ci
    - source $CI_COMMIT_BEFORE_SHA_FILE
    - echo "CI_COMMIT_BEFORE_SHA=$CI_COMMIT_SHA" > $CI_COMMIT_BEFORE_SHA_FILE
    - python3 ../ci/build.py   # 编译
    - /bin/bash ../ci/commit.sh   # 提交编译结果
  only:
    changes:
      - www_src/**/*
    refs:
      - test
      - test-99
      - test-128
      - master
      - ci


测试发布:
  stage: deploy
  variables:
    PROCESS_PATH: /mnt/gv0/gitlab-runner-cache/deploy/process/$CI_JOB_ID  # 目录不要换，用于日志服务器获取日志展示
  script:
    - mkdir $PROCESS_PATH # 建立发布临时路径，存放发布配置中间文件和结果日志用
    - dplt $CI_PROJECT_DIR/.deploy_test.yml $CI_PROJECT_PATH $CI_PROJECT_DIR/php/ $PROCESS_PATH
    # dplt 发布yml配置
    - echo "发布完成，错误日志查看http://new.admin.wolffy.qihoo.net/log?path="$PROCESS_PATH
    - echo `ls $PROCESS_PATH/*.log`
  only:
    changes:
      - php/**/*
    refs:
      - test

2.2 Этап загрузки зависимостей (этап pre_build)

Решение для загрузки зависимостей: при изменении файла package.json запустить этап pre_build и выполнить установку пряжи. Загруженные node_modules размещаются под хостом, а зависимости получаются через мягкую цепочку во время выполнения.

2.3 Этап сборки

Фаза сборки, разделенная на 3 части

  1. изменения файла различий
  2. интерфейсная сборка
  3. Результаты после фиксации сборки

2.3.1 изменения файлов различий

Для каждого ЭК сохраните текущий SHA фиксации ЭК (переменная CI_COMMIT_SHA) в файле как переменную CI_COMMIT_BEFORE_SHA.При сравнении git diff сравнит изменения между текущим ЭК и SHA последней фиксации.

2.3.2 Интерфейсная сборка

По изменениям git diff определите проект, который нужно запаковать на этот раз.

2.3.3 HTML-файл, сгенерированный после упаковки фиксации

При отправке кода в GitLab CI/CD используйте хранилище учетных данных Git для отправки упакованного HTML-файла. Подробнее о хранилище учетных данных Git см.Документация по хранилищу учетных данных

2.4 Этап развертывания

На этапе публикации используйте внутренний инструмент rsync dplt для развертывания упакованного HTML-файла. dplt может настроить кластер, список машин.

V. Текущие проблемы и будущие направления

  1. Для непрерывной интеграции, несмотря на автоматическую сборку и выпуск, ключевая ссылка для тестирования отсутствует.
  2. С помощью GitLab CI/CD мы добились согласованности онлайн-среды, но локальная среда разработки и онлайн-среда по-прежнему несовместимы, локально проблем может не быть, но могут быть проблемы онлайн.
  3. После перехода с SVN на разработку Git стратегии управления ветвями, соглашения об именах ветвей, спецификации сообщений коммитов, CodeReview и т. д. должны быть стандартизированы шаг за шагом в команде.

6. Основные справочные материалы

Что такое непрерывная интеграция?

Что такое CI/CD?

GitLab Docs

Introduction to CI/CD with GitLab

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

Как реализовать непрерывную интеграцию и непрерывное развертывание интерфейсной разработки?

Практика фронтенд-инжиниринга CI/CD на базе GitLab CI

Категории