領域驅動設計學習筆記（3）：實驗計畫

Nov. 4 11:25~12:20

 

這禮拜Teddy在北科大兼任的「敏捷與精實軟體開發」課程進度來到DDD（Domain-Driven Design；領域驅動設計）與Microservice（微服務），Teddy將修課學生分成：

• 專案經理（1人）
• 分析師（2人）
• 開發人員（6人）
• 測試人員（4人）
• 維運人員（3人）

學生採用看板方法（Kanban Method）一起合作共同開發一個軟體專案，該軟體系統將以Microservice的形式存在，透過看板方法將不同專長的人在開發流程中串接起來，期望這個專案可以達到DevOps或是至少做到Continuosu Delivery（持續交付）的程度。

***

這是Teddy第三年在北科兼任「敏捷與精實軟體開發」，往年課程內容以看板方法、XP為主，Scrum與精實開發為輔。這兩年因為DevOps炒得很熱，今年在規劃課程的時候便思考能不能讓學生也體驗一下DevOps。談DevOps不能只講工具，必須從敏捷精神、流程、架構、設計、團隊組成著手。但一學期只有18週，怎麼在這麼短的時間涵蓋這些課程內容也是挺傷腦筋的。

幸好上學期Teddy兼任的另一門課「軟體生命週期管理」三組學生共同開發一個專案，這個專案的功能已經完備，但軟體架構屬於傳統的Monolithic（一整坨），剛好可以拿來讓這學期「敏捷與精實軟體開發」的學生使用，重新改寫成Microservice架構。如此一來學生不用花太多時間開發功能，只要把心力放在Microservice、整合以及最終的DevOps或持續佈署即可。

▼上學期三組學生跑Scrum，依據泰迪軟體的需求所開發出來的系統主畫面

 

實驗結果如何，等期末Teddy再向鄉民們報告。

***

友藏內心獨白：學東西就是要串起來。

DevOps技術簡介

July 25 22:05~00:00

▲DevOps基礎生產與佈署流程，參考文中論文重繪

 

今天介紹另一篇也是刊登在今年5/6月IEEE Software的文章，標題只有一個字：「DevOps」。這篇文章深入淺出介紹DevOps概念以及所牽涉到工具。

***

DevOps觀念

DevOps是關於如何快速且有彈性地開發與供裝（provisioning）商業流程的一門課題。DevOps有效率地整合開發、交付及維運，讓這些傳統上隔離的孤島可以精實且流暢的連結在一起。DevOps牽涉到開發、品管與維運部門。為了達成上述目的，DevOps運用自動化的方式在以下三個領域：

• 開發
• 佈署
• 基礎建設的監控

DevOps不是只有自動化工具的採用，而是組織結構與流程的改變，將傳統各行其事的部門串接起來組成跨職能團隊，以便持續提供客戶服務。

***

DevOps工具

該論文將DevOps依據階段不同分成三類：建構（Build）、佈署（Deployment）、維運（Operation）。再依據工具類型區分為建構（Build）、持續整合（Continuous integration）、配置管理（configuration managment）、日誌記錄（Logging）、監控（Monitoring）。請參考下圖：

▼DevOps自動化工具，參考文中論文重繪（CI: Continuous integration；CM: Configuration management）

***

其他

文章還提到幾個與DevOps相關的議題：

• 真實世界的DevOps：介紹Amazon Web Services（AWS）的幾個工具，包括AWS Elastic Beanstalk、AWS OpsWorks、AWS CloudFormation、AWS CodeDeploy、AWS CodePipeline、AWS CodeCommit、AWS CloudWatch。
• 微服務（ Microservices）：微服務出現在10年前，是服務導向設計（service-oriented architecture；SOA）的後續演化結果。微服務拆分複雜的軟體架構以達到隨選交付服務以及提升效能。DevOps可以協助開發、佈署與管理微服務容器生態系。
• 文化轉移：文中提到四種主要的挑戰：
  • 將複雜的軟體架構與功能集切分成可獨立開發與佈署的小區塊模組。
  • 維護一個配置與建構環境以便清楚了解佈署服務或元件的版本與相依性。
  • 引入一個從傳統應用程式生命週期管理所衍生的特意建構之開發與生產環境（這一點看不懂）。
  • 橋接傳統上各自為政的開發與維運文化。

此外，在DevOps文化中，開發人員必須採取全端開發策略（full-stack developer），負責開發、測試與釋出環境。除了coding以外，他們還必須擴展資料庫管理與測試等能力。測試與持續整合對開發團隊都是必須具備的工作，測試人員可以和開發人員一起結隊開發，雙便皆可因此獲取更多技術知識。品管團隊則需要確認自動化所有測試案例以及程式涵蓋率。維運人員則需要更緊密的與開發團隊協作，以達成持續提供服務的目的。

***

結論

最後直接引用論文結論中的兩句話：

• Building on lean and agile practices, DevOps means end-to-end automation in software development and delivery.
• Because products and life-cycle processes vary, each company needs its own approach to achieve DevOps, from architecture to tools to culture.

***

友藏內心獨白：最後一段麻煩自己英翻中。

DevOps：更容易做正確的事

July 22 22:50~00:00; July 25 09:50~11:15

 

▲圖片節錄自Google搜尋結果

 

