CI/CDЭто полный набор решений для непрерывной интеграции и непрерывной доставки, предоставляемых Gitlab.

Понятия: «Непрерывная интеграция (Continuous Integration)», «Непрерывная доставка (Continuous Delivery)» и «Непрерывное развертывание (Continuous Deployment)», понимание понятия подробно изложено в статье:Простое понимание непрерывной интеграции, непрерывной доставки, непрерывного развертыванияа такжеРасскажите о разнице между непрерывной интеграцией, непрерывной доставкой и непрерывным развертыванием.

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

Конфигурация CI для GitLab

Предварительное условие: развертывание сервера настроено с помощью Runner .Как показано на рисунке, я сделал共享型的 Runner, более десятка фронтенд-проектов могут выполнять CI-скрипты на основе этого Runner. Поскольку Runners являются общими, поэтомуgitlab-ci.ymlОбраз докера в образе рекомендуется для обеспечения несогласованности каждого проекта, чтобы один Runner можно было использовать вместе для параллельного выполнения нескольких проектов CI, по сути выполняя сценарии в разных образах докера, чтобы не было конфликтов. Бегун:gitlab-runner

Ниже приведен пример разработки интерфейса Angular, реализованной в Gitlab.CIScript, в настоящее время выполняет только проверку кода и автоматическое определение процесса сборки. Автоматически проверять, является ли код стандартизированным, а внешний интерфейс ограничивает некоторые代码拼写规范、console.log禁用、alert禁用Ждатьограничения tslint, это могут быть настроенные правила обслуживания под проект. Сборка aot предназначена для дальнейшей проверки некоторых проблем компиляции. Пока оба проходят успешно, сборки Jenkins на 100% безошибочны.

Конфигурация:

# GitLab CI/CD 前端 Angular 持续集成实践 : https://github.com/giscafer/front-end-manual/issues/27
# 因为共享Runner，这里不建议一样的版本号，避免同时运行的时候，相同docker镜像会出问题
image: node:latest
# image: node:10.4.1

# 变量定义
# https://docs.gitlab.com/ee/ci/variables/#using-predefined-environment-variables
variables:
  NODE_MODULES_VERSION: 'ng-starter-web-1.0.0' # node_modules版本号，每次升级依赖改一下这里的数值
  CURRENT_BRANCH: $CI_COMMIT_REF_NAME

# 缓存目录文件
# key是唯一值，重名会覆盖上一次的缓存
cache:
  key: '$NODE_MODULES_VERSION'
  paths:
    - node_modules/

stages:
  - init
  - lint
  - build
  # - deploy

install_packages:
  stage: init
  cache:
    key: '$NODE_MODULES_VERSION'
    paths:
      - node_modules/
  script:
    # 打印一下当前是什么分支而已
    - echo "NODE_MODULES_VERSION=$NODE_MODULES_VERSION"
    - echo "CURRENT_BRANCH=$CURRENT_BRANCH"
    # 设置 npm 的源，会快一些
    - npm config set registry http://registry.npm.taobao.org/
    # 安装所有依赖，也就是 node_modules
    - npm install --silent

lint_code:
  stage: lint
  # 定义缓存
  cache:
    key: '$NODE_MODULES_VERSION'
    # 下面的配置指示，我们当前只拉取缓存，不上传，这样会节省不少时间
    policy: pull
    # 指定要缓存的文件/文件夹
    paths:
      - node_modules/
  script:
    - npm run lint
  only:
    - /^dev.*$/ # dev分支下只做lint语法检查

build:
  stage: build
  cache:
    key: '$NODE_MODULES_VERSION'
    policy: pull
    paths:
      - node_modules/
  script: npm run aot:test
  # artifacets 是打包你指定的文件或者文件夹，然后你可以通过 gitlab 的页面进行下载的
  artifacts:
    # artifacets 的名字
    name: '$CI_COMMIT_REF_NAME-dist'
    # artifacets 的过期时间，因为这些数据都是直接保存在 Gitlab 机器上的，过于久远的资源就可以删除掉了
    expire_in: 60 mins
    # 制定需要打包的目录，这里我把 dist 目录给打包了，准备发布到服务器
    paths:
      - dist/
  only:
    - master
#
##  部署任务
# deploy:
#   stage: deploy
#   # 该命令指定只有 master 分支才能够执行当前任务
#   only:
#     - master
#   # 部署脚本，在下面的代码中，我用到了很多类似 ${AMAZON_PEM} 的变量，由于我们的私钥、Ip 都算是不宜公开显示的信息，
#   # 所以我用到了 Gitlab 的变量工具，在 repo 的 Setting > CI/CD > Secret variables 中，这些变量值只有项目管理员才有权限访问
#   script:
#     - 'ls -la'
#     - 'ls -Rl dist'
#     - 'echo "${AMAZON_PEM}" > amazon.pem'
#     - 'chmod 600 amazon.pem'
#     - 'scp -o StrictHostKeyChecking=no -i amazon.pem -r dist/* ${AMAZON_NAME_IP}:/usr/share/nginx/html/'

