• 端到端自動(dòng)化流水線
  • 需求、代碼構(gòu)建、測(cè)試、部署環(huán)境內(nèi)嵌自動(dòng)化能力，每次提交都觸發(fā)完整流水線
• 提交階段流水線（個(gè)人級(jí)）、
• 驗(yàn)收階段流水線（團(tuán)隊(duì)級(jí)）、
• 部署階段流水線（部署/發(fā)布）
• 流水線自動(dòng)化觸發(fā)，遞次自動(dòng)化(制品)晉級(jí)；
• 流水線任務(wù)按需串行、并行、特殊場(chǎng)景下跳過執(zhí)行
• 必要環(huán)節(jié)人工干預(yù), e.g. 在手工測(cè)試、正式發(fā)布等環(huán)節(jié)導(dǎo)入手工確認(rèn)環(huán)節(jié)，流水線牽引流動(dòng)

1）提交流水線

過程如下：

• 提交即構(gòu)建
• 編譯單測(cè)打包代碼質(zhì)量檢查
• 構(gòu)建錯(cuò)誤第一時(shí)間通知提交人

以Jenkins實(shí)現(xiàn)為例，
通過webhook觸發(fā)CI構(gòu)建，首先配置Jenkins項(xiàng)目

• 使用generic webhook方式觸發(fā)項(xiàng)目構(gòu)建
• 配置構(gòu)建觸發(fā)器參數(shù)（獲取gitlab返回的數(shù)據(jù)，比如分支、用戶等信息）
• 配置構(gòu)建觸發(fā)器中的token（確保唯一，建議可以用項(xiàng)目名稱）
• 配置觸發(fā)器中的請(qǐng)求過濾（merge_request，opend）

其次是Gitlab的配置

• 項(xiàng)目-》集成-》新建webhook
• 填寫webhook地址?token=projectName
• MergeRequest操作觸發(fā)

剩下的就是編寫Jenkinsfile了，下面列出幾個(gè)關(guān)鍵點(diǎn)
1.獲取gitlab數(shù)據(jù)中的分支名稱，作為本次構(gòu)建的分支名稱。
2.獲取gitlab數(shù)據(jù)中的用戶郵箱，作為構(gòu)建失敗后通知對(duì)象。

2）MR流水線

過程如下：

• codereview
• 配置分支保護(hù)
• 創(chuàng)建合并請(qǐng)求對(duì)將代碼審查結(jié)果在評(píng)論區(qū)展現(xiàn)
• 由assignUser合并代碼

合并流水線設(shè)計(jì)：合并流水線的步驟其實(shí)跟提交流水線很類似，但是在代碼質(zhì)量檢查的步驟中嚴(yán)格要求檢查質(zhì)量閾的狀態(tài)，當(dāng)質(zhì)量閾狀態(tài)為錯(cuò)誤的時(shí)候，需要立即失敗并通知發(fā)起人。
第一次設(shè)計(jì)

• 開發(fā)人員創(chuàng)建MR并指定AssignUser。
• CI工具開始對(duì)MR中的源分支進(jìn)行編譯構(gòu)建打包代碼檢查。
• 構(gòu)建成功（代碼質(zhì)量沒問題）在MR頁(yè)面評(píng)論提示信息。
• 構(gòu)建失敗在MR頁(yè)面評(píng)論失敗信息

第二次設(shè)計(jì)（借助GitlabCI）- 優(yōu)化點(diǎn)：加入MR構(gòu)建失敗攔截，成功自動(dòng)合并

• 項(xiàng)目配置當(dāng)流水線成功時(shí)才能merge。
• 開發(fā)人員創(chuàng)建MR并指定AssignUser。
• Jenkins開始對(duì)MR中的源分支的最后一次commit狀態(tài)改為running。
• 然后進(jìn)行編譯構(gòu)建打包代碼檢查。
• 構(gòu)建成功，更新最后一次commit的狀態(tài)為 success。
• 構(gòu)建失敗，更新最后一次commit的狀態(tài)為faild。

3）SQL發(fā)布流水線

除了代碼有版本，其實(shí)SQL也有“版本的”，SQL腳本的版本對(duì)于產(chǎn)品的升級(jí)回滾至關(guān)重要。
一般對(duì)SQL的集成，會(huì)包含如下要素

