91APP 電商技術大解密 (2020 線上分享系列)：DevOps 時代下的前端工程師

主題：DevOps 時代下的前端工程師
講師：梁瑋哲（Ted Liang) Android Team 部門主管

在 DevOps 時代，不論你是前端、後端或全端工程師，似乎在 DevOps 的大旗之下每位工程師的工作模式都必須隨著時代而有所進化與改變。這場 Session 我們將會聊一聊 91APP 的前端工程師在經歷團隊的 DevOps 轉型之後產生了哪些化學變化，一窺前端工程師的 DevOps 進化之路。

Youtube: https://youtu.be/GINqcckwwoI

91APP Tech Network: https://www.91app.tech/
91APP Tech Group: https://www.facebook.com/91apptech/

Transcript

1. DevOps 時代下的前端工程師 Ted 1
2. About few years ago 2
3. I am Ted • 一位 App 工程師 ◦ 主修 Android • 負責 ◦ App 開發 ◦ App 上架 3
4. 自動化工具 app 上架 app 製作 客戶 app 概觀 自動化工具 4
5. • 時程不同 • 跨團隊協作困難 • app 的 Scope 越來越大 • 部署時間過長 1000+ 客戶 • 測試團隊重複測試 優惠券列表 商品頁顯示優惠券 購物車使用優惠券 首頁 UI 優化 分類頁 UI 優化 商品頁 UI 優化 購物車新增付款方 式 購物車新增運送方 式 購物車新增折扣活 動 A B C 5
8. 想像有這樣的一個世界，產品經理，開發人員，QA人員，IT運維人員 和信息安全人員互相幫助，齊心協力，整個公司的業績蒸蒸日上. 他 們朝著一個共同的目標努力奮鬥，建立從產品計畫直至功能上 線的端到端的快速服務交付流水線 (例如每天執行幾十次， 數百次甚至上千次代碼部署)，在系統穩定性，可靠性，可用性和安 全性方面均達到了世界一流的水平 from: DevOps 實踐指南 8
9. 所以 DevOps = CI/CD? NO!! 我認為是藉由： 1) 建立文化 、2) 賦能給團隊 、3) 讓團隊有能力改善現場的問題 進而能夠應付變化多端需求的一種方法 也就是賦予團隊彈性，讓團隊能夠適應改變 9
10. Devops 三步工作法 流動原則 看見全貌，消除等待，消除浪費，持續改善 反饋原則 快速得到反饋，確保品質 持續學習與實驗原則 建立持續學習，改善，安全，分享的文化 10
11. 回到我們的問題 11
12. 問題是什麼 1. 各個平台需要暸解對方的 domain know how 2. 各個平台因語言隔閡互相幫不上忙 3. 開發流水線需要多個團隊協作 問題是 app 開發團隊沒辦法 end to end 解決他們想解決的問題 自動化工具 app 上架 app 製作 客戶 自動化工具 12
13. 自動化流水線 自動化上架工具 自動化 build 工具 自動化流水線 自動化上架工具 自動化 build 工具 app 製作 客戶 app概觀 賦能 13
14. • Pros: ◦ 開發流程簡單 • Cons: ◦ 測試人員要測很多次 ◦ conflict 很大包 14
15. • 問題是什麼 ◦ branch 待在外面太久 ◦ 測試團隊測試多次 ◦ 所有的團隊改同一份 codebase 15
16. 分支策略 1. Feature Branching 2. Continuous Integration reference:https://martinfowler.com/articles/branching-patterns.html 16
17. 我們做了調整 trunk based development release branch 17
18. real case 1. 盡可能小包的 Pull Request 2. 教育訓練 ＆ 利用 release manager 提醒，事件通知 3. 並不會將所有功能都加上 feature toggle 4. 還是會有 branch 會放比較久一點才 merge 原則： 1. 讓團隊成員了解做這件事情的目的 2. 公開透明，讓大家看見全貌，了解目前有哪些專案正在進行 3. 討論保持彈性避免無意義的制度化 18
19. Deploy QA 19
20. UT Lint 確保 develop branch 的健康 1. 如何確保 code 的品質 a. 跟 testing 要測項，RD 自己測過 b. Unit test 2. 如果進版的 code 有問題，快速 revert rollback 20
21. UT Lint Integration Test Rollback if failed Deploy QA 21
22. Trunk Based Development 帶來的好處 1. Conflict 變小包 2. 測試只要測一次 3. Deploy 信心度提升 4. RD 主動確保品質 22
23. 好的架構 • 擴展性好，易於開發，職責明確 ◦ 高內聚，低耦合 ◦ 職責明確 ◦ 團隊成員協作順暢 • 單體架構 ◦ 開發快速，什麼東西可能別人都已經幫忙寫好了 ◦ 很難暸解整體架構，架構複雜 ◦ 邊界不清楚 ◦ 改了一個核心東西之後要測試的範圍會相對大 • 微服務 ◦ 獨立性 ◦ 服務間溝通較複雜 23
24. 康威定律 • Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure. ——Melvin Conway, 1967 • 產品的架構通常會對應到組織的架構，工作溝通方式，如果刻 意違背則會增加溝通的障礙 24
25. 再 recap 一次我們的團隊 優惠券列表 商品頁顯示優惠券 購物車使用優惠券 首頁UI優化 分類頁UI優化 商品頁UI優化 購物車新增付款方式 購物車新增運送方式 購物車新增折扣活動 A B C 會員登入 會員資料 會員等級 D 25
26. App Api Base Login Member ShoppingCart Promotion Shopping 26 1. 產生領域專家 2. 限縮修改範圍 3. 保持彈性 4. 降低code conflict
27. 其他改善的項目 • 每次上架 1000+ 個 app 花的時間很多，又需要很多人力 ◦ 原本放在機房，只有 5-6 台機器 ▪ 成本高 ▪ 機器隨時可能壞掉 ▪ 再好的機器放 3 年也是變普通的機器 27
28. 其他改善的項目 Master Slave-Spot Slave-Spot Slave-Spot Slave-Spot Slave-Spot Slave-Spot Slave-Spot Slave-Spot Slave-Spot Slave-Spot 1. 可用最新的機器 2. 無限的資源 3. 降低成本 a. spot instance 4. 降低build time 28
29. 我們做了什麼 1. 讓團隊盡可能能夠 end to end 的去處理自己的事務 2. 調整 git flow 3. 擁抱雲端 solution 4. 站在巨人的肩膀上 29
30. 實際上我們真的做了什麼 1. 建立互相學習的環境 2. 將測試維運變成日常生活的一部分 3. 藉由 end to end 解決問題，消除浪費/等待 4. 藉由明確目標，看見全貌，保持彈性，避免一昧的制度 化 5. 讓團隊成員成為通才，進而達到賦能的效果 30
31. I am Ted • 一位大前端工程師 ◦ 主修 android ◦ 旁邊是我的技能樹 • 我們團隊能夠處理 ◦ app 開發 ◦ app 上架 ◦ app 製作後臺開發 ◦ 自動化工具開發 ◦ Backend For Frontend 開發 ◦ 交付流水線優化 ◦ 監控維運自己的服務 31