Xây dựng Gitflow

Phải nói thật một điều, không có gì là hoàn hảo không có gì là chén thánh cho mọi trường hợp. Và đối với Gitflow cũng vậy.

Mô hình JP giới thiệu bên dưới là dựa vào kinh nghiệm cá nhân, các dự án thực tế trong quá trình làm việc từ năm 2012 đến nay mà JP đúc kết qua được.

Dựa vào yêu cầu của mỗi dự án, skill của các members trong dự án mà mô hình này có thể được sửa lại cho phù hợp với từng dự án. Không có 1 mô hình tuyệt đối chính xác hay đúng đắn. Tất cả chỉ là tương đối.

Với các dự án quá cũ, có cách vận hành gitflow khác thì không cần phải chuyển qua mô hình này.

Dự án trong giai đoạn develop

Vai trò của các branch

master
Đây là nhánh chính của dự án, luôn luôn tồn tại (có thể đặt tên khác: main,…). Chúng ta sẽ thống nhất một số quy tắc BẮT BUỘC như sau:

• Luôn ở trạng thái có thể deploy.
• Không bị fail auto test (nếu dự án có yêu cầu dùng auto test)
• Nếu có vấn đề gì thì phải ưu tiên fix đầu tiên
• Không được commit/push trực tiếp vào branch này. Branch master phải được bảo vệ bằng chức năng protected branchs của GitHub (tất nhiên nếu công ty giàu :)) )

Branch này chỉ được update từ các merge request từ branch develop hoặc staging. Đôi khi các dự án nhỏ thì quá trình staging là không cần thiết

staging
Đây là nhánh dùng cho quá trình test tích hợp, cho các sếp review trước khi deploy lên production (do các công ty mình từng làm có quy trình này, có thể công ty các bạn không có)

Branch này cũng tương tự, không được push/commit trực tiếp vào branch này. Code mới chỉ được update từ merge request từ branch develop

develop
Đây là branch chính trong quá trình phát triển dự án, các tính năng mới sẽ được phát triển từ branch này

Nếu dự án mới khởi chạy hoặc các bạn chưa tạo thì branch develop được tách ra từ master.

Sau khi quá trình phát triển hoàn thành thì sẽ được tạo merge request vào nhánh staging hoặc master. Cần được review bởi các bạn có nhiều kinh nghiệm hoặc leader

Và vẫn là luật cũ, không được commit/push trực tiếp vào branch này. Tuy nhiên có một số ngoại lệ, nếu dự án quá nhỏ và chỉ có 1 người thực hiện thì bạn có thể push trực tiếp vào develop.

Vậy nếu không push trực tiếp thì chúng ta làm cách nào để phát triển tính năng cho dự án. Cùng JP tìm hiểu các branch chuyện dụng bên dưới

feature-XXX-[mô tả ngắn về chức năng]
Một số quy tắc

• Tách ra từ branch master
• XXX là id của backlog (hoặc open project, redmine, github issue,… tuỳ theo dự án)
• Dù chỉ có 1 commit cũng phải tạo pull request (PR). Các pull request khi tạo phải có tiền tố [WIP] ở trước. Sau khi được hoàn thiện và sẵn sàng review thì bỏ tiền tố này đi
• Sau khi hoàn thành phát triển thì submit review cho Project Leader, PM hoặc bạn tự review cũng cần submit

Các bạn cần luôn luôn tách branch feature vì một số lí do sau:

• Dự án có nhiều lập trình viên cùng phát triển nếu commit trực tiếp vào develop thì rất dễ xảy ra conflic (xung đột) code
• Để tách các chức năng độc lập giúp quá trình phát triển dễ quản lý hơn
• Các chức năng mới cần sự tham gia review chéo từ các thành viên team, review từ Project Leader, PM

Các PR luôn hướng về nhánh develop

feature-XXX-YYY

• Được tách ra từ branch feature-XXX
• YYY là tên người làm. Chỉ dùng trong trường hợp có nhiều hơn 1 người cùng dev 1 chức năng.

Các PR luôn hướng về nhánh feature-XXX

bug-fix-XXX-[mô tả ngắn lỗi]
Nhánh được tách ra từ develop để fix các bug trong quá trình phát triển chức năng
XXX là id của backlog (hoặc open project, redmine, github issue,… tuỳ theo dự án)

Sau khi hoàn thiện cần tạo PR và review vào develop

hotfix-XXX
Tách ra từ branch master
XXX là id của backlog (hoặc open project, redmine, github issue,… tuỳ theo dự án)
Sau khi làm xong thì gửi pull request vào master, merge và deploy lên.
Gửi pull request vào develop và merge.

Review

Khi tạo 1 branch mới và có commit mới thì bắt buộc phải tạo pull request và thêm prefix [WIP]. Tất cả các pull request phải được review.

Sau khi hoàn thiện xong chức năng và sẵn sàng review thì bỏ [WIP] đi và assign lại cho leader. Sử dụng các công cụ chatwork/slack để yêu cầu được review. Xem hướng dẫn tích hợp Slack notification

Sau khi review xong thì leader merge vào và xoá branch đó đi. Nếu có yêu cầu phải sửa thì comment vào và assign ngược lại cho member. Leader sau khi review xong cần phải comment lại để cho members được biết.

Deploy

Nếu có thay đổi trong develop, staging thì tự động deploy. Quản lý bằng Jenkins / CircleCI / Drone

Các bạn DevOps nên sử dụng các tools tự động để tiết kiệm thời gian, giảm rủi ro. Hẹn các bạn ở một bài viết khác chúng ta cùng bàn luận về vấn đề này

Deploy lên production

Sử dụng branch master chuyên để deploy lên production. Khi deploy lên production, tạo pull request từ branch staging vào branch master. Xác nhận sự thay đổi, nếu không có vấn đề gì thì merge vào master. Sau khi merge xong thì deploy lên server production. Khuyến khích dùng deploy tự động.

Fix lỗi khẩn cấp

Các lỗi khẩn cấp này không muốn gặp nhưng đôi lúc vẫn xuất hiện. Lý do vì môi trường production thường khác môi trường staging. Production thường có ELB, S3, biến môi trường khác biệt, …

Các lỗi này cần phải fix ngay lập tức, thường thì không có thời gian để trải qua đủ các quy trình deploy. Cần có người đủ kinh nghiệm phụ trách để tránh các lỗi phát sinh không mong muốn

Mô hình git cho phase 2nd

Nếu dự án đã release đến người dùng và cần phát triển phase tiếp theo. Lúc này có một số đều cần chú ý

1. Nếu dự án phát triển liên tục thì các bạn chỉ cần lặp lại quá trình dev như trên. Phát triển từ branch develop
2. Nếu dự án bị pending quá lâu, lúc này nhánh develop có thể có một số commit chưa được release, lúc này team cần ngồi lại xem xét có cần giữ lại các commit đó hay không, nếu không cần thì hãy bắt đầu phát triển tiếp bằng cách pull từ master

Bài viết hơi dài hy vọng các bạn đủ kiên nhẫn đọc đến đây. Cảm ơn các bạn đã đọc bài viết của JP. Các bạn hãy comment nếu cần thảo luận cùng JP.