1. 構(gòu)建環(huán)節(jié)，對(duì)SQL語(yǔ)法進(jìn)行檢查，避免打進(jìn)包里語(yǔ)法是錯(cuò)的；某些情況下，多個(gè)開發(fā)會(huì)寫不同的增量腳本，最后發(fā)布時(shí)候需要做腳本的合并
2. SQL腳本的版本，某些情況下產(chǎn)品自身要用表來(lái)記錄自身業(yè)務(wù)腳本的版本，通過產(chǎn)品版本來(lái)判斷某些腳本是否應(yīng)該被執(zhí)行。

當(dāng)然，也有其他數(shù)據(jù)庫(kù)版本管理工具，比如 flyway 和 liquibase；

• Flyway是獨(dú)立于數(shù)據(jù)庫(kù)的應(yīng)用、管理并跟蹤數(shù)據(jù)庫(kù)變更的數(shù)據(jù)庫(kù)版本管理工具。用通俗的話講，F(xiàn)lyway可以像Git管理不同人的代碼那樣，管理不同人的sql腳本，從而做到數(shù)據(jù)庫(kù)同步。
• liquibase 只是在功能上和Flyway有差異

不管怎么樣，它們底層的原理都是用另外的表記錄SQL腳本的版本，升級(jí)更新是比較版本差異，來(lái)決定是否執(zhí)行。
python自帶的model模塊 python manage.py makemigrations 同樣在做類似 的事情
數(shù)據(jù)庫(kù)版本管理

流水線的關(guān)鍵元素

不管你用什么CI/CD平臺(tái)，開源的Jenkins, GitLab CI, Teckton, Drone，還是商用的Azure,阿里云效等，不管是代碼化，還是可視化，流水線包含的元素基本都差不多，下面通過不同的示例來(lái)說(shuō)明這些元素的作用和含義。
參考：

• https://docs.gitlab.com/ee/ci/pipelines/
• https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/key-pipelines-concepts?view=azure-devops
• https://www.jenkins.io/doc/book/pipeline/

Agent&Runner(執(zhí)行代理)

image: "registry.example.com/my/image:latest" #gitlab-ci

pool:
  vmImage: ubuntu-latest  #auzure

agent { label 'linux' }  //jenkins

agent {
    docker {
       image 'maven:3-alpine'
       label 'Ubuntu'
       args '-v /root/.m2:/root/.m2'
    }
}

Parameter(參數(shù)變量）

• **流水線級(jí)別參數(shù) **（全局參數(shù)），范圍限于整個(gè)流水線運(yùn)行時(shí)，可被整個(gè)流水線其他任務(wù)使用
  • 內(nèi)置全局參數(shù) - 一般稱為built-in（預(yù)定義） variable, 有的平臺(tái)成為環(huán)境變量

export CI_JOB_ID="50"
export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a"
export CI_COMMIT_SHORT_SHA="1ecfd275"
export CI_COMMIT_REF_NAME="main"
export CI_REPOSITORY_URL="https://gitlab-ci-token:[masked]@example.com/gitlab-org/gitlab-foss.git"

1. BUILD_ID : 當(dāng)前build的id
2. BUILD_NUM : 當(dāng)前build的在pipeline中的build num
3. PIPELINE_NAME : pipeline 名稱
4. PIPELINE_ID: pipeline Id
5. GROUP: pipeline 所屬的group 名稱
6. TRIGGER_USER: 觸發(fā)build的user（event觸發(fā)的為觸發(fā)gitlab event的user）
7. STAGE_NAME: 當(dāng)前運(yùn)行的stage的名稱
8. STAGE_DISPLAY_NAME : 當(dāng)前運(yùn)行的stage的顯示名稱
9. PIPELINE_URL : pipeline在ui中的網(wǎng)頁(yè)的鏈接
10. BUILD_URL: build 在ui的網(wǎng)頁(yè)鏈接
11. WORKSPACE: 當(dāng)前stage運(yùn)行的工作目錄，通常用作拼接絕對(duì)路徑

• 非內(nèi)置全局參數(shù)

 environment {         
        HARBOR_ACCESS_KEY = credentials('harbor-userpwd-pair')     
        SERVER_ACCESS_KEY = credentials('deploy-userpwd-pair')      
        GITLAB_API_TOKEN = credentials('gitlab_api_token_secret')       
    }

• 外部參數(shù) - 一般作為運(yùn)行時(shí)參數(shù)

variables:
  TEST_SUITE:
    description: "The test suite that will run. Valid options are: 'default', 'short', 'full'."
    value: "default"
  DEPLOY_ENVIRONMENT:
    description: "Select the deployment target. Valid options are: 'canary', 'staging', 'production', or a stable branch of your choice."

parameters([ 
        separator(name: "PROJECT_PARAMETERS", sectionHeader: "Project Parameters"),
        string(name: 'PROJECT_NAME', defaultValue: 'vue-app', description: '項(xiàng)目名稱') ,
        string(name: 'GIT_URL', defaultValue: 'git@git.xxxx.com.cn:devopsing/vuejs-docker.git', description: 'Git倉(cāng)庫(kù)URL') ,
])

• 步驟任務(wù)參數(shù) （局部參數(shù)） - 一般作為某個(gè)插件任務(wù)的輸入?yún)?shù)，也可以使用上個(gè)任務(wù)的輸出作為參數(shù)，范圍僅限于該任務(wù)內(nèi)
• 加密變量 - 對(duì)特殊變量進(jìn)行加密處理

