Aws summit 協助客戶邁向 DevOps 流程經驗分享
重點摘要
聽客戶痛點，找出原因，做最少改動達成想要的效果。不一定照圖施工，就會保證成功。
不一定要改上aws或改動現在正在使用或者導入中的工具
人工最常失誤的地方，例如部署，退版。
改善流程
訂定衡量標準，檢視導入 DevOps 改善多少程度
花最多時間是花在看 log ，其次是導入 CI/CD 方法
客戶案例與改善方法
| 客戶既存做法 | AWS SA 建議做法 | |
|---|---|---|
| Plan | CTO預期服務上 AWS 之後，開發團隊能夠更快交付新功能，但仍然緩慢 | 上 AWS 只是讓 infra 團隊更有效率做事，但對開發團隊幫助有限，需要從改善流程著手。 |
| Code | 每人固定維護自己的一條分支，不定期從上次release 版本 merge code ，或是從別人的分支某次穩定版 merge code，並基於 merge 後的程式碼，繼續往自己分到的票開發下去。很複雜的流程。 | 修改分支規則：a) 依照功能開分支，一功能一分支 b) 打 git tag 號 |
| Test | 跟Code一樣很複雜的流程，部署在測試環境上。 | 預計要測的程式碼一律合併要測試的其他功能分支在固定名稱的分支，有利於自動化打包和測試。若合併程式碼時遇到衝突時，在開發者本機解完衝突推上github後，再測試 |
| Build | 若測試過沒問題，每個測試版本各自打包成一個 AMI，所以會有很多個 AMI | 測試過沒問題，只做一個AMI，並配合制定 ec2 tag 和 S3 bucket 路徑 tag 的設定，對 AMI 打不同 tag，程式碼依據不同 tag 做不同事情。制定EC2 tag 和 S3 bucket 路徑配合命名規則如下：$部門/$案子/$環境，用帶入變數的方式，讓不同環境的部署，使用同一套流程 |
| Release | 選擇一個看著適合的 AMI，每月release 一次，一次八小時。每個Sprint時，每人輪流當release manager 並且負責解程式碼衝突 | 兩週release 一次, 一次40分鐘 |
| Package | (沒講) | (沒講) |
| Configuration | 每次連進機器，手動git pull 程式碼 | 用git hook 呼叫powershell 腳本 驅動 jenkins 去包裝一個可以release 的版本，然後自動部署。 |
| Deploy | (沒講) | 每天Deploy to dev 環境，全自動化部署在開發、測試、staging環境。因為客戶需求，在正視環境仍是手動按按鈕去觸發自動部署。部署到正式站之前，先備份環境和資料。 |
| Validation | 一個現在要上線的版本、一個要退版的版本 | (沒講) |
| Operation | (沒講) | (沒講) |
| Feedback | (沒講) | (沒講) |
AWS 上關於 DevOps 相關學習資源連結截圖：
