導入 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,團隊要能夠有部署的 自主權,部署到 各式需求 的環境,要能做到這些的前提:

  1. 清楚的 系統架構圖,不知道架構是部署心酸的嗎?
  2. Provision 完整的 Environment,包含 Infra、Network
  1. 公開的 Artifacts Storage Service,讓其他人可以自行部署。
  1. 清楚的 Configuration 文件,使用單位自行維護
  2. 透過 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

問題:沒有技術能力怎麼辦?

有些人員沒有技術背景啊?怎麼可能要他們部署呢?

兩個方法:

  1. 把部署做到 One Button
  2. 透過教育訓練:
  • 實務的經驗,長久來看,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 寫的草稿,原文在 這裡.


延伸閱讀

引用

更新紀錄

  • 2019/01/13: 註記原始草稿
  • 2018/10/20: 增加 Artifact 重要性的錄影說明。


Comments

2018/03/20 22:20:00





  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