secrets:
  DATABASE_PASSWORD:
    vault: production/db/password@ops  # translates to secret `ops/data/production/db`, field `password`

Step(步驟)

參考： https://docs.drone.io/pipeline/overview/

---
kind: pipeline
type: docker
name: default

steps:
- name: backend
  image: golang
  commands:
  - go build
  - go test

- name: frontend
  image: node
  commands:
  - npm install
  - npm run test

...

Stage(階段)

一般用于對(duì)多個(gè)任務(wù)（step）進(jìn)行分組歸類，便于管理

 stage('Pull code') {
            steps {
                echo 'Pull code...'
                script {
                    git branch: '${Branch_Or_Tags}', credentialsId: 'gitlab-private-key', url: 'git@git.xxxx.com.cn:xxxx/platform-frontend.git'
                }
            }
}

Trigger(觸發(fā)器)

trigger:
- master
- releases/*

trigger_pipeline:
stage: deploy
script:
- 'curl --fail --request POST --form token=$MY_TRIGGER_TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/123456/trigger/pipeline"'
rules:
- if: $CI_COMMIT_TAG
environment: production

trigger:
  event:
  - promote
  target:
  - production

trigger:
   type: cron
   cron: '*/5 * * * *' #每5分鐘執(zhí)行一次

制品歸檔&緩存 （artifacts&cache）

一般用于CI制品的歸檔，以及CI構(gòu)建的緩存

archiveArtifacts artifacts: 'target/*.jar', fingerprint: true

job:
  artifacts:
    name: "$CI_JOB_NAME"
    paths:
      - binaries/

cache: &global_cache
  key: $CI_COMMIT_REF_SLUG
  paths:
    - node_modules/
    - public/
    - vendor/
  policy: pull-push

集成憑證（Credentials）

參考：

• http://www.rzrgm.cn/FLY_DREAM/p/13888423.html
• https://www.jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials

主要用于CI/CD流水線對(duì)接外部工具，通過token/pwd/private key等方式連接外部服務(wù)。一般需要在界面做些提前配置，生成token 或者憑證ID，將ID在CI/CD yaml 或jenkinsfile中使用

withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD')]) {
// available as an env variable, but will be masked if you try to print it out any which way
// note: single quotes prevent Groovy interpolation; expansion is by Bourne Shell, which is what you want
sh 'echo $PASSWORD'
// also available as a Groovy variable
echo USERNAME
// or inside double quotes for string interpolation
echo "username is $USERNAME"
}

Service(服務(wù))

該元素應(yīng)用于一些復(fù)雜的場(chǎng)景，比如需要一種外部（公共）服務(wù)為流水線提供某種輸入或者結(jié)果。
您可以將相互依賴的服務(wù)用于復(fù)雜的作業(yè)，例如端到端測(cè)試，其中外部API需要與自己的數(shù)據(jù)庫(kù)通信。
例如，對(duì)于使用API的前端應(yīng)用程序的端到端測(cè)試，并且API需要數(shù)據(jù)庫(kù):

end-to-end-tests:
  image: node:latest
  services:
    - name: selenium/standalone-firefox:${FIREFOX_VERSION}
      alias: firefox
    - name: registry.gitlab.com/organization/private-api:latest
      alias: backend-api
    - postgres:14.3
  variables:
    FF_NETWORK_PER_BUILD: 1
    POSTGRES_PASSWORD: supersecretpassword
    BACKEND_POSTGRES_HOST: postgres
  script:
    - npm install
    - npm test

