敏捷開發與Gitlab CI/CD持續集成

2021-01-08 程序猿指南

概述

敏捷軟體開發（Agile software development），是一種應對快速變化的需求的一種軟體開發能力。強調開發團隊與業務需求方之間的緊密協作、面對面溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發過程中人的作用。敏捷開發的流程分為幾個階段：編碼 -> 構建 -> 集成 -> 測試 -> 交付 -> 部署。而CI/CD是實現這一理念的方法。

持續集成CI(Continuous integration)

持續集成(Continuous integration)，簡稱CI，是一種軟體開發實踐。開發人員提交代碼後，系統自動進行構建、（單元）測試，通過自動化測試保障所有的提交在合併主線之後不會出現質量問題，對可能出現的一些問題進行預警。

需要具備的條件

需要為每個新功能、代碼改進、或者問題修復創建自動化測試用例。你需要一個持續集成伺服器，它可以監控代碼提交情況，對每個新的提交進行自動化測試。儘可能快地提交代碼。帶來的效益

通過自動化測試可以拿到測試結果，避免將一些問題提交到交付生產中。發布編譯將會更加容易，因為合併之初已經將所有問題都規避了。減少工作問題切換，研發可以很快獲得構建失敗的消息，在開始下一個任務之前就可以很快解決。測試成本大幅降低，你的CI伺服器可以在幾秒鐘之內運行上百條測試。團隊花費在測試上面的時間會大幅縮短，將會更加側重於質量方面的提升上面。

持續交付CD(Continuous Delivery)

持續交付(Continuous Delivery)，簡稱CD：是一種軟體工程的手法。持續交付在持續集成的基礎上，將集成後的代碼部署到更貼近真實運行環境的「類生產環境」（production-like environments）中，也就是我們通常說的預發布環境。交付給質量團隊或者用戶，以供評審。如果評審通過，代碼就進入生產階段。持續交付並不是指軟體每一個改動都要儘快部署到產品環境中，它指的是任何的代碼修改都可以在任何時候實施部署。

需要具備的條件

需要有強大的持續集成組件和足夠多的測試用例滿足代碼的需求。部署需要自動化。觸發是手動的，但是部署一旦開始，就不能人為幹預。團隊可能需要接受特性開關，沒有完成的功能模塊不會影響到線上產品。帶來的效益

繁瑣的部署工作沒有了。開發團隊不再需要花費幾天的時間去準備一個發布。你可以更快的進行交付，這樣就加快了與需求方之間的反饋環。輕鬆應對小變更，加速迭代。

持續部署CD(Continuous Deploymen)

持續部署(Continuous Deployment)，也是簡稱CD：指當交付的代碼通過評審之後，自動部署到生產環境中。持續部署是持續交付的最高階段。開發人員可以專注於構建軟體，他們看到他們的修改在他們完成工作後幾分鐘就上線了。基本上，當開發人員在主分支中合併一個提交時，這個分支將被構建、測試，如果一切順利，則部署到生產環境中。

需要具備的條件

研發團隊測試理念比較完善。測試單元的健壯性直接決定著交付質量。文檔和部署頻率要保持一致。特徵標誌成為發布重大變化過程的固有部分，以確保您可以與其他部門（支持，市場營銷，公關…）協調。帶來的效益

發布頻率更快，因為你不需要停下來等待發布。每一處提交都會自動觸發發布流。在小批量發布的時候，風險降低了，發現問題也可以很輕鬆的修復。客戶每天都可以看到我們的持續改進和提升，而不是每個月或者每季度，或者每年。持續交付與持續部署的關係

持續部署意味著所有的變更都會被自動部署到生產環境中。持續交付意味著所有的變更都可以被部署到生產環境中，但是出於業務考慮，可以選擇不部署。如果要實施持續部署，必須先實施持續交付。

持續交付表示的是一種能力；而持續部署則是一種方式。

Gitlab CI/CD介紹

Gitlab CI/CD是Gitlab一個簡潔好用的的持續集成/持續交付/持續部署的框架。為項目配置一個或者多個 GitLab Runner，然後添加一個