Angular gitlab-ci.ymlКонфигурация также может относиться к:stackoverflow.com/questions/4…

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

Переменнаяvariables

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

build:
  stage: build
  script:
    - |
      if [ "$CI_COMMIT_REF_NAME" = "$ci_defined_secret_variable_deploy_branch" ]; then
        echo "build ran and conditional was true"
      fi
  except:
    - master

stagetwo:
  stage: deploy
  script:
    - |
      echo "stage two ran"
  only:
    variables:
      - $CI_COMMIT_REF_NAME == $ci_defined_secret_variable_deploy_branch

На следующем рисунке показана конфигурация сборки в рамках проекта.

этапы этапы

Определить этап, этап может быть просто понят как "шаг", который будет выполняться последовательно. Если предыдущий шаг неверен, он не будет продолжать выполнять следующий шаг. Например, как определено выше, первый шаг будет выполнен первым .lintПроверьте спецификацию кода, второй шаг сборки. Полное разделение этапов должно быть:第一步先初始化，第二步检查代码规范，第三步进行单元测试，第四步构建，第五步就直接将项目部署到服务器

кеш-кэш

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

Определите глобальную стратегию кэширования, как упоминалось выше, для каждой отдельнойstage, CI перезапустит новый контейнер, поэтому мы ранееstageФайлы в пропадут, во front-end разработке, это значит, что каждыйstageнужно переустановитьnode_modules, на этот раз затраты времени и сети не малы, поэтому мы решили кэшировать эти файлы.

Однако кеш также должен быть практичным: например, если я добавлю библиотеку во вторую отправку, второй ЭК не сможет повторно использовать предыдущий.node_modulesКэш, внутри.gitlab-ci.ymlВ середине мы установленыcacheизkeyЧтобы различать разные кеши, как видно из конфигурации, через пользовательские переменныеNODE_MODULES_VERSIONидентифицироватьnode_modulesверсию, решить, загружать ли новые зависимости, и поддерживать это каждый раз, когда проект изменяет версию зависимости или добавляет модульNODE_MODULES_VERSIONНомер версии в порядке. Номер версии NODE_MODULES_VERSION может быть автоматически изменен сценарием путем отслеживания обновления версии файла package.json. Например, сценарий:compare-pk.js

# 变量定义
# https://docs.gitlab.com/ee/ci/variables/#using-predefined-environment-variables
variables:
  NODE_MODULES_VERSION: 'ng-starter-web-1.0.0' # node_modules版本号，每次升级依赖改一下这里的数值
  CURRENT_BRANCH: $CI_COMMIT_REF_NAME

Задача Работа

остальноеJobЧтобы определить сценарий, вышеперечисленные вещи предназначены дляJobиспользовать. Подробности в следующем примере:

# 这个是某个任务的名称，你可以随意起名
install_packages:
  # 指定该任务所属的步骤，每到一个步骤，该步骤所对应的所有任务都会并行执行
  stage: init
  # 指定要缓存的文件以及文件夹
  cache:
    # 这个属性是 gitlab 比较新版本里面加的特性，意思是在这一步，我只上传这个缓存，我不会拉取该缓存
    policy: push
    # 指定缓存的内容，在下面我缓存了 node_modules 这个文件夹，你还可以在下面继续添加文件或者文件夹
    paths:
      - node_modules/
  # 该任务要运行的脚本，顺序执行
  # 都是 bash 命令
  # 默认当前目录就是 repo 的根目录
  script:
    # 打印一下当前是什么分支而已
    - echo "CURRENT_BRANCH=$CURRENT_BRANCH"
    # 设置 npm 的源，会快一些
    - 'npm config set registry "https://registry.npm.taobao.org"'
    # 安装所有依赖，也就是 node_modules
    - "npm install"

Кэшированное и некешированное сравнение скорости CI

Проверка на ворсинки без кеша занимает около 8 минут.

С кешем это занимает около полутора минут

Для получения дополнительной информации об элементах конфигурации см. официальную документациюyaml/README

отделение развития

PR: запрос на слияние или запрос на слияние

за фиксацию илиPRавтоматически сработаетjob:lint,PRВ случае линта кода или провала теста его нельзя слить по умолчанию (кнопка отключена, и пользователи с высокими правами могут пропустить проверку, но это не рекомендуется, если вы не хотите наделать ошибок).

Более удобно,PRОн может быть установлен для автоматического слияния после принятия выполнения скрипта, конечно, при необходимостиCR （code review）Если это так, его можно настроить для слияния вручную. Если код даже не проходит тест, он не нуженCR.

главная ветвь

Вы можете выполнять непрерывную доставку (CD) в ветке master, в основном для автоматизации сборки; вы можете развернуть успешный результат сборки через скрипт. Если есть более поздний автоматизированный тест интерфейса или компонента, тест будет выполнен после развертывания, и если он не пройден, будет выполнен откат. Само собой разумеется, что успешно протестированный код, как правило, не вызывает проблем после развертывания, если только это не проблема, вызванная средой и данными.

