Chúng ta làm việc với git thông qua pull, push, commit, rebase, merge, pr, v.v.. để áp dụng git vào trong quy trình phát triển phần mềm cũng cần một số quy định để thống nhất quy trình làm việc cho cả team, dưới đây là một GitFlow mình đã áp dụng vào trong một sự án phát triển sản phẩm.

Quy trình này có thể sẽ không đúng cho cách xây dựng các sản phẩm khác, ở đây chỉ đưa ra một góc nhìn trong một sản phẩm cụ thể để mọi người cùng tham khảo.

Một số từ viết tắt

PR : Pull Request, cách gọi khác của Merge Request

CI/CD: Continuous Integration/Continuous Delivery

RC: Release Candidate

QA: Môi trường Quality Assurance

PROD: Môi trường Production

STG: Môi trường Staging

Các nhánh trong Git

dev: Nhánh chứa code code mới nhất được cập nhật chuẩn bị cho lần release tiếp theo

main:

• Nhánh chứa code đang được deploy trên môi trường production, sau khi code được triển khai từ nhánh release sẽ được merge ngược trở lại nhánh master.
• Dành cho việc phát triển các tính năng mới của hệ thống cho các đợt release tiếp theo.
• Nhánh này sẽ được merge vào develop hoặc hủy bỏ nếu các tính năng mới không đáp ứng.

feature/{ID}-{mo-ta-ngan}:

• Dành cho việc phát triển các tính năng mới của hệ thống cho các đợt release tiếp theo.
• Nhánh này sẽ được merge vào develop hoặc hủy bỏ nếu các tính năng mới không đáp ứng.

release/{major}.{minor}: Là nhánh được checkout từ nhánh develop khi đảm bảo các chức năng đảm bảo được cho việc release đã được merge vào nhánh develop.

