Gitlab CI — автоматизированная сборка и оптимизация внешнего интерфейса

GitLab
Gitlab CI — автоматизированная сборка и оптимизация внешнего интерфейса

Теперь, когда появляется все больше и больше трюков с внешним интерфейсом, то, о чем я собираюсь рассказать сегодня, не является чем-то новым. как Дженкинс. Тем не менее, также было упомянуто, что как фронтенд, особенно бизнес-разработка, я обычно редко касаюсь этих вещей. Еще автор недавно планировал автоматически развернуть контейнер на фронтенде, а потом изучил и посмотрел, а потом поделился со всеми процессом обучения и небольшим резюме.

Цель моей статьи - обобщить обходные пути, через которые я прошел всем, дабы вы не наступили на яму, а я не хочу, чтобы она вам нравилась, просто меньше брызгайте. Потому что я действительно испытал много сценариев "миллионы статей, практика закончилась", и все не отвечают перед читателями, поэтому в моих статьях в основном есть код и демо-примеры, которые не могут быть лучшими, но, по крайней мере, если вы столкнулся с той же проблемой, определенно решил ее ~

передний

  • Gitlab
  • Gitlab Runner
  • Docker

Вышеупомянутое является предварительным условием, не говоря уже о Gitlab.Как правило, компании используют хранилища Gitlab для внутренних целей, Gitlab Runner обычно требует дополнительной установки, а предварительно написанный скрипт для автоматической сборки и развертывания (который будет представлен позже) запускается им. Наконец, проект необходимо упаковать в образ и развернуть в контейнере, поэтому также требуется Docker.

Поскольку это внутренний процесс компании, а не игра в одиночку, достаточно позволить эксплуатации и обслуживанию сделать это за вас.В эту эпоху это должно быть доступно по умолчанию в компании. Личные проекты могут быть размещены на Github с большой вероятностью.Друзья могут выбрать Github Actions.В Интернете есть много обучающих программ.

создать новый проект

кcreate-react-appВ качестве краткого примера автоматизируйте развертывание сборки, а затем создайте страницы Gitlab. Сначала мы создаем новый проект и отправляем его на удаленный склад:

.gitlab-ci.yml — инициализация

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

# 定义阶段 stages
stages:
  - build
  - deploy

# 定义 job - build 项目
job1 - build 阶段:
  # 开始之前需要安装依赖
  stage: build
  script:
    - echo "finish build stage"

# 定义 job
job2 - 发布到线上环境:
  stage: deploy
  script:
    - echo "finish deploy stage"

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

Нажмите файл вверх, чтобы увидеть эффект:

Как видно из рисунка, он успешно проталкивается на пульт, а затем нажимается:CI/CD -> pipelines

Как видно из рисунка выше, автоматизированное построение проекта завершено, спросите вы, так ли это просто? На самом деле это так просто.Хотя я упростил содержание построения до двух строк вывода, общий процесс на самом деле тот же.Это не что иное, как усложнение процесса построения и добавление содержимого сценария. Затем используйте этот пример, чтобы шаг за шагом узнать больше о Gitlab CI.

Анализ концепций, связанных с YAML, в Gitlab

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

Официальная документация здесь, Я просто проверяю официальные документы, вы также можете перейти в «Словарь Youdao» для перевода.

ключевые слова Reqired описывать
image нет Использование образов Docker
service нет Использовать докер-сервис
stages нет Определение этапов сборки
types нет псевдоним этапов (рекомендуется использовать только этапы, устарело)
before_script нет каждыйСценарий, который нужно выполнить перед выполнением задачи сценария
after_script нет каждыйСкрипт, который будет выполняться после выполнения задачи скрипта
variables нет Определите переменные, которые можно использовать на этапе сборки
cache нет Определите файл кеша, который можно использовать на более поздних этапах.

job

jobда.gitlab-ci.ymlЭто элемент верхнего уровня в , и он должен быть в любом автоматизированном развертывании.Я лично думаю, что его можно разделить на задачи, и каждая задача содержит как минимум один скрипт, указывающий, что делать в этой задаче. Можно определить несколькоjobи каждыйjobМежду всеми независимыми друг от друга,jobБудетGitlab RunnerВыполняйте в своей среде.

