DevOps Culture Establishment from 0 to 1-Infrastructure
一個人可以走很快，一群人可以走很遠，當工程師時，你的成就取決於你的成長。成為管理者時，你的成就取決於你能與你的夥伴走多遠。
這篇是針對落地的實施方針所撰寫的基礎架構篇，精神偏向技術。想知道怎麼演化來的可以先參考
從 0 到 1 的 DevOps 文化建立-我們是如何在兩年半的時間建立 DevOps 文化(上)
從 0 到 1 的 DevOps 文化建立-我們是如何在兩年半的時間建立 DevOps 文化(下)
貫策目標
其實在運作的過程中，我們會以責任共擔、質量導向來當作我們要建立文化的價值觀，所有的行動與動作都會圍繞著這兩個觀念進行與展開，甚至也可以提升為企業的使命。
從 0 到 0.1 ( 2-3人or 都沒碰過敏捷)
在這個階段中，你可能是團隊中技術最資深的，很多問題可能都需要你解決，所以用雲服務是當務之急，你絕對沒有時間再去管理自建工具。
以傳統方式來說，通常都會先出 SA、SD，文件，但效果來說並不好，這種文件難以根據需求與進度來調整與變動，尤其在現今軟體設計架構下，並不好去配合敏捷開發，但並不是說他不重要，這些文件應該參與在 UX 設計下的需求訪談、Flow、wireframe、prototype，這邊後續會以其他文章的形式出現，今天會先專注在開發面的 DevOps、SRE。
GitOps
這個項目中，我們在乎的是先讓團隊成員熟悉這種開發流程，透過版本管理工具Git 來解決持續集成(CI)的問題。我們選用的服務是 Bitbucket。在第一個小階段我們使用的卡片服務是 Trello 對於剛有敏捷觀念的開發這來說，先上手這兩個東西應該是很好的切入點。
卡片中的內容除了需要描述用戶故事之外，可能也還需要提供他可能的撰寫邏輯，否則很可能會有看著卡片發呆的情況發生。
持續集成的部分一定要告訴開發者，他要切分支出來開發。這階段可以不強制開功能分支來開發（時程、交付速度都要考慮），但一定要養成 PR、Code Review 之後，並入主分支的習慣，即使是主推人也要執行。
注意，你在執行任何過程時，所認為的這次算了沒差，下次記得就好，都會降低一點你的成功率。
ChatOps
我們希望團隊中所有人的變動與更改，都被其他團隊成員所關心，個人認為這是 DevOps 有成果很重要的因素，當團隊成為互相關心彼此做的事情、了解彼此做的事情，這時候效益就會慢慢發酵，大家的多點連線漸漸成為了一個結構體，對於專案會顯得更扎實。這個項目中我們引入了Slack，並且將上面的 Bitbucket 與 Trello 綁定其中，當有更新時，自動發消息在 Slack中。
挑戰
剛引入這些所謂敏捷開發的工具時，沒有經驗或者被舊經驗所困住的開發夥伴們，一定都會有點茫然，而且主推者有可能很難去推行這流程，因為大家不習慣。這個階段要培養的一定是團隊成員彼此的關心與想要利用這套工具的誘因。這邊可以分享幾個經驗給大家。
- 不厭其煩的提醒需使用
– 比方說團隊成員完成了某張卡片，但卻沒有更新狀態時，一定要很明確的說「那記得在拖曳一下卡片讓大家知道」。 - 遊戲化
– 在卡片上分配點數，當一周衝刺完了之後，大家可以看到自己得到多少點數– 這個點數可以設計在企業內部可以提供兌換，或者獎勵，目前打算配合企業內部系統來達成（這個我們也尚未達到，關於遊戲化設計工作，可以參考遊戲化實戰全書） - 密集的短暫開會
– 注意是密集的短暫，比如說先施行站立會議，因為這有助於團隊成員彼此縮短距離。有時候一個成員描述完之後，也可以問一下其他成員，他說了說了什麼，理解嗎，有什麼建議，一開始會很扭捏，但是習慣了就好，現階段最重要的是習慣。 - 提供安全的心理支持
– 這個過程中需要大量的向團隊成員提供安全的心理支持，可以讓他們覺得天塌下來有你扛等等，這個初期的階段需要安全感 - 剛學會開發的新手
– 如果是剛會開發的新手，這邊絕對要再更謹慎，這個階段的新手比較適合指令式的工作，可以觀察三個月，若三個月後他還是無法自行解決問題、無法自學、無法上手新概念，這時候要考慮轉崗或放棄。 - 概念演說、技術指導不能少
– 在這過程中一定要常常讓大家了解敏捷是什麼、多實作與練習– 定期的宣導新的概念與學習目標，可以用每週一概念循序漸進地讓團隊成員了解。
現階段架構展覽
這個部分可以先不花心力處理單元測試問題，我們都知道需要寫單元測試，但實際上他需要更長時間的習慣養成。
這個階段的金錢上成本可以說幾乎為零，最大的成本是要讓團隊成員熟悉與了解這個過程與項目（這成本很巨大），這個期間應該會持續 3-6個月，根據成員的熟悉度而不同，在這期間如果能發現團隊成員對於敏捷的概念熟悉或學習很快，對於下一階對是很有幫助的。你可能會在這階段灰心喪志，這個過程是最艱苦與困難的，但千萬不要放棄。（以我們的經驗來說大約持續了 4 個月才免強進入下個階段）
0.1 to 0.19 ( 3-5人, 稍微有點敏捷經驗)
這個階段的團隊成員們應該都已經熟悉上個階段的流程與工作了，這個階段可以使用 bitbucket 上的一些 pipeline 功能，可以先至少讓整個專案是可以建置的，確保都是可以執行的程式。也須將這些結果串接到 ChatOps 中，目標是讓團隊成員開始重視自己的程式碼品質與責任感，看到 pipeline 失敗了應該馬上去想辦法修復。
這個階段的另外一個目標是，讓大家開始寫單元測試，以及簡單的需求下，可以自行設計與功能開發，順利的話，這階段的 CI 應該是非常完整的。
這階段可能 1-3 個月就會有成果了（以我們的經驗來說是 2 個月，這 2 個月我先大致上完成了Backend、iOS、Android、Web 的 Pipeline，以及要求到 50 % 後端的單元測試覆蓋率）
這階段完成應該會非常安心，至少不用擔心下次打開是不能執行的 Code 了。
0.19 to 0.29
這部分的跨越可能是面對更複雜的需求時，除了PM 的需求分析能力外，還要引入 Sprint 的概念，這階段 Board 工具換成了 jira，並且引入了衝刺的概念，加上功能分支之的執行。一張卡片應該對應一個功能分支，並且在 jira 卡片上是可以追蹤的。另外也需要把 jira 集成到 ChatOps 裡面。
這邊帶上 Sprint 的概念後，差不多也需要 1 個月的時間熟悉，這邊盡可能地要在引入週一的衝刺需求會議與週五的評審會議（以新手 Sprint 來說，我們的經驗是一週 1 個 Sprint 比較不容易走偏）
0.29 to 0.5
本質上就是部署管理、環境管理。
這階段最重要的是要把 CD 建置完成，其實能力與時間允許的話，可以跟 CI 的階段一起做，這邊都可以主推者來把這些基礎設施弄好，讓你的團隊成員只要專注在需求開發實作上。
這邊的例子會拿雲上的一些應用來當作範例，流程與概念都是不變的，但要根據不同的環境與架構來抽換工具與流程，同時也會建議讓應用容器化，對你的 CD 絕對是幫助的。這個階段會建議把整個系統從後端開始做 CD，因為後端可能來自不同前端的串接與資料處理，通常會是整個系統最核心的部分，也是最容易出錯的部分，所以要儘早把核心部分做好 CD，確認每次交付的軟體都是符合預期的。
以我們的例子來說，我們利用了 GCP 的 Cloud Build 幫我們把後端都建置在 kubernetes 的環境中，對於我們現階段來說是更適合不過了，自建與架設工具是現階段應該盡可能避免的，因為會造成額外的穩定與維護成本。
以我們後端的流程架構就會如下圖，當然個別應用中的開發建置是更複雜的，這時候開發方法論中也不能少，DDD 與 微服務 的設計，可以讓你在 CD 中更好的去交付軟體。
0.5 to 0.7
接下來就是把所有系統項目都加入 CD 了，因為各個平台交付的方式有所不同，這邊以 iOS、Android 、Web 為例子如下圖。這邊就不畫出測試環境與正式環境了，但至少都要分出這些環境。
我們的 iOS 、Android 是透過 fastlane 部署的，若有興趣的可以先參考這篇 iOS App 環境管理 : 靈活運用 Xcode Scheme、GitLab 和 Fastlane 設置不同的開發環境
Web 都是透過容器化進行部署，也比較會放置在 KNative 這種環境中。
恭喜你，走到了這個階段後，團隊成員基本上對於 DevOps 文化已經稍稍了解了，日常的建設基礎 CI/CD 基本上已經成形了，我們的經驗是，不要太在意工具，先以概念、以文化先行，讓大家先知道，為什麼要做這件事情，有什麼好處。
最後開發流程最基礎的應該有以下步驟：
- 領到卡片任務
- 查看卡片任務中的用戶故事與目標
- 查看卡片中建議的設計
- 拖曳卡片至執行中
- 創建新的功能分支
- 執行軟體設計與實作
- 撰寫單元測試
- 提交分支並且發送 Pull Request
- Auto Run Pipeline 執行建置、測試
- 確認 Pipeline 執行成功後拖曳卡片到 Review
- 如果失敗必須修正後重新提交
- 進行 Code Review
- 合併到 develop 分支
- 合併後自動觸發 CI/CD
- 自動建置、測試、部署
- 自動 打包 docker image
- 自動推送到 Private Container Repo
- 自動部署到 Kubernetes 中
- Slack 通知完成
0.7 to 0.99
這階段的最重要的目標是持續努力、培養團隊成員也理解這些概念，這個階段可以開始更深入的探討方法論、執行細節與項目，並且要建立屬於自己團隊的 Wiki ，以我們團隊來說是用 notion 來執行。
並且同時要適當的讓團隊成員主導某些流程、開始引入數據呈現，讓每一個成員都可以體驗這個文化的好處。主要概括有以下幾項
- 多邀請大家參與社群活動
- 多在內部舉辦頭腦風暴，凝聚大家的想像力也加強合作
- Scrum 會議中更鼓勵大家提出想法與問題，還有想討論的事項
- 以文件驅動工作流程，比如功能設計後要附上一張流程圖
- 透明化每個專案，讓每個成員都可以有靈感或創意時提供意見
- 量化指標
– 交付效率
– 開發時間（這邊目前我們使用 jira 的時間記錄功能）– 交付目標
– 交付頻率– 交付吞吐量– 交付質量
– Bug 密度– Bug 分佈– 故障修復時間 - 混沌工程
- 數據儀表板
- 持續進步
– PDCA
總結
人 + 流程 = 文化
DevOps 中的三大支柱 人、流程、與平台，其實我們建置的過程中，一直圍繞著這三大部分，深深的體認到，人參與進來是非常重要的，如果感受到你的團隊成員只是把他當一個流程時，會有一些無力感，會覺得希望他們更 join 進來。
以上就是我們稍微有一點點成績的 DevOps 文化與基礎設施。我認為工具真的不能，最難的是人的部分。大家一但養成了，責任共擔、質量導向，其實就離初步的 DevOps 不遠了。
工具的使用與方法論其實都沒有實踐來得難，我們需要知行合一，才有辦法培養敏捷、DevOps 文化，讓團隊成員都有多多少少的系統思維，能夠適時的以大局觀看到與更了解整個系統的樣貌，也鼓勵在這種 參與進來 的氣氛中工作，而不是離得遠遠的感覺他只是工作。遊戲化、興趣化、大家為了某一件事情努力的這種氣氛。
這就是我們實踐的過程，希望對讀到現在的你妳有些幫助。這就是目前我們的故事，當然，故事還在繼續進行，我們也開始要跨越到0.99 到 1 的階段，這才是開始！接下來會再繼續分享，我們如何結合敏捷、DevOps、Lean UX
你也有你的故事嗎，歡迎也分享給我。
澄思設計-沈思世界的解決方案
解決問題的路上，也給大家解決過的問題不同的角度思考方案，包含軟體工程、架構、使用者體驗、專案管理等方法論。澄思設計以顧問的角色，積極解決客戶的問題。理解客戶的想法，這個客戶不一定是企業，也可能是個人，解決企業問題，我們使用專案解決，解決個人問題，我們使用產品解決。我們想要找的人，是能夠解決這個世界上各種大大小小問題的人，無論是透過溝通、技術解決，同時他應該會有積極與強大的自學能力，對於解決問題充滿熱誠，與團隊、與公司共同搭上火箭成長，那你可能就是我們要找的人Klearthink Design Co., Ltd.
如果你對我們公司有興趣，歡迎參考我們的職缺，我們有機會聊聊吧 :D
職缺參考
—
yasuoyuhao，自認為終身學習者，對多領域都有濃厚興趣，喜歡探討各種事物。目前專職軟體開發，系統架構設計，企業解決方案。最喜歡 iOS with Swift， [email protected]。
如果喜歡我的文章，可以按下喜歡或追隨讓我知道呦，拍手可以拍 50 下，更歡迎許多大神指點討論。感謝您的閱讀。
部落格：yasuoyuhao’s Area