bugfix/{ID}-{mo-ta-ngan}: Tương tự nhánh feature, nhưng tạo ra với mục đích fix các bug/issue trên nhánh develop hoặc release/*

hotfix/{ID}-{mo-ta-ngan}: Tương tự như nhánh feature, nhưng được tạo ra từ nhánh release mà code đang được triển khai trên môi trường PROD nhằm fix những lỗi critical.

Các môi trường phát triển sản phẩm

dev:

• Môi trường dành cho developer deploy, test các tính năng mới phát triển, test lại các bug fix.
• QA test các chức năng thuộc nhánh feature.
• QA test các bug/issue được phát hiện trên môi trường develop

qa:

• Developer test các bug/issue được phát hiện trên môi trường QA/STG.
• QA test các bug/issue được phát hiện trên môi trường QA để đóng bug.
• QA test các bug/issue được phát hiện trên môi trường STG để confirm đã TEST DONE trên môi trường QA.

stg:

• Môi trường dùng thử cho các khách hàng trong nhóm đăng ký tính mới.
• QA test để confirm lại các bug được phát hiện trên môi trường STG đã được fix và DONE.

prod:

• Môi trường sản phẩm. Khách hàng dùng và có thể report lỗi thông qua kênh feedback

Tùy thuộc vào từng loại sản phẩm, số lượng môi trường có thể tăng hoặc giảm, các môi trường khác như alpha, gold, v.v…

Nguyên tắc hoạt động Gitflow

• Việc phát triển sản phẩm được tiến hành ở nhánh develop
• Các thay đổi về code (commit) không được đẩy (push) trực tiếp nên các nhánh master, develop và release/* việc cập nhật các thay đổi về code thông qua merge (squash) từ các nhánh feature/bugfix/hotfix
• PR cho feature hoặc bugfix được merge thông qua square và rebase để gom lại các commit và lịch sử commit dễ đọc hơn
• Sau khi merge các các PR từ feature/bugfix/hotfix nên xóa nhánh trên repo
• Khi có một merge vào nhanh release, sẽ merge đến các nhánh release/* có version cao hơn và nhánh develop
• Khi nhánh release/* được tạo ra thì các thay đổi code phải thực hiện thông qua các PR từ nhánh bugfix/* hoặc hotfix/*. Tuyệt đối không thự hiện PR từ nhánh develop lên nhánh release

Nguyên tắc hoạt động CICD

• Code cho nhánh feature/* được và chỉ được checkout từ nhánh develop
• Code cho nhánh bugfix/* được checkout từ nhánh develop hoặc nhánh release
• Code cho nhánh hotfix/* được và chỉ được checkout từ nhánh release (cụ thể là Prod Release)
• Code được đẩy(push) lên từ nhánh feature/*, bugfix/*, hotfix/* sẽ thực hiện lệnh build, đảm bảo các thư viện, cú pháp chuẩn.
• PR chỉ được tạo ra từ
  • feature/* vào develop
  • bugfix/* vào develop
  • bugfix/* vào release
  • hotfix/* vào release
• Code được PR từ nhánh feature/*, bugfix/*, hotfix/* sẽ thực hiện CI, không thực hiện CD
• Code được merge từ feature/* vào develop sẽ được thực hiện CI và CD, khi thực hiện CD sẽ deploy lên môi trường DEV.
• Trong repo khi có 2 branch release trở lên, ta luôn xác định được 2 active release branch là 2 branch lớn nhất. Ví dụ hệ thống có release/1.0, release/1.1, release/1.2 thì 2 active branch là release/1.1 và release/1.2
  • Prod release (release/1.1): code trên branch này đang được triển khai lên môi trường prod
  • Pre release (release/1.2): code trên branch này chưa được đẩy lên prod, đang thực hiện test/fixbug.
• Khi repo chỉ có một branch, thì đó là Pre release.
• Khi thực hiện checkout một nhánh release từ nhánh develop, nhánh đó chính là pre release, nhánh thấp hơn nhánh release đó sẽ thành nhánh Prod release. Khi thực hiện lệnh checkout sẽ deploy nhánh mới lên môi trường QA.
• Khi tạo một tag (v1.0.0) trên nhánh Prod release sẽ thực hiện CI và CD, khi thực hiện CD sẽ deploy lên môi trường PROD
• Chỉ tạo hotfix/* từ Prod release branch (ràng buộc bởi quy định với dev nếu gitlab không hỗ trợ).
• Khi thực hiện PR từ hotfix/* vào Prod release sẽ thực hiện build đảm bảo thư viện và syntax.
• Khi PR hotfix/* vào Prod release được merge sẽ thực hiện merge code về nhánh pre release và nhánh develop. Khi merge, PIPE xác định nhánh đó có phải Prod Release hay không, nếu không phải sẽ không đồng bộ lại nhánh pre release và develop.
• Khi PR bugfix/* vào Prod release, PIPE xác định PR sai và báo lỗi.
• Khi tạo một tag (v1.1.0-rc.1) từ nhánh Pre release sẽ thực hiện CI và CD, khi thực hiện CD sẽ deploy lên môi trường STG
• Code được merge từ bugfix/* vào Pre release sẽ được thực hiện CI và CD, khi thực hiện CD sẽ deploy lên môi trường QA và thực hiện việc merge lại code vào nhánh develop.
• Tên của tag phải đảm bảo đúng mẫu quy định
  • Release ver: release/1.0
  • Prod release Tag:
    • v1.0.[buildNum]
    • v1.0.0
  • Pre release Tag

Quy trình phát triển phần mềm

Đầu mỗi Sprint hoặc có thể xa hơn sẽ tiến hành lên kế hoạch và định nghĩa các chức năng sẽ release hoặc các bug sẽ fix, gọi là release note, có thể định nghĩa nhiều release note tại một thời điểm. Dựa trên release note sẽ tạo thành các Epic/User Story/Task trên Jira của release note đó. Các đầu việc trên Jira liên quan đến Dev sẽ có quy tắc sau:

• Chức năng xây dựng mới thì cho kiểu issue là Task, thẻ môi trường cho Issue này là DEV.
• Các lỗi phát hiện trên môi trường DEV sẽ có kiểu là Bug, thẻ môi trường cho Issue này này DEV.
• Các lỗi phát hiện trên môi trương QA sẽ có kiểu là Bug, thẻ môi trường cho Issue này là QA.
• Các lỗi phát hiện trên môi trường STG sẽ có kiểu là Bug, thẻ môi trường cho Issue này là STG.
• Các lỗi được khách hàng phát hiện gửi lại qua kênh feedback, khi được team lead xác định là các lỗi nghiêm trọng cần fix, sẽ được tạo một Issue có kiểu là Bug, có thẻ môi trường là PROD.

Khi các đầu việc giao cho dev để xây dựng một chức năng nào, developer sẽ tạo một nhánh feature/* trên gitlab của repo tương ứng, có những đầu việc cần tạo trên nhiều repo khác nhau, nhưng luôn đảm bảo quy tắt đặt tên như đã nêu ở trên. feature/{ID}-{mo-ta-ngan}, ở đây ID mã của JIRA issue. Developer tiến hành phát triển/test các chức năng tại local sau đó tạo PR lên develop, khi code được merge sẽ được deploy lên DEV, tại đây developer test lại trước khi chuyển sang review. Team lead sẽ review và Done issue nếu feature có thể chuyển qua Phase test. Team lead tạo đầu việc test cho feature đó, gắn Jira link vào trong nội dung mô tả cần test.

Khi một issue có thẻ môi trường là DEV, developer sẽ tạo một nhánh bugfix/* từ nhánh develop để thực hiện fix lỗi, sau khi lỗi được fix ở local, sẽ tạo PR lên nhánh develop, developer tiến hành test lại và chuyển trạng thái. Team lead sẽ review và chuyển sang trạng thái test cho QA team, QA có quyền DONE bug. Khi một issue có thẻ môi trường là QA/STG, developer sẽ tạo một nhánh bugfix/* từ nhánh pre release (xác định pre/prod release tại mục 4.), developer fix và tạo PR lên nhánh pre release, developer tiến hành test lại và chuyển trạng thái. Team lead sẽ review và chuyển sang trạng thái test cho QA team. Khi một issue có thẻ môi trường là PROD, developer sẽ tạo một nhánh hotfix/* được checkout từ nhánh Prod release, lỗi này sẽ dược hotfix và không cần trải qua việc test, rất hạn chế những hotfix trừ trường hợp đặc biệt nghiêm trọng.

Tổng kết

• Có rất nhiều chiến lược khác nhau khi áp dụng GitFlow, TeachLead sẽ quyết định áp dụng mô hình nào để phù hợp với dự án của mình
• Bài viết chia sẻ về quy trình phát triển phần mềm dựa trên gitflow và áp dụng mô hình Scrum cho việc phát triển, chỉ là một góc nhìn tham khảo, có thể không phù hợp với tất cả các dự án.