.gitlab-ci.yml

文件到項目根目錄，進行提交或者推送代碼到Gitlab伺服器，就可以很方便地持續集成/部署代碼。

.gitlab-ci.yml

文件會告訴Gitlab Runner做什麼。

Gitlab CI/CD運行原理

開發者推送、提交代碼到Gitlab，Gitlab通過項目的

.gitlab-ci.yml

文件配置，找到指定的項目gitlab runner，runner運行相關的命令，進行編譯、 集成、測試、交付、部署，一切順利地話會分發到各個伺服器（測試伺服器、預發布伺服器、正式伺服器等），此時一個迭代開發上線流程走完。流程圖如下。

GitLab Runner

GitLab Runner是一個開源項目，用於運行項目持續集成、持續部署作業並將結果發送回GitLab，與GitLab CI/CD一起使用。GitLab Runner是用Go編寫的，可以作為單個二進位文件運行，不需要語言特定的要求，運行在Linux，macOS和Windows作業系統上。只要您可以在其上編譯Go二進位文件，其他作業系統可能會起作用，也可以運行在Docker上。

執行流程

默認情況下，它運行有三個流水線階段stage：

build

，

test

，和

deploy

，可以在

.gitlab-ci.yml

的stages自定義，多個階段是按順序執行的，可以修改順序，如果其中一個階段失敗，則後續的階段不會被執行，整個過程被認為失敗。

Stage 在

.gitlab-ci.yml

中通過如下的方式定義：

stages: - build - test - deploy

任務Job可以關聯到一個階段stage，當一個 Stage 執行的時候，與其關聯的所有 Job 都會被執行。一個階段可以有多個任務Job，同個階段的任務直接是可並行執行的。

Job 在

.gitlab-ci.yml

中關聯Stage示例如下：

build:stage: build script: - cd ~/go/src/$CI_PROJECT_NAME/ - go build

至此，執行流程就講完了，接下來就是詳細的配置過程。

具體配置過程

安裝gitlab runner

這裡以安裝到Linux為例，參考官網教程，選用一臺編譯伺服器用root帳號執行。

下載gitlab runner二進位文件放在bin目錄：

wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386

賦予它可執行權限

chmod +x /usr/local/bin/gitlab-runner

創建一個gitlab CI用戶：

useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

安裝並作為服務運行

# 安裝gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner# 運行gitlab-runner start

註冊到gitlab

在gitlab項目獲取URL地址和token令牌，如下：

此時得到

URL地址：https://gitlab.xxxx.comtoken令牌：TOKEN

啟動註冊功能：gitlab-runner register輸入gitlab項目的URL地址，：Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )https://gitlab.xxxx.com輸入令牌：Please enter the gitlab-ci token for this runnerTOKEN輸入Runner的描述，可以在GitLab修改： Please enter the gitlab-ci description for this runner [hostame] my-runner給Runner添加標籤，這裡我標記為運行goland的：Please enter the gitlab-ci tags for this runner (comma separated):goland.gitlab-ci.yml 中可以設置 tags 欄位來聲明，當前任務只在擁有匹配 Tags 的 Runner 上運行。比如 iOS 編譯階段只能在 Mac Runner 上運行，那麼就可以設置這個 Runner 的 Tags 為 『iOS』，並且在 iOS 工程中在欄位 tags 中，添加『iOS』 值。 Tags 最好不要隨便命名，遵循適當的命名規則會讓後期 CI 的維護輕鬆許多。選擇Runner執行程序，這裡選擇用shell：Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:shell在gitlab項目查看是否允許，或者管理此runner：

runner其它命令

gitlab-runner --debug run，如果你遇到一些錯誤，可以使用這個命令來在前端（控制臺運行），查看loggitlab-runner stop ，停止運行gitlab-runner run --user jafir(普通用戶)，如果需要切換用戶可以使用這個gitlab-runner uninstall，如果想卸載從頭再來gitlab-runner status，查看狀態gitlab-runner verify，查看runner是否在運行後gitlab-runner verify --delete，刪除註冊的用戶，如果想要從頭再來刪除 ~/.gitlab-runner/config.toml(註冊的用戶的配置文件)，和/etc/gitlab-runner/config.toml，如果想要從頭再來

