Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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/

91APP Tech Network

June 04, 2020
Tweet

More Decks by 91APP Tech Network

Other Decks in Programming

Transcript

  1. I am Ted • 一位 App 工程師 ◦ 主修 Android

    • 負責 ◦ App 開發 ◦ App 上架 3
  2. • 時程不同 • 跨團隊協作困難 • app 的 Scope 越來越大 •

    部署時間過長 1000+ 客戶 • 測試團隊重複測試 優惠券列表 商品頁顯示優惠券 購物車使用優惠券 首頁 UI 優化 分類頁 UI 優化 商品頁 UI 優化 購物車新增付款方 式 購物車新增運送方 式 購物車新增折扣活 動 A B C 5
  3. 6

  4. 7

  5. 所以 DevOps = CI/CD? NO!! 我認為是藉由: 1) 建立文化 、2) 賦能給團隊

    、3) 讓團隊有能力改善現場的問題 進而能夠應付變化多端需求的一種方法 也就是賦予團隊彈性,讓團隊能夠適應改變 9
  6. 問題是什麼 1. 各個平台需要暸解對方的 domain know how 2. 各個平台因語言隔閡互相幫不上忙 3. 開發流水線需要多個團隊協作

    問題是 app 開發團隊沒辦法 end to end 解決他們想解決的問題 自動化工具 app 上架 app 製作 客戶 自動化工具 12
  7. real case 1. 盡可能小包的 Pull Request 2. 教育訓練 & 利用

    release manager 提醒,事件通知 3. 並不會將所有功能都加上 feature toggle 4. 還是會有 branch 會放比較久一點才 merge 原則: 1. 讓團隊成員了解做這件事情的目的 2. 公開透明,讓大家看見全貌,了解目前有哪些專案正在進行 3. 討論保持彈性避免無意義的制度化 18
  8. UT Lint 確保 develop branch 的健康 1. 如何確保 code 的品質

    a. 跟 testing 要測項,RD 自己測過 b. Unit test 2. 如果進版的 code 有問題,快速 revert rollback 20
  9. 好的架構 • 擴展性好,易於開發,職責明確 ◦ 高內聚,低耦合 ◦ 職責明確 ◦ 團隊成員協作順暢 •

    單體架構 ◦ 開發快速,什麼東西可能別人都已經幫忙寫好了 ◦ 很難暸解整體架構,架構複雜 ◦ 邊界不清楚 ◦ 改了一個核心東西之後要測試的範圍會相對大 • 微服務 ◦ 獨立性 ◦ 服務間溝通較複雜 23
  10. 康威定律 • 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
  11. App Api Base Login Member ShoppingCart Promotion Shopping 26 1.

    產生領域專家 2. 限縮修改範圍 3. 保持彈性 4. 降低code conflict
  12. 其他改善的項目 • 每次上架 1000+ 個 app 花的時間很多,又需要很多人力 ◦ 原本放在機房,只有 5-6

    台機器 ▪ 成本高 ▪ 機器隨時可能壞掉 ▪ 再好的機器放 3 年也是變普通的機器 27
  13. 其他改善的項目 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
  14. 實際上我們真的做了什麼 1. 建立互相學習的環境 2. 將測試維運變成日常生活的一部分 3. 藉由 end to end

    解決問題,消除浪費/等待 4. 藉由明確目標,看見全貌,保持彈性,避免一昧的制度 化 5. 讓團隊成員成為通才,進而達到賦能的效果 30
  15. I am Ted • 一位大前端工程師 ◦ 主修 android ◦ 旁邊是我的技能樹

    • 我們團隊能夠處理 ◦ app 開發 ◦ app 上架 ◦ app 製作後臺開發 ◦ 自動化工具開發 ◦ Backend For Frontend 開發 ◦ 交付流水線優化 ◦ 監控維運自己的服務 31