第四步：实战化

GitLab CI的目的是定义一些工作流，自动化地构建、测试和发布软件，以减少手动操作和加快交付速度。再不用工作流的时候大家都怎么交付的呢？

本地yarn build,然后把打包出来的dist交给后端同学部署，又或者自己部署到环境上。
本地yarn build,然后把打包出来的dist提交到后端仓库指定的静态资源目录下面，然后由后端整体打包构建服务。
使用jenkins帮你打包部署，执行定义好的工作流。

咱们先说说3的问题为何使用GitLab CI代替jenkins的优势：

每次构建任务需要去jenkins点一下。
使用GitLab 的 webhooks监听push等动作来触发jenkins执行的(这个先不在这里细说了)，多了一步。
无法使用Gitlab的内置的环境变量。

后面我们就把重心都切到了GitLab CI上面了，那么咱们回到正题如何使用GitLab CI工作流分别帮咱们使用1,2呢？

第一种: 直接把静态资源部署到开发、生产服务器上

同步本地和目标服务器的插件咱们使用rsync、ansible-playbook、sshpass等来实现用脚本登录服务器操作静态资源文件

如果本机或者远程计算机没有安装 rsync，可以用下面的命令安装。注意，传输的双方都必须安装 rsync。

bash

# Debian
$ sudo apt-get install rsync

# Red Hat
$ sudo yum install rsync

# Arch Linux
$ sudo pacman -S rsync

使用方法看阮一峰rsync 用法教程

yml

variables:
  FILE_NAME: dist.zip

stages:
  - build

build:
  stage: build
  script:
    - yarn && yarn build
    - cd dist/ && zip -r dist.zip ./* && mv dist.zip ../ && cd -
    - ls

  artifacts:
     # expire_in 产物保留多少天
    expire_in: 30 days
    paths:
      - ${FILE_NAME}
  tags:
    - runner

deploy:
  stage: deploy
  script: 
    - sudo rsync
    - echo "project done"
  only:
    - tags
  dependencies:
    - build
  tags:
    - runner

第二种: 交到后端仓库指定的静态资源目录

定义工作流直接把代码打包，然后把dist文件夹上传到后端工程里面（后端git仓库）。如下：

yml

variables:
  USER_NAME: '你的用户名（需要跟你git的保持一致）'
  USER_EMAIL: '你得邮箱（需要跟你git的保持一致）'
  BRANCH: ${CI_COMMIT_REF_NAME}
  BUILD_SUCCESS: '打包执行成功'
  SUCCESS: 'job执行完成'
   
stages:
  - prod_deploy
 
prod_deploy:
  stage: prod_deploy
  script:
    # 打包-配置
    - npm -v
    - yarn && yarn build
    - ls
    - echo ${BUILD_SUCCESS}
    # - ssh-Key-配置
    - mkdir ~/.ssh -p
    - chmod 700 ~/.ssh
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
    - eval $(ssh-agent -s)
    # # PRIVATE_SSH_KEYE 在该仓库中定义的变量
    - echo ${PRIVATE_SSH_KEYE};
    - ssh-add <(echo "$PRIVATE_SSH_KEYE")
    - git config --global user.name ${USER_NAME};
    - git config --global user.email ${USER_EMAIL};
    - echo ${BRANCH};
    # 推送仓库配置
    - ls
    - cd .ci && yarn
    # node 提交git 脚本再下面文件中
    - node index
    - echo ${SUCCESS}

  only:
    - master
 
  #dependencies:  表示依赖关系的
  artifacts:
    paths:
      - ${FILE_NAME}
  tags:
    - runner

${PRIVATE_SSH_KEYE}是你本地的ssh私钥，放在了自定义变量里面。以下命令获取私钥：

bash

cd ~/.ssh
cat id_rsa

大概node脚本就是如下流程：

拉取后端仓库切换到要提交的分支；
删除原本的前端静态资源；
复制新打包出来的资源到后端仓库里面；
git提交；
删除拉下来的后端仓库；

// node inde
const chalk = require('chalk');
const shell = require('shelljs');
const { log } = console;

const FULL_NAME = '你的打包后的文件名称';
const GIT_PATH = 'clone的后端的ssh地址';
const GIT_BRANCH = '后端仓库要提交的分子';
const PROJECT_AS_NAME = 'project-clone';

function deploy() {
  // 上传git
  shell.rm('-rf', `${PROJECT_AS_NAME}/`);
  shell.exec('git config user.name');
  shell.exec(`git clone ${GIT_PATH} -b ${GIT_BRANCH} ${PROJECT_AS_NAME}`);

  shell.exec('ls');
  shell.cd(PROJECT_AS_NAME);
  shell.rm('-rf', `${FULL_NAME}/`);
  shell.rm('-rf', `${FULL_NAME}/`);
  shell.cp('-R', `../../${FULL_NAME}`, `${FULL_NAME}`);

  shell.exec('pwd');
  shell.exec('git add .');
  shell.exec('git status');
  log(chalk.blue('git add 成功！'));
  //这里是运行的sh 文件 放下面了   
  shell.exec('sh ../command.sh');
  log(chalk.blue('git commit 成功！'));
  shell.exec('git push');
  shell.cd('..');
  shell.exec('pwd');
  shell.rm('-rf', `${PROJECT_AS_NAME}/`);
  shell.rm('-rf', `${FULL_NAME}`);
  log(chalk.blue('git 推送成功！'));
}


deploy();

由于没办法使用node脚本提交git commit把该指令放在了sh文件中如下：

#!/bin/bash
git commit -m $'feat:前端更新'

echo 'commit success'

以上只是适合我的工作中的应用场景，可以参考下定制属于自己的工作流。其实还有些其他常见的流程比如：再项目推送完成后可以向项目组上的人发送邮件，通知他们部署成功，又或者可以调用钉钉的webhooks等达到一个通知的功能。

第四步：实战化 ​

第一种: 直接把静态资源部署到开发、生产服务器上 ​

第二种: 交到后端仓库指定的静态资源目录 ​

第四步：实战化

第一种: 直接把静态资源部署到开发、生产服务器上

第二种: 交到后端仓库指定的静态资源目录