及時反映衝突,馬上處理
補充
另一個概念 Agile Development:盡快取得市場的 feedback,確認開發方系是否符合市場需求。需要 DevOps 和 CI/CD 兩項技術支援以達到加速整個流程的目的。
CI/CD 中非常重要的一環
TDD(Test-Driven Development)是一種開發流程,中文是「測試驅動開發」。 用一句白話形容,就是「先寫測試再開發」。 先寫測試除了能確保測試程式的撰寫,還有一個好處:有助於在開發初期釐清程式介面如何設計。
版控系統
Git hooks
inotify
Container
維持開發環境和營運環境的統一性
維持測試環境的單純
維持系統的安全性
docker in docker (DinD)
人工的版控
當專案稍微大型一點,還在用人工去做版控已經不太實際…
pic by 陳建宏老師
所以我們需要一個自動化的版控系統,去解決上述問題。
為了保持 codebase 的健康,我們會以 branch 的方式,從現在穩定的版本開一個分支,並且在這個分支上開發,開發完後要跟 codebase 合併,就是所謂的 merge。
Linux kernel 的開發團隊原本以 BitKeeper 來管理程式碼,但後來 BitKeeper 開始收費,於是 Linus Torvalds(Linux 之父) 花了 10 天,自己做了一個版控系統,就是 Git。
免費、開源
速度快、檔案體積小 (snapshot)
.git 目錄巡禮
分散式系統
支援多人同時編輯,傳統版控的作法是把要修改的檔案 lock 起來,直到解除 lock 之前,其他人都是無法編輯的狀態。
易學難精,但根據 "80/20 法則", 20% 的指令就可以應付 80% 的工作。
當 master 還沒被其他 branch 修改,對目前 fork 出來的 branch 來說,他就等於是所有的修改,所以可以被 ff-merge 回去。
預設為 ff-merge,使用no-ff
參數 merge,生成新節點,以便維持版本歷史的清晰。
三種最常用的 Workflow
最早出現,也最早被廣泛使用。
特色是專案中長期 (不會刪除) 存在兩個 branch
還有三種短期的臨時分支,開發完 merge 到 master 或 develop 就會刪除。
Github 比 Git 多了兩個服務,fork 和 pull request(簡稱PR)。
先有一個共有的 remote repository,然後各自 fork 到個人的 repository。完成 develop 之後,向共有的 repository 發 PR,審核後 merge 進 master。
所以他只有 feature 跟 master 分支
如此一來,既可以滿足很多 github flow 不方便的地方,又不會像 git flow 那麼複雜。
進而產生對知名工具的迷思
FIXME 不符合現狀
FIXME table
名稱 | jenkins | drone | Gitlab CI | Travis CI | Circle CI |
---|---|---|---|---|---|
定價 | Free | Free | Free | Free / On-premise | Free / Pricing |
支援系統 | Linux、Mac OS、iOS | Linux、Mac OS、iOS | Linux | Linux | Linux、Mac OS、支援容器 |
服務類型 | SaaS | SaaS | SaaS/On-premise | SaaS | SaaS |
支援的版控系統 | CVS、Git、Perforce | Git、Bitbucket | GitHub | GitHub | GitLab、Bitbucket |
設定檔格式 | .jenkins.yml | .drone.yml | .gitlab-ci.yml | .travis.yml | .circle.yml |
特點 | 1.在各版本作業系統輕鬆更新 2. 可以通過Web介面輕鬆設定和設定 Jenkins | 1. 為開源產品使用者可下載官方Docker映象或從原始碼構建 2. Pipeline配置了一個簡單易讀的檔案,可以直接提交至git倉庫;每個Pipeline步驟都在一個隔離的Docker容器中執行 | 1. 提供大多數功能的API讓開發人員進行更深入的整合 2. GitLab中的內部專案允許促進內部儲存庫的內部sourcing | 1. Travis使用虛擬機器構建應用程式 2. 強大的 API 和命令列工具 | 1.支援Docker可以配置自定義環境 2. 與VCS工具整合 |
預設是使用雲端的共享的 runner 來執行 .gitlab-ci.yml
裡面撰寫的 script,不過你也可以架自己的 runner,runner 就是一個在 server 上跑的 container,所以一個 server 也可以架設多個 runner。
GitLab 內建了 CICD 工具,不需要使用第三方工具。
Job
整個 GitLab-CI 裡面最小的執行單位,每一個 job 都會開一個 container。
Stage
包含一個或多個 Job,代表一個執行階段。
Pipeline
由一個或多個 Stage 組成,就是一次 CI/CD 的所有執行階段,依序執行 Stage,執行過程中一旦有一個 Job 報錯,預設後續的 Stage 都會被忽略。
allow_failure: true
(.gitlab-ci.yml
).gitlab-ci.yml
?放在 Project 的根目錄,用來決定 Gitlab CI 要做什麼。它會跟著 Project 一起做版控,每次 Push 的時候 GitLab 就會去讀取他,然後用 Gitlab Runner 執行 pipeline.
YAML 是專門用來寫設定檔的語言,和 python 一樣用縮排代表層級
.gitlab-ci.yml
檔案結構alpine: 極輕量化的 linux (5MB)
stage: 設定目前的 job 屬於哪個 stage (預設為 test )
script: 此 job 要執行的腳本內容 ( job 中唯一必要的參數 )
artifacts: 當 stage 結束時會保留的檔案,以便別的 job 取用
exit 1
強制設定 job 為 failed (0 為 success,非 0 皆為失敗 )Image Not Showing Possible ReasonsLearn More →
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
參數 | 內容 |
---|---|
tags | 用來選擇註冊到 gitlab 的自架 runner |
dependencies | 限制 job 之間的依賴關係 |
cache | 存放需要使用的套件,以前沒有 cache 的時候放在 artifacts |
before_script | 每次執行測試之前的設置,例如 docker 的登入,或 apt install |
only | 定義 job 僅限於哪些 branch 使用 |
except | 定義 job 不被哪些 branch 使用 |
retry | 設置失敗後重試的次數,小於等於 2 |
Cache | Artifacts |
---|---|
透過 key 來辨識,同樣的 key 檔案會被後來執行的 job 覆蓋 | 沒有同 key 覆蓋問題 |
只會存在同一個 runner 所以不同 tag 的 job 無法相互取用 | 生成之後,後面的 job 都可以取用 |
設定預設要使用的 image,他給你的是 doker + machine,可以自己做選擇。
還有 executor 預設要用的 runner
連結大概長這樣
https://gitlab.com/chiyuh1996/hello/-/settings/ci_cd
.gitlab-ci.yml
顯示 passed 表示執行成功
那再點進去看他到底做了什麼
Artifacts 就是在 jobs 之間傳遞的檔案,
常用於 error report等
example
這樣就成功把 hello.txt 從 job_A 傳到 job_C
如果在 job_C 中把 dependencies 設為 job_B
則 job_C 只會去取用 job_B 的artifacts,所以他就拿不到 hello.txt 這個檔案
專案目錄
DOCKERFILE
ADD 跟 COPY 的差別
COPY 是單純把 local 檔案 複製到 docker image 裡面,ADD 可以做到 COPY 的功能,不一樣的是,ADD 可以用URL (非 local),或者是直接把一個 tar 檔案,解壓到指定的 docker image 裡的位置。意思是就可以 save 你的 image 並用 artifacts 傳到下個 stage,就可以在下個 stage 把這個 image 把他 load 出來
參考:若要改成 push 到 Docker Hub
在 project 的 CI/CD 設定中加入 Docker Hub 的 url 跟帳號密碼,即可改成 push 到 Docker Hub。
Docker Hub 也有自動 build image 的功能。在 Docker Hub 設定好 autobuild 之後,當每次 push 到 git repository,就會透過 webhook 去觸動 Docker Hub 開始 build image。
這邊會在 docker 裡面把剛剛 build 的 image 跑起來
再看跑出來的字串是否符合預期