# 定义 job1
job1:
  script: 
    - echo "i'm job1"
# 定义 job2
job2:
  script: 
    - echo "i'm job2"

Выше приведен самый простой пример, определяющий дваjob, каждый со скриптом, который выводит строку.

【Примечание】: Как упоминалось ранее,jobэто элемент верхнего уровня, и он имеет широкое название,${string}:Строка + точка с запятой (не ограничивается китайским и английским языками), но ключевые слова, упомянутые в таблице выше, не могут быть определены какjob名из.

image && services

Поскольку Gitlab Runner также построен с использованием Docker, мы также можем использовать соответствующий образ для базовой конструкции при создании нашего кода. Соответствующее полеimageа такжеservices, давайте посмотрим на простой пример, приведенный чиновником:

# 基础镜像
image: ruby:2.1
# 使用镜像 service - postgres
services:
  - postgres

Далее мы рассмотрим наш собственный проект, мыcreate-react-appПостроенный проект, поэтому зависимости должны бытьnodeЗеркало, сервис прописывать не нужно, т.к. это опционально.

# 依赖镜像 node
image: node:10.16.0
# 定义阶段 stages
stages:
  - build
  - deploy

# 定义 job - build 项目
job1 - build 阶段:
  # 开始之前需要安装依赖
  stage: build
  script:
    - echo "finish build stage"

# 定义 job
job2 - 发布到线上环境:
  stage: deploy
  script:
    - echo "finish deploy stage"

Выше мы добавили зеркальные зависимости, и указан номер версииv10.16.0.

stages

Это направление тоже очень важное, я думаю, его можно перевести в этап строительства, например, наш проект разбит на два этапа, первый этап —build— Компилируем и упаковываем, второй этапdeploy— Выпущено онлайн. По сути, это соответствует двум работам, а затем более подробное описание каждого этапа дается ниже.

stagesНесколько этапов определения поля идут в одном порядке в процессе строительства трубопроводов и имеют следующие правила:

  • Предыдущий этап завершен, выполняется следующий этап

То есть развертывание будет выполнено после успешной сборки.

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

Конкретный процесс реализации можно найти вpipelinesПроверьте это, как показано на рисунке ниже

script

Это также самое важное поле. Оно представляет собой сценарий оболочки, выполняемый Gitlab Runner.В процессе сборки проекта необходимо выполнить множество команд, таких как команды для установки зависимостей, упаковки и развертывания. На примере нашего проекта добавлено новое изображение узла, а значит, его можно выполнитьnpm installа такжеnpm run buildЖдать заказа.

# 依赖镜像
image: node:10.16.0

# 定义阶段 stages
stages:
  - build
  - deploy

# 定义 job - build 项目
job1 - build 阶段:
  # 开始之前需要安装依赖
  stage: build
  script:
    - yarn install
    - yarn build
    - echo "finish build stage"

# 定义 job
job2 - 发布到线上环境:
  stage: deploy
  script:
    - echo "finish deploy stage"

Выше мы добавили две новые команды в job1yarn installа такжеyarn buildТе, кто знаком с фронтенд-разработкой, должны знать эти две команды.Перед созданием проекта зависимости должны быть установлены, упакованы и скомпилированы. Затем нажмите на удаленный склад, чтобы увидеть эффект:

  • Сборка выполнена

  • Создайте контент для первого шага

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

до_скрипта и после_скрипта

Значение этих двух полей такое же, как и буквальное значение.before_script— скрипт выполняется до выполнения скрипта,after_script— Скрипт, который будет выполняться после выполнения скрипта.

Некоторые здесь могут сказать, а затем поставитьyarn installЗависимая команда скрипта помещается вbefore_scriptНе было бы более уместно, чтобы фаза сборки выполняла только команду сборки, что более уместно. Ответ — нет, потому что эти две команды находятся во внешнем слое, а это значит, что они выполняются один раз перед каждым этапом, то есть каждое задание будет выполняться первымbefore_scriptЗатем выполняем сценарий сценария, определенный вами, и фактически мыyarn installНужно выполнить только один раз.

Думал-думал найти лучшую сцену для демонстрации, но чувствую, что использованных сцен действительно мало и не очень уместно.Конечно, если это просто для понимания функции, то выводить строку.Вот думаю отечественные допустимыеbefore_scriptПеред установкой Taobao зеркало.

