導入 CI/CD 的第一步
先不談 CI/CD 的定義，或者 DevOps 是啥。
企業導入 CI/CD 的第一步，先在內部解放 Build / Artifact / Configuration 的觀念，目的是要讓 Developer 以外的人員，能夠獨立部署產品，獨立確認產品的樣貌，提高靈活度。
- 如果開發出來的軟體，無法讓開發人員以外的人自行安裝或者部署，那麼這整個開發流程就是不敏捷。
- 相關參閱 Artifacts Management
前言
問題：團隊裡，「誰」能夠去 CI Server 按下 Deploy 的按鈕？
如果這個按鈕只有單方面有，那離 DevOps / Agile 精神還很遠。然後，我沒有說 Deploy 的受詞是哪裏喔，也沒說是單數還是複數喔 …. 文法公式如下：
[主詞] [動詞: Deploy] [受詞]
其中:
- 主詞：換成 Developer 以外的成員，像是 QA / Technical Support / Sales / HD …
- 受詞：可以是自行建置的環境、自己的電腦、Cloud … whatever …
例子：
- [Developer] 部署 到 自己的電腦
- [Developer] 部署 到 測試環境
- [Developer] 部署 到 正式環境
- [QA] 部署 到
Env1 - [Support] 部署 到
Orz - [Operator]] 部署 到
Luffy
需要前述的 CD 使用情境？ (2018/04/13 Updated)
前面講 Support 部署到某一個地方，真的有這樣的需求？
CD 除了部署到正式環境，讓新功能上線，為公司帶來價值與獲利。另外把線上的狀況，還原到 Lab 也是很重要的，常見的使用情境：
- 找功能性問題：商業邏輯錯誤，通常是資料性的錯誤，需要離線確認
- 找效能議題：還原某一個時間點附近的狀況，找問題，像是 deadlock、memleak、網路 …
- 找無法復現的問題：有時候 Production 會出現偶爾才出現的問題，很嚴重，但是很難復現。為了不影響 Production，最好是複製整個環境在 Lab 重複測試。
我們曾經為了找效能議題，複製整個環境，然後最後發現問題卡在 NAT Network Throughput。
各種測試的階段參考： 淺談軟體測試的階段與策略
驅動部署的角色與情境
Developer 寫好 Feature 後，基本的要做到的是可以 Build 成 Artifacts，這個 Artifacts 放在共用的 Storage Service，至於 Deploy 誰來驅動，是由 需求者 自己決定，不是單方面的，否則是很難敏捷的。
底下的例子都是 Engineering 的角色，實際上其他像是 PM / Techincal Support / HD / Sales 也可以做：
QA / Tester要做商業功能性測試時，部署到自己的環境，開始執行 Testcase / 驗證，或者跑 Automation (Regression, UAT)。Automation Test Engineer做自動化程式開發，開啟 Provision 的環境，部署最新的 Artifacts，配置 Configuration，準備測試資料，開發測試程式。Performance Engineer做效能測試，Provision 完整個 Production Scale，然後部署最新的 Artifacts，配置適當的 Configuration，還有適當的資料，執行效能測試Release Engineer開始 Release，把 Artifacts 部署到 Production 或者 Sandbox (A/B Test)。
前提
前述負責部署的人，都不是 Developer，團隊要能夠有部署的 自主權，部署到 各式需求 的環境，要能做到這些的前提：
- 清楚的
系統架構圖，不知道架構是部署心酸的嗎? - Provision 完整的 Environment，包含 Infra、Network
- 技術：
Infra as Code，像是 CloudFormation, Terraform.
- 公開的 Artifacts Storage Service，讓其他人可以自行部署。
- Artifact 要定義好 Version Number, Naming
- 清楚的 Configuration 文件，使用單位自行維護
- 透過 Configuration Management Tools 配置，像是 Ansible, Chef, Puppet, CodeDeploy
這些事情過往是有難度的，但後來有 VM (VMware / Virtualbox) 之後就簡單多了，後來有 Cloud (IaaS) 也容易多了，現在有 Container 根本就是 基本功 ….
前提的補充說明（Updated: 2018/10/20)
底下的 Youtube 是摘錄我在內部教育訓練的影片，主要說明這段 前提 重要性，以及 讓團隊在技術上自主性 的重要性。相關的關鍵字有：自主性、DevOps, Architecture, CI/CD, Provisioning, Infra as Code, Artifact Management
問題：沒有技術能力怎麼辦？
有些人員沒有技術背景啊？怎麼可能要他們部署呢？
兩個方法：
- 把部署做到
One Button - 透過教育訓練：
- 實務的經驗，長久來看，RD / QA / Ops 都應該要知道怎麼做這件事情，不是只有特定的人。
- 投資教育訓練對企業是有價值的事
問題：怎麼叫做好了？
環境總算有能力建置了，有人可以安裝了，可是怎麼知道系統好了？什麼叫做好了？
想像一下：
- 裝 ELK (Elasticsearch, Logstash, Kibana) 的時候，你怎麼確認他是好了？
- 裝了某一個用 Docker 封裝的工具，例如 Redmine 跑起來之後，怎麼知道他好了？
- 想像裝了 Hadoop 這種分散式的工具，裝好了之後怎麼知道他好了？
很簡單，打 API ，如果可以取得版本資訊就是好了。確認開發的服務有定義版本資訊這些東西，每次 Build 都要 Bind 進去。詳細參閱 Version Control
更嚴謹的，可以透過 Health Check Pattern 做，請參閱 淺談系統監控與 CloudWatch 的應用 P16-29 的說明。
不做會怎樣？
如果只有 Developer 能做，那整個公司發展到一定程度之後，就會卡在這裡，：
- 整個開發速度會越來越慢
- 系統越來越複雜，沒人知道全貌
- 溝通成本 越來越高，因為沒人能看到系統全貌
- 沒人能完整部署整個系統，因為部署也不知道怎麼確認
- 公司長不大，只能做固定的生意，等著被併購
然後公司會不知道為什麼請了很多人，但是東西就是出得很慢，找了敏捷教練，找了外來的和尚，但是總體就是原地踏步，最慘的就是，還不知道為什麼會這麼慢。。。開始找外面的領導統御課程來上課、挖高手、空降。。。然後問題放在哪裡沒人管。
DevOps Engineer or Release Engineer
這整個 Pipeline 誰來串？CI Server 上 Deploy 按下之後的事誰來做？我以前稱 Release Engineer or 潮一點的說法 DevOps Engineer … 這件事很難嗎？我覺得至少看到整個流程的人才可以掌握，然後技術要有一定深度的，所以他通常會是 Senior Developer or Senior Operator。
這是 AWS 定義的 DevOps Engineer 條件：
- Implement and manage continuous delivery systems and methodologies on AWS
- Understand, implement, and automate security controls, governance processes, and compliance validation
- Define and deploy monitoring, metrics, and logging systems on AWS
- Implement systems that are highly available, scalable, and self healing on the AWS platform
- Design, manage, and maintain tools to automate operational processes
如果這件事很簡單，或者不重要，阿貓阿狗都可以做的來，那請忽略這篇文章，繼續用你熟悉的方法做。
詳細請參考：AWS DevOps Engineer
他有屬於自己的技術生態圈 (Ecosystem)，常見的像是 Gitlab, Jenkins, CircleCI, Travis, Rest, AWS CodePipeline, Drone …. etc.
如果要說
DevOps是文化，我覺得那只對一半，文化跟工程是相輔相成，不會有衝突，精神跟肉體都要有。只有靈魂，那就只能觀落陰；只有肉體，那就跟殭屍沒兩樣。
老人經驗談
上述，是我六年前 (201203) ，到新創公司時，做的第一件事情。這段在 協同合作系統建制與導入 - 以 Redmine 為例 的 Version Control and Autobuild 有描述部份。但其實沒有特別強調，因為對我來說這是軟體開發過程很基礎的工作。
在更早之前，我也做過類似的，只是是把 Build 的東西，串到我的自動化測試平台。這段則是在 Designing Test Architecture and Framework 有描述到。當時把米國 Build Images Mirror 回台北，然後把 Build 資訊塞到 Database，讓 Automation Test 做報表使用。
我從工作第一天就有 Daily Build / Source Control + Defect Tracking 這樣的東西，開發過程一直都習慣這樣的模式。
所以 持續整合 這件事情一直是 built-in 在我的身體裡的，或許也是這樣，後來我不管換啥工作或者 Project，只要沒這段，就會想辦法主動補上。。。
IBM CMVC: Source Control + Defect Tracking:
掉書袋
這年頭，要掉掉書袋，底下摘錄自 持續交付 (Continuous Delivery) 中文版 - P17，跟我前述說的概念是一樣的。
然後這件事情，很重要！
原始草稿
這篇文章是 2018/03/20 我在 Facebook 寫的草稿，原文在 這裡.
延伸閱讀
- SQA
- CI/CD/Automation
- 協作管理
引用
更新紀錄
- 2019/01/13: 註記原始草稿
- 2018/10/20: 增加 Artifact 重要性的錄影說明。
Comments
About
著作
演講
AWS Certifications
