Git flow ở công ty nghìn người sẽ như thế nào

Chuyện là hôm trước đang miệt mài support team trong quá trình test trên môi trường UAT để chuẩn bị golive, thì có thằng em team khác chạy sang vỗ vai hỏi sao anh lại deploy UAT từ branch riêng?

Mình kiểu Ủa Alo anh có làm thế bao giờ đâu?

Tức là câu chuyện nó như này:

Team mình với team ông em kia (gọi tạm ông em này là D) cùng code trên một con service, branch uat là branch chung chứa tất cả code của các team trước khi golive, còn branch release sẽ là branch riêng theo từng feature, mỗi team trước khi triển khai chức năng sẽ tạo branch release riêng cho chức năng của team mình.

Và buồn cười là nếu deploy từ branch release (branch riêng) mà không phải deploy từ branch uat (branch chung) thì sẽ xảy ra tình trạng mất code trên môi trường UAT.

Vì điều đó nên là mới có cái ảnh ở trên, một đồng nghiệp trong team của ông em D, mình gọi là ông anh H đi, ông anh H với thằng em D code hai chức năng khác nhau, một chức năng của D sau khi code xong đã được merge vào UAT để cho đội QC verify rồi, còn ông anh H sau khi đẩy code xong lên branch riêng thì deploy UAT thẳng từ branch riêng luôn, thành ra bị mất code của D.

Đôi khi đồng nghiệp cùng tên nó cũng không có nhiều cái lợi cho lắm, mình nhớ đâu đó cũng vài lần cá nhân mình cũng từng bị đồng nghiệp cho mất code kiểu này rồi, trên QC cũng như UAT.

Nhân tiện tình huống dở khóc dở cười này, mình xin chia sẻ một chút quy trình sử dụng git ở công ty mình cho các bạn:

Quy tắc chung

• master: branch master được quy định là branch stable, chỉ khi các chức năng đã được verify kĩ càng thì mới được merge vào master
• feature/test-qc: branch chung (đi theo service) trên môi trường QC, sau khi develop xong chức năng thì code sẽ được merge vào QC trước để kiểm thử
• feature/test-uat: branch chung (đi theo service) trên môi trường UAT, sau khi chức năng verify pass trên QC sẽ được merge vào UAT
• tên branch feature trong quá trình phát triển sẽ có format dạng : feature/jira_ticket (kiểu dạng như là feature/AT-10000-<tên mô tả ngắn gọn>)
• release: branch release sẽ là branch riêng, tuân theo quy tắc Semantic versioning (ví dụ đặt là: release/1.1.0, release/1.2.0,...) và đi theo từng ticket cụ thể, ví dụ ticket AT-101 đang được code ở branch release/1.1.0
• hotfix: sau khi golive, hệ thống vô tình gặp một rắc rối nào đó, thì cần hot fix để xử lý ngay, branch hotfix sẽ được tách từ master ra và xử lý, format sẽ có dạng: hotfix/jira_ticket_<mô tả hành động>

Triển khai thực tiễn

Team mình làm việc theo Scrum với mỗi sprint 2 tuần, trong mỗi sprint sẽ thực hiện công việc xử lý một vài ticket mà PO đã chuẩn bị trước, ví dụ:

• Các ticket AT-001, AT-002, AT-003,… tương ứng với các chức năng khác nhau (hoặc sẽ là phần riêng nhưng có liên quan đến nhau)
• Engineer trong quá trình triển khai code sẽ thực hiện tạo ra trước những branch release chung tương ứng với từng ticket trên
• Branch feature sẽ được tách từ branch release ra và implement code trên đó
• Sau khi implement code trên từng branch feature, thì sẽ merge code vào QC và UAT để kiểm thử
• Sau khi hoàn tất kiểm thử, code chạy ngon, đầy đủ test coverage thì sẽ merge code từ những branch feature vào branch release để chuẩn bị cho golive
• Code sẽ được merge từ nhiều branch release vào master để golive, tuy nhiên thường team mình sẽ tạo thêm một branch release chung nữa, để merge toàn bộ các branch release nhỏ vào một, sau đó nâng pom và golive trên branch release mới thôi.
• Sau khi golive nếu có biến, thì sẽ tạo branch hotfix để xử lý nhanh, sau đó merge lại vào những branch QC, UAT để tester verify tiếp.

Lý do chính để tuân theo git flow này

Thực ra ở những công ty nhỏ thì anh em developer đa số toàn tách từ master ra một branch chung sau đó code trên cùng branch đó thôi, hầu như cũng ít tuân theo những gitflow chuẩn, vậy nên rất hay có tình trạng anh em làm mất code của nhau, hoặc rất mất công trong những lần lấy lại code từ git, cherry-pick các kiểu tùm lum mới xong.

Các bạn có thể thấy, lợi ích của việc team mình tuân theo gitflow này chính là vì nó có thể đảm bảo được việc release cùng lúc nhiều phiên bản, hơn nữa việc tuân theo gitflow chuẩn như này khiến công việc trở nên rất dễ dàng, dễ xem lịch sử thay đổi, cũng như việc nhiều team cùng làm việc trên một dự án hoàn toàn đơn giản.

Xem thêm một số bài viết nổi bật:

• Viết code với những thói quen tốt này sẽ giúp bạn giỏi hơn
• Phỏng vấn dạo kĩ sư phần mềm 2023
• Kĩ năng quản lý căng thẳng cho Developer
• Câu chuyện phỏng vấn online mùa Covid
• Làm việc trong môi trường Agile là như thế nào
• Là kĩ sư phần mềm hãy cố gắng giữ gìn sức khỏe bản thân
• Bạn không giỏi lắng nghe như bạn nghĩ đâu
• How to build Rate Limit with Hazelcast and Spring Boot
• Hazelcast Distributed Cache with Spring Boot
• How to build Cron Job for multiple instances with ShedLock
• Distributed Lock with Hazelcast and Spring
• Ba luồng thực hiện tuần tự, có những cách triển khai nào?
• Biết sử dụng git cherry-pick để làm việc hiệu quả hơn
• Git stash giúp bạn trở nên chuyên nghiệp như thế nào?