Release Flow at Microsoft Develop Team
(Bài viết tóm lược cách Microsoft sử dụng Release Flow để xây dựng one engineering system)
MS rất tích cực theo đuổi chiến lược sử dụng one engineering system cho toàn bộ công ty: một hệ thống hiện đại để build tất cả products đựa trên Git và Azure DevOps.
Bài viết này sẽ giải quyết câu hỏi làm sao sử dụng version control và branching dể deliver các thay đổi một cách an toàn tới production?
MS gọi nó là Release Flow, và nó bao gồm toàn bộ DevOps process: từ development đến release.
Quá trình Development
- Branch
Bước đầu tiên khi một developer muốn fix một bug hoặc implement một feature là tao một branch từ main integration branch (mainline), master branch. Đây là các short-lived topics branch. Developer được khuyến khích để commit sớm nhất có thể và tránh xa các long-running feature branch bằng cách sử dụng kỹ thuật feature-flag.
- Push
Khi developer đã sẵn sàng cho việc tích hợp các thay đổi của họ và ship các thay đổi này tới toàn bộ team, họ sẽ push local branch của họ tới một remote branch trên server, đồng thời tạo một pull-request.
- Pull Request
MS sử dụng Azure Devops Pull Request để quản lý cách các topic branch được merge vào master. Pull Request đảm bảo bảo các branch policy được thỏa mãn, đầu tiên là build các thay đổi và chạy các test nhanh.
MS run bộ test khoảng 60K tests level 0 và level-1 trong khoảng thời gian dưới 5 phút. Đó chưa phải là một matrix chất lượng hoàn chỉnh, tuy nhiên nó đủ để khẳng định nhanh sự tự tin về chất lượng của pull request.
Sau đó, MS yêu cầu các member khác của team review code và chấp thuận các thay đổi. Code review được được hiện sau khi các automated tests đã chạy thành công. Code review sẽ rất hợp để phát hiện các vấn đề về architect. Code review là một hoạt động thủ công để đảm bảo rằng nhiều engineer ở trong team quan sát được các thay đổi và chất lượng code ở mức cao.
- Merge
Một khi tất cả build policies được thỏa mãn, vòng đời của pull request kết thúc. Điều đó có nghĩa topic branch đã được merge vào main integration branch, master branch.
Sau khi merge, MS run các acceptance tests mà mất rất nhiều thời gian để chạy (post-checkin tests). Điều này cho MS sự cân bằng giữa các fast tests và complete test trong suốt quá trình pull request review. Đến cuối cùng thì vẫn có output là một complete test coverage before release.
Releases at Sprint Milestones
Vào cuối sprint, một deployment branch sẽ được tạo từ master branch: ví dụ, vào cuối sprint 129, MS sẽ tạo branch mới releases/M129. MS deploy branch này lên production.
Một khi deployment branch được tạo, master branch vẫn tiếp tục mở cho developer merge các thay đổi của họ. Các thay đổi này, tất nhiên, không được deploy lên production - chúng sẽ được deploy trong vào 3 tuần nữa, vào thời gian deploy của sprint tiếp theo.
Releasing Hotfixes
Chắc chắn rằng, một thay đổi thì cần deploy tới production càng nhanh càng tốt. Chúng ta thường không muốn thêm một feature cồng kềnh vào giữa sprint, nhưng thi thoảng thì chúng ta muốn mang một bug fix vào Azure DevOps thật nhanh để không làm block user. Đôi khi chúng ta phải fix các lỗi sai chính tả. Hoặc đôi khi chúng ta có một bug gây ra sự cố ở live site, MS gọi nó là "live site incident".
Khi nó xảy ra, MS bắt đầu mới workflow bình thường: tạo một branch từ master, review code, tạo pull request để merge nó. MS luôn bắt đầu bằng việc tạo ra các thay đổi từ master đầu tiên: điều này cho phép developer tạo các fix nhanh chóng, và kiểm tra nó ở local mà không cần switch tới 'release branch' ở local.
Một điều rất quan trọng nữa, bằng việc tuân theo process này, MS đang đảm bảo rằng các thay đổi đều diễn ra trên master. Điều này rất quan trọng: nếu fix một bug trên release branch, và sau đó quên mất việc mang các thay đổi này vào master, chúng ta sẽ tái hiện bug này vào lần deploy kế tiếp (một trải nghiệm khách hàng tệ đúng không?).
Chúng ta dễ quên làm điều này trong lúc bối rối, căng thẳng, hoặc có thể phát sinh khi mất điện. Vì vậy luôn luôn mang các thay đổi vào master đầu tiên, chúng ta biết rằng chúng ta sẽ luôn luôn có được các thay đổi ở cả master và ở cả các release branch.
(Sử dụng cherry-pick để sử dụng cho Workflow có vẻ là một best practice)
Moving On
Sau 3 tuần, chúng ta sẽ kết thúc việc thêm các feature vào sprint 130, chúng ta sẽ sẵn sàng để deploy các thay đổi này. Để deploy, chúng ta sẽ tạo ra một release branch releases/M130 từ master và deploy nó.
Vào thời điểm này, chúng ta có 2 branch ở production releases/M130 và releases/M129. Nếu releases/M130 phát sinh lỗi, chúng ta có thể roll back về releases/M129 rất nhanh chóng.
In Conclusion
Release Flow là trung tâm của phương pháp phát triển phần mềm ở Azure DevOps. Nó cho phép chúng tôi sử dụng một chiến lược branching đơn giản (trunk-based) cho các online services. Thay vì giữ các developer mắc kẹt ở deployment queue và chờ đợi các thay đổi được merge, các developer vẫn có thể tiếp tục làm việc, đẩy các commit lên master.
Release Flow cho phép chúng tôi triển khai các tính năng mới trên tất cả các trung tâm dữ liệu Azure theo nhịp đều đặn. Dù cho kích thước của codebase và số lượng developer làm việc trong đó thế nào, chúng tôi vẫn có thể đưa các hotfix vào production nhanh chóng, an toàn và hiệu quả.
Git at scale video chi tiết của MS