Mô hình Pull Request của GitHub có thể được sử dụng để triển khai phê duyệt bài không?

Câu trả lời được chấp nhận cho " Những triển khai có thể (hoặc ví dụ) của nguyên tắc bốn mắt là gì? " Cho thấy mô hình Yêu cầu Kéo của GitHub là một triển khai có thể.

Và câu trả lời của riêng tôi về " Làm thế nào để thực hiện nguyên tắc bốn mắt cho các sửa chữa khẩn cấp? " Giải thích khái niệm về phê duyệt sau .

Câu hỏi của tôi : Mô hình Yêu cầu Kéo của GitHub có thể được sử dụng để triển khai phê duyệt bài không? Nếu vậy: làm thế nào? Nếu không, có gì khác trong Git (GitHub?) Mà tôi có thể sử dụng cho nó không?

Vâng, tôi tin như vậy. Để giải thích rằng tôi cần đặt một số nền tảng về cách tôi đã thực hiện một cái gì đó tương tự, tôi đã đơn giản hóa mô hình trong một nỗ lực để làm cho nó rõ ràng nhất có thể.

Giả định

Tôi đang đưa ra giả định ở đây rằng Jenkins, TeamCity hoặc tương tự đang được sử dụng làm công cụ CI / CD được lựa chọn. Ngoài ra, GitHub đang được sử dụng và có cấu trúc phân nhánh được xác định rõ ràng và được kiểm soát phù hợp :

Cấu hình

Trong ví dụ này, GitHub được cấu hình như sau:

• Chi nhánh 'Master' Đen chỉ có thể được hợp nhất vào bằng cách sử dụng Yêu cầu kéo , các cam kết trực tiếp không được phép.
• Chi nhánh 'Phát triển' của Blue có thể chấp nhận các cam kết hoặc sáp nhập trực tiếp; trong thực tế, có thể có những hạn chế bổ sung đối với chi nhánh này.
• Chi nhánh 'Hotfix' màu đỏ có thể chấp nhận các cam kết và sáp nhập trực tiếp.
• Kiểm tra trạng thái bắt buộc được bật trong chế độ nghiêm ngặt để ngăn việc hợp nhất các yêu cầu kéo khi chi nhánh không xây dựng được.
• Nếu nhánh Hotfix đi trước Master thì kéo các yêu cầu vào Master sẽ bị chặn, với API trạng thái hoặc Móc nhận trước trên GitHub Enterprise .

Các công cụ CI / CD được cấu hình như sau:

• Các bản dựng từ nhánh Phát triển không thể được triển khai vào sản xuất.
• Bản dựng từ Master có thể được triển khai cho tất cả các môi trường.
• Bản dựng từ Hotfix có thể được triển khai cho tất cả các môi trường.
• Triển khai từ Hotfix sẽ thông báo cho một số chức năng không phát triển, ví dụ: nhóm Thay đổi / Phát hành và yêu cầu họ thực hiện phê duyệt sau .

Ghi chú

Master được bảo vệ vì nó đại diện cho tình trạng sản xuất hiện tại, để thực hiện điều này trên thực tế, bạn có thể có một nhánh "Phát hành" khác mà việc triển khai được thực hiện từ và chỉ khi hợp nhất thành công vào nhánh Master.

Những điểm chính

Chi nhánh phát triển màu xanh về cơ bản là miễn phí cho tất cả. Hotfix là một loại miễn phí nhưng mọi triển khai đều kích hoạt một loại Break Glass bằng cách thông báo cho một chức năng không phát triển, người sẽ thực hiện phê duyệt sau và trong quá trình sẽ hợp nhất thay đổi thành Master.

Đó là sự hợp nhất thiết yếu vào Master stop trong khi Hotfix đi trước Master để:

1. Ngăn chặn việc triển khai từ Master ghi đè Hotfix, điều này có thể dẫn đến hồi quy.
2. Ngăn chặn một Hotfix ngồi trong nhánh Hotfix mòn mỏi mà không được hợp nhất.

Trong một số tổ chức, điều này có thể giúp ngăn chặn tất cả các lần đẩy vào kho lưu trữ GitHub trung tâm trong khi Hotfix đang chờ phê duyệt sau.