# 依赖镜像
image: node:10.16.0


before_script:
  - echo "======== before script ========"
  - npm config set registry https://registry.npm.taobao.org

after_script:
  - echo "======== after script ========"

# 定义阶段 stages
stages:
  - build
  - deploy

# 定义 job - build 项目
job1 - build 阶段:
  # 开始之前需要安装依赖
  stage: build
  script:
    - yarn install
    - yarn build
    - echo "finish build stage"

# 定义 job
job2 - 发布到线上环境:
  stage: deploy
  script:
    - echo "finish deploy stage"

Посмотрим на эффект:

  • этап сборки

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

Вы можете видеть, что действительно, как описано, эти два скрипта выполняются на каждом этапе сборки - stage.

only && except

Следующие два ключевых слова также очень важны, давайте рассмотрим пример:

  • Первый шаг — создать новую ветку:branch-a
  • Второй шаг — отправить измененный контент на удаленный сервер.

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

  • only: разрешены только подходящие сборки триггеров.
  • кроме: сборки запускаются за исключением чего-то

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

# 依赖镜像
image: node:10.16.0

before_script:
  - echo "======== before script ========"
  - npm config set registry https://registry.npm.taobao.org

after_script:
  - echo "======== after script ========"

# 定义阶段 stages
stages:
  - build
  - deploy

# 定义 job - build 项目
job1 - build 阶段:
  # 开始之前需要安装依赖
  stage: build
  script:
    - yarn install
    - yarn build
    - echo "finish build stage"
  only:
    - master

# 定义 job
job2 - 发布到线上环境:
  stage: deploy
  script:
    - echo "finish deploy stage"
  only:
    - master

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

Нажатие кода вверх больше не будет запускать автоматическую сборку. Давайте проверим это еще раз.branch-aВетвь упоминает MR, а затем объединяет его с мастером, чтобы увидеть эффект.

  • Merge Request

  • Merge && CI

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

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

variables

Как следует из названия, это переменная. Мы можем предопределить некоторые часто используемые переменные и использовать их в сценарии работы. Простой пример:

variables:
    DOCKER_HUB_URL: "https://custom.dockerhub.com"
    
# 定义 job - build 项目
job1-build:
  # 开始之前需要安装依赖
  stage: build
  script:
    - yarn install
    - yarn build
    - echo $DOCKER_HUB_URL
    - echo "finish build stage"

Помимо пользовательских переменных, в системе также есть множество встроенных констант:Подробности здесь

artifacts

Этот параметр также является очень важной частью.Его функция заключается в передаче файлов или папок в списке сборки другим заданиям (не обязательно следующему заданию) после успешного построения текущего задания.Передача содержимого файла между заданиями.

Почему это важно? Давайте сначала рассмотрим пример. Мы добавляем новую команду в job2 для просмотра текущего каталога сборки:

# 定义 job
job2 - 发布到线上环境:
  stage: deploy
  script:
    - ls
    - echo "finish deploy stage"
  only:
    - master

Результат выглядит следующим образом:

Найдем проблему, контент в мастере склада все равно получается в job2, что это значит, если вы знаете React, то должны знать,create-react-appПосле упаковки,/buildПапка, содержимое этой папки, как правило, является конечным онлайн-контентом. Но мы явно строим job1, а билд job1 проходит успешно, то есть нам нужно поставить папку после билда job1 успешно/buildПерешел к job2, так что он также используется в это времяartifacts.

# 依赖镜像
image: node:10.16.0

before_script:
  - echo "======== before script ========"
  - npm config set registry https://registry.npm.taobao.org

after_script:
  - echo "======== after script ========"

# 定义阶段 stages
stages:
  - build
  - deploy

# 定义 job - build 项目
job1-build:
  # 开始之前需要安装依赖
  stage: build
  script:
    - yarn install
    - yarn build
    - echo "finish build stage"
  only:
    - master
  artifacts:
    paths:
        - build/

# 定义 job
job2-deploy:
  stage: deploy
  script:
    - ls
    - echo "finish deploy stage"
  only:
    - master
  dependencies:
    - job1-build
  • job1-build

Вакансия1 добавленаartifactsвнутренние настройкиpaths: build/папка.

  • job2-deploy