模板（Template）

參考： https://docs.drone.io/template/yaml/
某些平臺(tái)會(huì)使用“模板“的概念，其實(shí)就是復(fù)用的思想，通過加載固定模板實(shí)現(xiàn)一些快捷動(dòng)作

kind: template
load: plugin.yaml
data:
  name: name
  image: image
  commands: commands

kind: pipeline
type: docker
name: default
steps:
   - name: {{ .input.name }}
     image: {{ .input.image }}
     commands:
        - {{ .input.commands }}

執(zhí)行邏輯控制

參考： https://docs.gitlab.com/ee/ci/pipelines/pipeline_architectures.html

stage('run-parallel') {
  steps {
    parallel(
      a: {
        echo "task 1"
      },
      b: {
        echo "task 2"
      }
    )
  }
}

stage('Build') {
            when {
                environment name: 'ACTION_TYPE', value: 'CI&CD'
            }
            steps {                
                buildDocker("vue")                           
            } 
}

stages:
  - build
  - test
  - deploy

image: alpine

build_a:
  stage: build
  script:
    - echo "This job builds something quickly."

build_b:
  stage: build
  script:
    - echo "This job builds something else slowly."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "This test job will start as soon as build_a finishes."
    - echo "It will not wait for build_b, or other jobs in the build stage, to finish."

test_b:
  stage: test
  needs: [build_b]
  script:
    - echo "This test job will start as soon as build_b finishes."
    - echo "It will not wait for other jobs in the build stage to finish."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "Since build_a and test_a run quickly, this deploy job can run much earlier."
    - echo "It does not need to wait for build_b or test_b."
  environment: production

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "Since build_b and test_b run slowly, this deploy job will run much later."
  environment: production

門禁審批

參考：https://learn.microsoft.com/en-us/azure/devops/pipelines/release/deploy-using-approvals?view=azure-devops

pipeline {
    agent any
    stages {
        stage('Example') {
            input {
                message "Should we continue?"
                ok "Yes, we should."
                submitter "alice,bob"
                parameters {
                    string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
                }
            }
            steps {
                echo "Hello, ${PERSON}, nice to meet you."
            }
        }
    }
}

pool: 
   vmImage: ubuntu-latest

jobs:
- job: waitForValidation
  displayName: Wait for external validation  
  pool: server    
  timeoutInMinutes: 4320 # job times out in 3 days
  steps:   
   - task: ManualValidation@0
     timeoutInMinutes: 1440 # task times out in 1 day
     inputs:
         notifyUsers: |
            someone@example.com
         instructions: 'Please validate the build configuration and resume'
         onTimeout: 'resume'

部署流水線分步驟實(shí)施

說(shuō)了這么多，如果從0開始寫流水線呢，可以按照下面的步驟，從“點(diǎn)”到“線”結(jié)合業(yè)務(wù)需要串起來(lái)，適合自己團(tuán)隊(duì)協(xié)作開發(fā)節(jié)奏的流水線才是最好的。

1. 對(duì)價(jià)值流進(jìn)行建模并創(chuàng)建簡(jiǎn)單的可工作流程
2. 將構(gòu)建和部署流程自動(dòng)化
3. 將單元測(cè)試和代碼分析自動(dòng)化
4. 將驗(yàn)收測(cè)試自動(dòng)化
5. 將發(fā)布自動(dòng)化

注意的事項(xiàng)
開始寫流水線需要注意一下幾個(gè)方面，請(qǐng)考慮進(jìn)去

• 確定變量 - 哪些是你每次構(gòu)建或者部署需要變化的，比如構(gòu)建參數(shù)，代碼地址，分支名稱，安裝版本，部署機(jī)器IP等，控制變化的，這樣保證任務(wù)的可復(fù)制性，不要寫很多hardcode進(jìn)去
• 變量/命名的規(guī)范化，不要為了一時(shí)之快，最后換個(gè)機(jī)器/換個(gè)項(xiàng)目，流水線就不能玩了，還要再改
• 如果可以，最好是封裝標(biāo)準(zhǔn)動(dòng)作成為插件，甚至做成自研平臺(tái)服務(wù)化，讓更多團(tuán)隊(duì)受益
• 如果你還在用手動(dòng)的方式配置流水線，請(qǐng)盡快切換到代碼方式，不管是jenkinsfile,還是yaml , 一切皆代碼 也是DevOps提倡的。

流水線案例

案例-1

案例-2