創建.gitlab-ci.yml文件

這裡用go語言的編譯發版的示例，你可以根據自己的需求配置：

stages: - build - deploybefore_script: - export NOW_DATE_TIME=$CI_PROJECT_NAME$(git show -s --format=%cd --date=format:%m-%d_%H:%M $CI_COMMIT_SHA)variables: SUPERVISORD_WORKER: "ci_cd_test-worker:ci_cd_test-worker_00" FILE_NAME: "meisha_account" TEST_HOST_IP: '127.0.0.1' PROD_HOST_IP: '127.0.0.2'build_stage: stage: build script: - rm -rf ~/go/src/$CI_PROJECT_NAME - cp -r $CI_PROJECT_DIR ~/go/src/ - cd ~/go/src/$CI_PROJECT_NAME/ - go get github.com/jsooo/log - go build tags: - golangdeploy_test: stage: deploy only: refs: - test script: - ssh -T -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=false test@$TEST_HOST_IP -p 23 "cd /home/test/projects/go/src/$CI_PROJECT_NAME/ && mv $FILE_NAME $NOW_DATE_TIME" - scp -P 56000 -q ~/go/src/$CI_PROJECT_NAME/$FILE_NAME test@$TEST_HOST_IP:/home/test/projects/go/src/$CI_PROJECT_NAME/ - ssh -T -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=false root@$TEST_HOST_IP -p 23 "supervisorctl -c /etc/supervisord/supervisord.conf restart $SUPERVISORD_WORKER" - echo '發到測試了' when: on_success tags: - golangdeploy_master: stage: deploy only: refs: - master script: - ssh -T -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=false user_00@$PROD_HOST_IP -p 23 "cd /data/publish/$CI_PROJECT_NAME/ && mv $FILE_NAME $NOW_DATE_TIME" - scp -P 56000 -q ~/go/src/$CI_PROJECT_NAME/$FILE_NAME user_00@PROD_HOST_IP:/data/publish/$CI_PROJECT_NAME/ - ssh -T -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=false root@$PROD_HOST_IP -p 23 "supervisorctl -c /etc/supervisord/supervisord.conf restart $SUPERVISORD_WORKER" - echo '發到測試了' when: on_success tags: - golang

配置說明

before_script 這一部分執行階段都會進行，我這執行的是獲取git commit提交的時間，賦值給NOW_DATE_TIME 變量；variables 是定義一些變量，這裡定義了測試、正式的IP位址，打包編譯的文件名，supervisorctl的進程名；build_stage、deploy_test 、deploy_master是一個個任務，可以自定義名稱，它們用stage關聯了某個階段，比如build_stage關聯了build階段，deploy_test關聯了deploy階段，deploy_master也關聯了deploy階段。only 定義哪個分支提交才會執行，我這裡定義了提交到test分支就部署到測試環境，提交到master分支就發布到正式環境。script 是任務的主要內容，需要執行的命令都寫在這。在build階段，用go build命令打包go程序。在deploy階段就把打包後的文件複製到伺服器，然後用supervisorctl重啟進程。when 定義了什麼時候才執行。tags標籤指定gitlab runner。具體配置可以參考gitlab的官網：https://docs.gitlab.com/ee/ci/yaml/README.html

