CICD Workshop 20180922

我們即將接手一個
專案
2

密碼產生服務
password
password
password
password
4

解決了市場需求
那現在可以解決自己的
生理需求了嗎
非功能性需求 6

接下來，就交給你們了
7

1. 登入自己的 Gitlab 帳號
2. Fork unipass project (https://gitlab.com/earou/unipass)
3. 進入 Cloud9 環境
4. git clone https://gitlab.com/{GITLAB_ID}/unipass.git
Chat Room: https://gitter.im/cicd-workshop-tw/Lobby
專案之初
8

腦力激盪
1. 想像一下你剛換新工作，或換專案。
2. 你拿到了一份程式原始碼。
3. 5 分鐘小組討論時間，試著提出一些問題。
9

9/22 小組討論 1
1. 要怎麼 build 環境，怎麼看到結果，plugin 要麼加
2. 必要的第三方軟體，如何準備開發環境
3. 專案進入點，config property，from QA
10

Exercise 1
目標：自動化建置，執行
延伸閱讀
Continuous Delivery 中文版
第一章 Page5-6
用自動化腳本取代詳細的說
明文件。
如何讓所有參與這個專案的人，快速建立本機測試環境
11

腦力激盪
1. 程式跑起來了！！
2. 重新檢視一下 code structure
3. 思考每個資料夾名稱的意義
12

Exercise 2
目標：重整專案結構
延伸閱讀
第二章 Page33-35
對所有內容進行版本控制。
讓腳本處理的範圍可以被明確劃分
13

腦力激盪
1. 試著做一些修改吧
2. 怎麼確認系統跑起來沒問題？
3. 怎麼和其他人溝通？
4. 5 分鐘小組討論時間
14

9/22 小組討論 2
1. 找本人
2. regression test
3. 測試用 branch
4. 加版號
5.
15

Exercise 3
目標：快速掌握系統狀態
延伸閱讀
第二章 Page47-48
每個人都應該能夠非常容易
的看到目前軟體的某個特定
版本部署到各種環境上的具
體設置資訊。
讓每次的變更都可以被辨識，並且在早期定義 Health Check
16

Version
要 release 出去的
使用者面向的
Build Id
內部溝通的
開發測試面向的
18

腦力激盪
1. 什麼是 CI，持續整合？
2. 2 分鐘小組討論時間
19

9/22 小組討論 3
寫完 code 以後，做一些測試，unit test, feature test, test coverage,
確認 build 完成，deploy 到 qa 然後是 production。
20

Exercise 4
目標：內建品質，提交測試
延伸閱讀
第一章 Page26-27
若能在尚未將程式簽入版本
控制之前，就發現並修復錯
誤，代價是最小的。
不用建置就可進行的測試，
或是對單一元件 (或角色) 即可做的測試。
21

Lint (檢查 Coding Style )
Vet (預先檢查 Runtime 錯誤)
Unit Test (最小單元的程式邏輯檢查)
22

腦力激盪
1. 整合測試不同於 Unit Test，需要將整個系統環
境建立起來測試。
2. 人工整合測試 vs 自動化整合測試
23

Exercise 5
目標：自動化整合測試(驗收測試)
延伸閱讀
第五章 Page125-128
提交測試對於多種錯誤的發
現而言，是非常優秀的試金
石。然而，有許多類型的錯誤
是它無法捕獲的。
24
好寫好維護才是重點（可先避免使用者介面測試）

書中自有黃金屋
1. 整個團隊都是驗收測試的擁有者。p127（並非只有 QE 在做）
2. 開發人員必須能在自己的開發環境中執行自動化驗收測試。p127
3. 當執行失敗時，不管是原始碼的失敗或是測試案例的失敗，都一視同仁進行修復，
同等重要。
4. 常見的誤區：手動測試功能邏輯後，就忽略自動化測試的失敗，延到以後有空再
修。
25

腦力激盪
1. 如何建立團隊紀律？
2. CI Pipeline
26

Exercise 6
目標：完成 CI Pipeline
延伸閱讀
第三章 Page55-83
提交前先在本地執行全部的
提交測試，在還沒提交前發
現並修復問題，修復成本就
越低。
27
決定我們要交付什麼東西，Artifact 產出物
建立一個基本提交紀律

腦力激盪
1. 新功能開發完成，通過 UT、和自動化功能測試
後，還需要經過什麼樣的程序，才有把握正式上
線。
2. 5 分鐘小組討論時間。
28

9/22 小組討論 4
1. 部署到客戶的驗收機，給客戶驗收 stanley
2.
29

GitHub Flow
Create
Branch
Code
Commit
Create
PR/MR
Deploy
To
Production
Merge
BackReview
30
We Are Here
Master, 主線, 穩定版本
創建開發用分支

GitHub Flow
Create
Branch
Code
Commit
Create
PR/MR
Deploy
To
Production
Merge
BackReview
31
We Are Here

GitHub Flow
Create
Branch
Code
Commit
Create
PR/MR
Deploy
To
Production
Merge
BackReview
32
We Are Here

GitHub Flow
Create
Branch
Code
Commit
Create
PR/MR
Deploy
To
Production
Merge
BackReview
33
We Are Here

GitHub Flow
Create
Branch
Code
Commit
Create
PR/MR
Deploy
To
Production
Merge
BackReview
34
We Are Here

GitHub Flow
Create
Branch
Code
Commit
Create
PR/MR
Deploy
To
Production
Merge
BackReview
35
We Are Here

延伸閱讀
第十四章 Page407-410
主線開發
不用分支也可以做複雜修改
36

建立一個可被 Review 的環境
1. 登入 GCP，新增一個 project
2. 建立 GCP SQL instance，開啟 ip
3. 新增 GCE instance
4. 登入 gcloud，並指定專案
5. 複製產出物到 GCE instance
6. 修改 default conf
37

腦力激盪
1. 可以部署的產出物要去哪裡拿？
2. 測試人員要自己 build?
3. 大家測的版本都不一樣
38

Exercise 7
目標：所有環境使用同樣的產出物
延伸閱讀
第七章 Page175-177
提交階段的產出物應該一直
在部署流水線的 Job 中被重
複使用，如果可能，最後發佈
給使用者或 Prod 環境。
39
不因環境不同而重新建置
Artifact 產出物管理

40
GCP Storage
QA env
Unipass Artifacts
專案相關人員可存取

建立 GS Bucket
1. 命名是全球唯一的，所以大家的應該都不一樣
2. 我取名為 unipass-earou
3. 事後可以砍掉
41

腦力激盪
1. 設定檔怎麼辦？
42

Exercise 8
目標：加入設置檔管理
延伸閱讀
第二章 Page47
將應用程式的設置與原始程
式碼保存在同一個 repo 中，
但要把設置的值保存在別
處。
43
使用者密碼這類型的敏感資訊不應該簽入版本控制。

44
GCP Storage
QA env
Unipass Artifacts
Config Files 只有維運人員/或是特定執行個體
具備存取機敏訊息的權限
設置檔範例
不含機敏資料的設置資訊
版本控制 Git

Exercise 9
目標：部署策略，完成 CD Pipeline
延伸閱讀
第二章 Page33
為了重新建立測試與生產環
境，將所有必需的資訊保存
起來也是很重要的。
45
Infra As Code

環境建立進化版
1. 手動試跑 startup script
2. Infra-as-code 建立 instance template
3. 建立 instance group 和負載平衡器
4. immutable
46

47
GCP Storage
Unipass Artifacts
Config Files
QA env
Deploy Info

48
GCP Storage
Unipass Artifacts
Config Files
QA env
Deploy Info
PT env
Prod env
Canary env

49
Prod env
Canary env
DNS 服務權重控制
unipass.com
canary.unipass.com
95%
5%

Exercise 10
目標：工具導入
延伸閱讀
第五章
讓測試團隊只要自己點擊按
鈕，就能將某個特定版本部
署到測試環境中。維運人員
也可以用一樣的方式部署到
Production。
51
整個交付期間，全部的人都能具有兩種權利，那
就是他能使用任何他想使用的版本，也能看到整
個發布流程。整個回饋鍊都是透明的。

發行(release) 管理
1. release 後會立刻 commit version file（跳號）
2. tag release & release notes (change log)
52

Exercise 11
目標：加入維運工程
53
收集各個環境的 log，可視化，告警
有良好的 log 資訊才能有好的 feedback

自我總結
1. 腳本都可以重複執行，而且不需而外的說明文件
2. 不同的環境裡面使用相同的腳本
3. 部署策略是實作一個簡單的套件管理腳本。
4. Docker 和 K8S 可以幫我們什麼？
54

環境回收
1. 將資源砍掉
2. 將防火牆關掉
3. 砍掉 GS bucket
4. 砍掉 LB
5. Commit 變更到 fork 專案
55

CICD Workshop 20180922

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à CICD Workshop 20180922

Similaire à CICD Workshop 20180922 (20)

CICD Workshop 20180922