今天介紹一篇刊登在5/6月IEEE Software 的文章：「DevOps: Making It Easy to Do the Right Thing」。文章主角是澳洲最大旅遊電商平台Wotif集團，旗下擁有Wotif.com和多個品牌（該集團在2014年底被Expedia收購）。在2013到2014年間，Wotif大幅整修他們的軟體釋出流程，將平均釋出時間從數週降低到數小時。文章介紹他們採用DevOps與持續交付（continuous delivery；CD）縮短釋出時間的經驗。

***

背景介紹

2012年時Wotif公司的工程部門有約170名員工，其中包含：

• 一個集中的營運團隊包含11位系統與資料庫管理員。
• 約60位開發人員。
• 30位測試人員。
• 15位業務分析師（business analyst）分佈在三個不同城市的12個開發團隊中。

以上人員約有20%（23人）不參與本篇文章所介紹的DevOps活動，也就是說實際牽涉人員約93人。

雖然工程部門的管理相當扁平，只有三個階層，但是他們的釋出流程卻非常的官僚。在產品釋出的前幾週就要先預定時間，但為了「夾帶」高優先權的功能，釋出的內容往往拖到最後一刻才決定。釋出流程並須經過層層關卡的檢查，例如所有釋出功能都要經過48小時的效能測試。

因為釋出流程很麻煩，團隊便想要塞進更多跨功能的異動到每次的釋出中以便減少釋出的次數，但卻因此造成每次釋出的內容變得很大一包，更增加釋出前的準備工作。如此一來團隊就很難滿足企業對於快速上市的需要，而且也沒時間去處理技術債。

為了解決這個問題，工程部門決定把延用了八年的Java EE架構改成微服務（microservices）。雖然在架構上他們覺得微服務有其優勢，但為了微服務卻引入更多的釋出工作因為他們必須要手動佈署與測試每一個微服務。結果原本的問題沒解決之前，還產生更多的問題。

因為導入微服務，不同部門所撰寫的微服務行為並沒有統一的規定，例如啟動服務的腳本、設定檔、管理端點、日誌檔的位置等等。這些問題又讓釋出的流程更加複雜，也造成維運團隊的困擾。

***

定義對的事

為了解決上述問題，Wotif成立一個CD團隊（持續交付團隊），包含兩個開發人員、一個系統管理師與一個流程改善業務分析師。該團隊採取一些策略來縮短釋出時間：

• 找出釋出流程的瓶頸，也就是只有11人的營運團隊。
• 藉由標準化應用程式包裝與佈署的機制來改善開發與釋出流程的一制性與可預測性
• 採用漸進式改變來擴充、精簡與自動化現有的基礎建設與工具。例如，繼續使用他們現有的資料中心，而不是把平台改成公有雲。

經過與開發團隊以及營運團隊的溝通，CD團隊整理了一份輕量級應用程式佈署標準，含蓋約30個規範，包含日誌檔位置與格式、初始化腳本位置與呼叫方法、配置檔位置、應用程式打包規範等。

***

簡化

CD團隊採取以下方法簡化開發與維運團隊實作上述標準的時間：

• 提供自動驗證測試套件（採用Fabric Python SSH函式庫開發），透過基本的Linux指令檢查每一個應用程式佈署之後，系統與程式是否正確。該驗證套件在開發人員每次提交程式碼時會在驗收測試環境中自動執行。
• 提供helloworld-service參考實作，該服務會被佈署到包含production的所有環境，用以展示與測試點到點（end-to-end）的佈署自動化過程。當Frbric Python版本升級時，它也做為自動驗收測試案例，確定此次版本升級沒有造成問題。helloworld-service也做範本，開發人員可以直接從它開始撰寫新的服務。
• 開發DevOps toolchain達成佈署與測試自動化。該DevOps toolchain包含Git、TeamCity、Yum、Hiera、Puppet，用Fabric Python將這些工具串起來，用以替代原本手動釋出的工作。為了測試服務的正確性，開發團隊需要針對每一個服務提供smoke test腳本。自動化佈署與測試完成之後，節省了85%的佈署時間，將原本需要幾個小時的時間縮短成幾分鐘。
• 要求服務必須獨立釋出。做到上述三點只解決各別服務佈署的問題，但是一個系統是由多個服務所構成，很有可能因為其中某一個服務升級，導致與其他服務發生不相容的問題。為了避免這個問題，所有的服務被要求必須要提供向下相容性，以便可以獨立釋出又不會影響到原本正常工作的其他相依服務。
• 訂定新的釋出流程，包含以下五項規則：
  • 讓異動獨立（keep changes independent）
  • 釋出過程不可以有人工測試
  • 不可以預約釋出時間
  • 應用程式必須符合最新的佈署標準
  • 維運人員可以將服務退回到之前的版本

在落實新的產品釋出流程之後，平均產品釋出時間從2週縮短到1天。

***

聽到DevOps許多人第一個印象就是找一堆工具來自動化測試與釋出流程，由這篇文章可以知道，工具與自動化只是其中一環。在自動化之前，必須找出流程上的瓶頸，接下來才能擬定改善計畫。如果流程沒有改變（改善），只是希望透過自動化工具加速錯誤流程的時間，就算是戴上DevOps這頂流行的帽子也不會讓你的團隊與產品看起來好棒棒。

怎麼找出瓶頸？最後置入性行銷，打個廣告：歡迎參加8月18日舉辦的「瓶頸遊戲：運用五步驟聚焦法持續改善流程」工作坊。

***

友藏內心獨白：要先do the right thing再do the thing right。