Эта статья о сценарии развертывания фронта, через инструменты Gitlab-CI.

Я использую GitLab-CI, а носителем исполнения скриптов GitLab Runner (об этом позже) пусть будет простой дроплет от DO

GitLab

GitLab — это онлайн-хранилище кода, основанное на Git, аналогичной GitHub. Обычно оно используется для создания частных серверов Git во внутренних сетях, таких как предприятия и школы.

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

Что такое хорошая непрерывная интеграция, можно посмотреть на Вики.

.gitlab-ci.yml

Это файл в корневом каталоге проекта Git, в котором записан ряд этапов и правил выполнения. GitLab-CI проанализирует его после пуша и вызовет Gitlab-runner(а) для запуска в соответствии с его содержимым.

Проще говоря, вы используете Git для отправки локального кода в Remote (здесь ваш gitlab.com), а затем Gitlab уведомит ваш сервер, который является Gitlab-runner, чтобы запустить задачу сборки.

Установить Gitlab Runner:

Например в Ubuntu
Скачать

curl -LJO https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb

Установить

dpkg -i gitlab-runner_amd64.deb

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

Зарегистрируйте Runner в системе Ubuntu:

Запустите следующую команду, чтобы начать процесс регистрации:

sudo gitlab-runner register

Введите URL-адрес экземпляра GitLab:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.xxx.com

Введите полученный токен для регистрации Runner:

Please enter the gitlab-ci token for this runner
xxx

Задайте название Ранеру

Please enter the gitlab-ci description for this runner
[hostname] my-runner

Запрос на установку тэга, оставьте пустым!

Please enter the gitlab-ci tags for this runner (comma separated):
my-tag,another-tag

Выберите исполнителя Runner:

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker
// Мой выбор Docker, пожалуйста, помните, что вы должны установить Docker, а установка Docker не рассматривается в этой статье.

Если вы выберете Docker в качестве исполнителя, программа регистрации позволит вам установить образы по умолчанию для проектов, которые вы укажите в .gitlab-ci.yml:

Please enter the Docker image (eg. ruby:2.6):
alpine:latest

Маленькая зеленая точка указывает на то, что вы успешно зарегистрировались.
Не переживайте, если у вас не так. Устанавливайте Docker и возвращайтесь к статье.

Конфигурация .gitlab-ci.yml

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

Pipeline

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

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+

Stages

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

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

Схематически, отношения между этапами и конвейером:

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+

Jobs

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

Задания на одном и том же этапе выполняются параллельно
Этап будет успешным, только если задания на той же стадии успешно выполнены
Если какое-либо задание не выполняется, происходит сбой этапа, т.е. Происходит сбой задания сборки (конвейер)

Итак, отношения между Jobs и Stage таковы:

+------------------------------------------+
|                                          |
|  Stage 1                                 |
|                                          |
|  +---------+  +---------+  +---------+   |
|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+

Давайте поговорим о некоторых базовых структурах .gitlab-ci.yml

Вот самый простой сценарий развертывания для проекта Node.

image: node:alpine  // Образ Docker для развертывания ci по умолчанию

stages:  // Сначала нужно определить несколько шагов. Все задания выполняются синхронно
  - test  
  - build

job1:
  stage: test  // Принадлежит к стадии теста
  script:
    - npm run test // Сценарий, выполняемый этой работой
  only:
    - master  // Слушайте только коммиты кода из ветки master
  tags:
    - marat  // Какой Runner использовать (опционально, выше я просил оставьте пустым.)

job2:
  stage: build
  script:
    - npm run build
  only:
    - master
  tags:
    - marat

Обратите внимание, что имена job1 и job2 являются произвольными, это не имеет значения, но не используете ключевые слова Gitlab-CI:

ключевое слово — Описание

image — Используется для инжекта Docker образов
services — Используется для службы докеров
stage — Определить этап сборки
before_script — Определите команду для запуска перед каждым заданием
after_script — Определите команду для запуска после каждого задания
variable — Определить переменные сборки
cache — Определяет список файлов, которые могут быть использованы в последующих запусках

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

Скачаем Vue3

git clone https://github.com/vuejs/vue-next-webpack-preview.git vue3
cd vue3
npm install
npm run dev

Действительно очень простой проект :)
Он генерируется с помощью webpack и затем ~~публикуется в указанном каталоге на сервере. Конфигурация nginx на сервере уже настроена.~~ по-хипстерски, разместим на https://surge.sh/

image: node:alpine

stages:
  - build
  - deploy

cache:
  paths:
  -  node_modules/

build process:
  stage: build
  script:
    - npm install --progress=false
    - npm run build
  artifacts:
    expire_in: 1 week
    paths:
      - dist

deploy to surge:
  stage: deploy
  script:
    - npx surge --project ./dist --domain xxx.surge.sh

Первая попытка gitlab-ci на фронте