持续集成指的是，频繁地（一天多次）将代码集成到主干，主要是为了快速发现错误和防止大幅度偏离主干分支。 持续部署指的是，频繁地将软件的新版本，交付给质量团队或者用户，代码通过评审以后，自动部署到生产环境。

持续集成 ​

持续集成指的是，频繁地（一天多次）将代码集成到主干，主要是为了快速发现错误和防止大幅度偏离主干分支。

持续部署指的是，频繁地将软件的新版本，交付给质量团队或者用户，代码通过评审以后，自动部署到生产环境。

真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。你敲了什么命令没人知道，但是你写个工具做变更线上系统，这个工具干了什么事，看看工具的源码就知道了。

总之，接下来的工作要尽可能的自动化。

持续集成系统演变过程

• 最初阶段：提交代码－自动部署；
• 一般进阶：提交代码－代码静态分析－自动部署；
• 高级进阶：提交代码－代码静态分析－自动化测试集（单元、验收、性能）－自动部署；

接下来，我们使用 Gitlab CI 实现最初阶段，提交代码之后自动部署。

Gitlab CI ​

1. 安装 Gitlab Runner ​

Gitlab Runner 部署在产品服务器上，是 .gitlab-ci.yml 的 script 部分的真正执行者，用来完成部署、测试等任务。

## 添加 Gitlab 的官方仓库
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

sudo apt-get install gitlab-runner

2. 修改 Gitlab Runner 的执行用户 ​

默认 gitlab runner 会添加一个新用户 gitlab-runner 来执行任务，现在修改为原来的用户。

使用 ps aux | grep gitlab 来查看 gitlab runner 的执行用户，获得这样的结果：

/usr/bin/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner

现在执行：

sudo gitlab-runner uninstall
sudo gitlab-runner install --working-directory /home/ubuntu --user ubuntu
sudo gitlab-runner restart

检验，可以看到 --user 和 —working-directory 已经修改成功：

/usr/bin/gitlab-runner run --working-directory /home/ubuntu --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user ubuntu

3. Gitlab 仓库注册 Runner ​

可以在 /settings/ci_cd 的 Runners settings 板块下获取需要的 url 和 token，以及管理当前仓库注册的 runner。

sudo gitlab-runner register

引导会让你输入 gitlab 服务器的 url、仓库的 token。

引导会让你输入 tag，一个项目可能有多个 runner，是根据 tag 来区别 runner 的。

引导会让你输入 executor，这个是要用什么方式来执行脚本，图方便输入 shell 就好了。

4. 编写脚本 ​

出于方便的考虑，我们可以在服务器上编写一些脚本，之后在配置文件 .gitlab-ci.yml 那里就可以调用。

比如，pullRepo 脚本用来拉取仓库的最新内容：

sudo nano /usr/local/bin/pullRepo
sudo chmod +x /usr/local/bin/pullRepo

##!/bin/bash
if [ $# -ne 2 ]
then
  echo "arguments error!"
  exit 1
else
  deploy_path="$HOME/repos/$1/$2"
  mkdir -p $deploy_path
  if [ ! -d "$deploy_path" ]
  then
    project_path="[email protected]:"$1/$2".git"
    git clone $project_path $deploy_path
  else
    cd $deploy_path
    git pull
  fi
fi

tgmsg 脚本用来使用 telegram 发送通知

##!/bin/bash
curl -H "Content-Type: application/json" \
  -d "{\"chat_id\":00000001,\"text\":\"$1\"}" \
  https://api.telegram.org/bot{{botToken}}/sendMessage

5. Gitlab CI 配置文件 ​

项目根目录添加一个 .gitlab-ci.yml 配置文件，记录一系列的阶段和规则。Gitlab-CI 会在 push 之后解析它来调用相应的 runner 来执行脚本。

stages: # 定义一批 stage
  - deploy
pull repo: # 定义一个任务
  stage: deploy # 相同 stage 的任务并发执行
  script: # runner 执行的叫脚本
    - pullRepo keng42 ci-demo
    - tgmsg "depoly keng42/ci-demo success"
  only:
    - master # 限制只有 master 分支的更新才会触发
  tags:
    - production # 对应 runner 配置的标签

至此，向仓库的 master 分支 push 更新，就可以在 /pipelines 看到一个新的任务，点进去还可以实时查看执行反馈。

持续更新 ​

TO BE CONTINUED

参考 ​

配置 Gitlab CI 自动发布代码到生产环境

[后端]gitlab之gitlab-ci自动部署

fir.im 持续集成技术实践

从 GITLAB 误删除数据库想到的