Поскольку ветка master объединяется с веткой dev или test PR, их тесты и проверки кода, как правило, проходят.Конечно, проверка кода и проверка будут выполняться повторно перед слиянием, и, наконец, задание сборки будет выполнено.

Pipeline

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

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

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

От частой отправки кода до автоматического тестирования (гарантия охвата тестами) -> выполнение локальных тестов -> выполнение тестов на сервере -> развертывание в тестовой среде -> управление доставкой.

И они должны быть автоматическими, поэтому вам нужно знать следующее: как писать тесты (Junit, Qunit, BDD, TDD..), автоматизированные тесты (Selenium..), управление версиями (git), конфигурация (функция toggle), управление зависимостями, сценарии развертывания и многое другое.

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

Позже я попробовал CI/CD Gitlab Pages и загрузил его на удаленный сервер после сборки:

image: node:10.4.1

variables:
  NODE_MODULES_VERSION: 'wiki-web-1.0.0' # node_modules版本号，每次升级依赖改一下这里的数值
  CURRENT_BRANCH: $CI_COMMIT_REF_NAME

# 缓存目录文件
# key是唯一值，重名会覆盖上一次的缓存
cache:
  key: '$NODE_MODULES_VERSION'
  paths:
    - node_modules/

stages:
  - build
  - deploy

build:
  stage: build
  cache:
    paths:
      - node_modules/

  script:
    - npm install  --silent
    - npm run build

  artifacts:
    name: 'dist'
    expire_in: 60 mins
    paths:
      - dist
      # - docs/.vuepress/dist

  only:
    - master

deploy:
  stage: deploy
  environment:
    name: Production
  before_script:
    # - sed -i '/jessie-updates/d' /etc/apt/sources.list
    # https://superuser.com/questions/1423486/issue-with-fetching-http-deb-debian-org-debian-dists-jessie-updates-inrelease/1424377#1424377
    - printf "deb http://archive.debian.org/debian/ jessie main\ndeb-src http://archive.debian.org/debian/ jessie main\ndeb http://security.debian.org jessie/updates main\ndeb-src http://security.debian.org jessie/updates main" > /etc/apt/sources.list
    - apt-get update -qq && apt-get install -y -qq sshpass
  script:
    - cd dist/
    - ls
    - sshpass -V
    - export SSHPASS=$USER_PASS
    - sshpass -e scp -P 端口 -o stricthostkeychecking=no -r . root@IP:/data/git_cd
    # - sshpass -e scp -o stricthostkeychecking=no -r . username@host.com:/var/www/html
    # - rsync -avz --delete -e"ssh -p 端口" ./ root@ip:/data/git_cd
  when: on_success
  only:
    - master

основывается наvuepressпроект, после автоматической сборки CI упакованныйdist文件夹загрузить наartifacts, когда компакт-диск работает, отсюда все в порядке.

Доступ к вложениям, созданным сборкой, можно получить черезsshpassилиrsyncЗагружать вложения на удаленный сервер. Связанные статьи могут относиться к:

• GitLab Build and Deploy to a Server via SSH
• GitLab-CI использует Rsync для непрерывного развертывания

App CI

Справочник по созданию среды Android и IOS CI:

• woo woo Краткое описание.com/afraid/651 no 049 oh 8…
• woo woo Краткое описание.com/afraid/30 Ebian wipe 319…

Выше приведены статьи, которыми поделились пользователи сети.Первая половина работы в основном заключается в создании среды запуска и докера, и есть более быстрый способ ее создания. Когда я создавал среду Android, я использовал общий Runner, а изображение было выбрано из сообщества с открытым исходным кодом.react-native-community/ci-sampledocker-образ, а затем настройте соответствующий сценарий выполнения. Помимо громоздкой конструкции среды Android, это преимущество докера.

набор инструментов непрерывной интеграции

Обычно используются следующие:

• Jenkins: используйте Jenkins для работы с веб-перехватчиком gitlab для CI/CD.
• Circle CI: мощный, дружелюбный к Github
• Travis CI: Мощный, дружественный к Github
• Gitlab CI: Gitlab поставляется со своей собственной средой CI, которая также проста в использовании (эта статья полностью отработана в gitlab ci).

Узнать больше о:док один.IO/article/817…

Блок-схема Jenkins CI/CD

Поделитесь двумя блок-схемами Jenkins CI/CD, которыми поделились пользователи сети ProcessOn:

Суммировать

Делая Runner общим типом, внешнему проекту не нужно повторно настраивать Runner, и его можно постепенно улучшать в последующих действиях. Полная конфигурация CI должна содержать следующие процедуры:第一步先初始化，第二步检查代码规范，第三步进行单元测试，第四步构建，第五步就直接将项目部署到服务器.

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

Добро пожаловать на обсуждение ~

---

рекомендовать:

• Руководство для менеджеров по продуктам по непрерывной доставке и DevOps
• Непрерывная поставка: систематический подход к надежному выпуску программного обеспечения

---

Author: @giscafer, оригинальный адрес:front-end-manual/Front-end engineering CI/CD практика на основе GitLab CI, Обсуждение приветствуется