Работа2 новаяdependencies: job1-build, что указывает на то, что эта работа зависит отjob1-buildПрошло болееartifactsсодержание.

Эффект удаленного просмотра:

Как видно из рисунка выше, job2 уже может получить сгенерированное job1 после успешного построения/buildпапка.

.gitlab-ci.yml

Окончательный файл конфигурации выглядит так:

# 依赖镜像
image: node:10.16.0

before_script:
  - echo "======== before script ========"
  - npm config set registry https://registry.npm.taobao.org

after_script:
  - echo "======== after script ========"

# 定义阶段 stages
stages:
  - build
  - deploy

# 定义 job - build 项目
job1-build:
  # 开始之前需要安装依赖
  stage: build
  script:
    - yarn install
    - yarn build
    - echo "finish build stage"
  only:
    - master
  artifacts:
    paths:
        - build/

# 定义 job
job2-deploy:
  stage: deploy
  script:
    - ls
    #######
    # 这里可以对项目进行真实的发布
    #######
    - echo "finish deploy stage"
  only:
    - master
  dependencies:
    - job1-build

На самом деле реальное автоматизированное построение и развертывание происходит онлайн.job2-deployЗатем добавьте более сложный скрипт, как я должен сделать, это отправить зеркальный пакет docker docker hub, а затем развернуть проект с помощью k8s. Конечно, вы также можете увеличить этап и работу, конкретные детали каждого человека в каждой компании разные, мы можем изменить.

Принципы системы процессов строительства проекта

После введения интерфейсный интерфейс может в основном использовать пользовательский интерфейс Gitlab для простого автоматического развертывания и онлайн, но его необходимо стандартизировать, когда компания разрабатывает с несколькими людьми.Ниже приведен мой пример.личный(Личное мнение, не распыляйте, если не нравится) Я думаю, что это более стандартизированный и разумный процесс.

  • Разрабатывайте проекты параллельно, каждый раз, когда главная ветка выходит в онлайн
  • Разработать новую ветку на основе основной ветки (одиночная и многопользовательская)
  • Ветка разработана и готова к запуску в сеть, мерж-реквест, после код-ревью не проблема, мастера проведут слияние с мастером
  • Смена основной ветки запускает автоматическую сборку и развертывание Gitlab CI (откат при сбое онлайн также запускается автоматически)

Поэтому конфигурация проекта Gitlab должна быть следующей:

  • Основная ветка добавляется.gitlab-ci.ymlПосле настройки push не разрешен
  • Ветка master может быть объединена только администратором через запрос на слияние.

Связанные оптимизации

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

  • npm -> yarn

В этом можно не сомневаться, все больше и больше проектов в опыте фронтенд-разработки ушли отnpm -> yarn, скорость установки пряжи и использование кеша действительно больше подходят для CI.

  • настройки зеркального источника
# 将镜像源设置成淘宝镜像
- yarn config set registry 'https://registry.npm.taobao.org'
# 如果你用到了 node-sass，比较特别，因为它经常安装失败，稳妥起见重新设置一下
- yarn config set sass_binary_site 'https://npm.taobao.org/mirrors/node-sass/'
  • использоватьgitlab-ciизcache 

cache:
  key: your-project-name
  paths:
    - $(pwd)/.yarn-cache
    - node_modules/

и команда установки становится- yarn install --pure-lockfile --cache-folder $(pwd)/.yarn-cache

Благодаря следующей конфигурации пакет зависимостей будет кэшироваться при сборке, чтобы следующая установка была быстрее ~

Вот несколько оптимизированных скриншотов:

  • При использовании npm: 278 с

  • Перейти на пряжу: 196 с.

  • Увеличение кеша: 1 с

Конечно, 1 здесь относится к ситуации, когда наши зависимости не изменились, если они изменились, их нужно переустановить. Но в целом ускорение очень большое.

Суммировать

Очень простая статья, просто чтобы дать каждому простое представление о построении автоматизации интерфейса, а также некоторые личные выводы. более глубокий уровень, напримерGitlab Runnerи собственно проектDockerРазвертывание варьируется от человека к человеку, и не все используют Docker для развертывания внешнего интерфейса, поэтому я не стал слишком подробно его представлять.

Категории