相關焦點

  • 使用 GitLab CI 與 Argo CD 進行 GitOps 實踐
    GitLab CI 是 GitLab 的持續集成和持續交付的工具，也是非常流行的 CI/CD 工具，相比 Jenkins 更加輕量級，更重要的是和 GitLab 天然集成在一起的，所以非常方便。開發人員在自己的分支上開發代碼，他們分支的每一次提交都會觸發一個階段性的構建，當他們將自己的修改和主分支合併時，完整的流水線就被觸發。將構建應用程式，打包成 Docker 鏡像，將鏡推送到 Docker 倉庫，並自動更新 Kubernetes 資源清單，此外，一般情況下將應用部署到生產環境需要手動操作。
  • Gitlab-CI初識
    GitLab CI (Continuous Integration)是GitLab內置的進行持續集成的工具。基於特徵分支開發後，需要發起Merge Requests合併共享代碼庫。Merge Requests總是頻繁發生，合併請求過來後，可以觸發流水線自動去構建、測試、驗證新代碼功能，及早發現錯誤，減少集成問題。
  • 記一次Gitlab-CI集成K8S實錄
    docker、Kubernetes、Harbor、Prometheus等集群環境不是本文關注的重點，這裡只是記錄Gitlab-CI集成K8S的試驗，依賴現成的K8S集群環境，但曾經被還原過一次，導致一些配置丟失。
  • 炸裂，如此這般用 GitLab 做 CI/CD 是什麼感覺，太強了
    Continuous Integration (CI) 持續集成Continuous Delivery (CD) 持續交付Continuous Deployment (CD) 持續部署持續集成的工作原理是將小的代碼塊推送到Git倉庫中託管的應用程式代碼庫中，並且每次推送時，都要運行一系列腳本來構建、測試和驗證代碼更改，然後再將其合併到主分支中
  • 基於 Python 項目的 GitLab-CI 演示
    的CI/CD中pipelines進行部署整個持續集成和持續部署的流程如下：...Please enter the gitlab-ci coordinator URL (e.g.
  • Docker的搭建Gitlab CI 全過程詳解
    RUN cd /home/gitlab_ci; sudo -u gitlab_ci -H git clone -b 3-2-stable --depth 1 https://github.com/gitlabhq/gitlab-ci.git gitlab-ci RUN cd /home/gitlab_ci/gitlab-ci; sudo -u gitlab_ci -H mkdir -p tmp/
  • 如何使用GitLab CI/CD 觸發多項目管道
    持續集成（CI）是在將代碼合併到master分支之前自動進行代碼構建和測試的實踐這使開發人員可以及早的發現錯誤和頻繁地合併代碼，同時降低了將新錯誤引入主原始碼存儲庫的風險。代碼運行CI之後，在實時環境中部署和運行測試很重要。從CI過渡到持續交付和部署（CD）是DevOps成熟的下一步。再次部署然後進行測試，可以將一個項目中的代碼與其他組件和服務一起進行測試，而其他組件和服務可以在其他項目中進行管理。
  • Gitlab概覽
    Feature和Fix在開發人員在開發環境部署測試，master在測試環境中部署測試，pre-production在演示環境中部署測試，production在生產環境發布，一條流水線下來，可以持續完成項目的部署交付。此外，我們可以有多穩定版本的分支策略，用於將軟體發布給外界。
  • Gitlab-ci: 從零開始的前端自動化部署
    && 自動化部署工具的運行機制 1.2 自動化部署給我們帶來的好處二.知識預備 2.1 gitlab-ci涉及的抽象概念(Runner/PipeLine/Executor/Job ) 2.2 YML文件的基本語法規則 2.3 .gitlab-ci.yml配置的特定關鍵字三.CI實戰 3.1 編寫一個gitlab-ci的「hello world」四.坑點總結五.gitlab-ci進階 5.1
  • 從零入門Serverless快速構建GitLab持續集成環境
    同時，ASK 主要適用的場景有：在線業務彈性（視頻直播、在線教育）；大數據計算（Spark）；定時任務；CI/CD 持續集成。GitLab CI on ASK 的優勢說到 CI/CD，大家最熟悉的兩個工具，一個是 Jenkins，另一個是 GitLab CI，隨著 Devops 角色的流行，越來越多的企業採用 GitLab CI 作為持續集成的工具
  • GitOps—通過CI/CD自動化構建虛擬機模版
    基於Git提交記錄進行語義版本管理(feet、fix)，版本號自增，並存儲到模版的Notes中；定時執行CI/CD任務實現模版變異；採用vCenter內容庫存儲模版，並以-latest為後綴；每次構建自動更新vCenter內容庫模版，保持ID不變，以保證vRA雲平臺或其他工具調用最新模版；所有密碼和配置，通過.gitlab-ci.yml
  • 教你 7 步快速構建 GitLab 持續集成環境
    導讀：本節課程為您介紹如何基於阿里雲 Serverless Kubernetes（簡稱 ASK）服務，來快速構建 GitLab 持續集成環境。同時，ASK 主要適用的場景有：在線業務彈性（視頻直播、在線教育）；大數據計算（Spark）；定時任務；CI/CD 持續集成。
  • CI/CD工具：Jenkins還是GitLab CI/CD？
    十年來，持續集成（Continuous Integration，CI）和持續交付（Continuous Delivery，CD）領域都取得了很大的進步。DevOps 測試的興起導致了對 CI/CD 工具的快速需求。
  • GitLabCI/CD自動集成和部署到遠程伺服器
    持續集成的工作原理是：將小的代碼塊-commits-推送到Git存儲庫中託管的應用程式的代碼庫中，並且每次推送時，都要運行腳本管道來構建，測試和驗證代碼更改，然後再將其合併到主分支中。持續交付和部署包括進一步的CI，可在每次推送到存儲庫默認分支時將應用程式部署到生產環境。
  • Springboot+Docker+GitLab持續集成上
    概述本文主要介紹持續集成的搭建方式，採用Docker的方式去搭建Jenkins環境，另外會涉及到SpringBoot和Git等技術。2.什麼是持續集成傳統的軟體開發流程如下：項目經理分配模塊給開發人員每個模塊的開發人員並行開發，並進行單元測試開發完畢，將代碼集成部署到測試伺服器，測試人員進行測試測試人員發現bug，提交bug、開發人員修改bugbug修改完畢再次集成、測試
  • 12個可以替代jenkins的CI/CD工具
    精華推薦：重磅發布 - 自動化框架基礎指南pdfJenkins是一個開源的持續集成平臺，是DevOps生命周期中的一個重要工具。這個列表折衷了具有流行特性和最新下載連結的商業和開源的continuos集成工具。Buddy（官網：https://buddy.works）是一款面向web開發人員的智能CI/CD工具，旨在降低進入DevOps的門檻。它使用交付管道來構建、測試和部署軟體。這些管道是由100多個現成的動作創建的，這些動作可以以任何方式進行安排——就像您構建一個用磚砌成的房子一樣。
  • 新一代 CI 持續集成工具 flow.ci 正式開源
    很高興地宣布 flow.ci 在 Apache-2.0 協議下正式開源了。
  • SpringBoot+GitLab+Docker+Jenkins實現持續集成上
    概述本文主要介紹持續集成的搭建方式，採用Docker的方式去搭建Jenkins環境，另外會涉及到SpringBoot和Git等技術。2.什麼是持續集成傳統的軟體開發流程如下：項目經理分配模塊給開發人員每個模塊的開發人員並行開發，並進行單元測試開發完畢，將代碼集成部署到測試伺服器，測試人員進行測試
  • Jenkins Pipeline結合github拉取請求自動進行項目發布(CI/CD)
    通過Jenkins Pipeline自動執行某些步驟來簡化發布流程將會大大改善發布的工作流程，這種業界一般稱為自動持續集成和自動持續部署（CI/CD），一般來說可以結合Jenkins和Github結合來完成，當然如果是私有倉庫用的是gitlab做的話，gitlab自有一套強大的CI/CD流程，在自己體系內就可以完成，而無需Jenkins來做了，以後有機會蟲蟲會和大家一起探討gitlab的ci/cd功能
  • 容器微服務和持續集成，（四）GitLab配置使用和代碼上傳
    今天整理和介紹，配合GitLab使用的代碼集成環境。下一篇將介紹通過使用Jenkins，來實現代碼的持續集成。一、GitLab配置GitLab的安裝很簡單，我就不再介紹了。在git機器上使用 ssh -T git@172.17.42.77驗證秘鑰方式連接gitlab