7.Quy trình phối hợp & quản lý thay đổi các nhóm

7.1. Mục tiêu chương

Chương này quy định cách phối hợp giữa nhiều đơn vị phát triển nhằm:

• Tránh xung đột giữa FE, BE và Database
  
  

• Đảm bảo tích hợp ổn định
  
  

• Giữ tính tương thích giữa các module
  
  

• Kiểm soát các thay đổi ảnh hưởng hệ thống

7.2. Khái niệm / phạm vi áp dụng

Áp dụng khi:

• Có nhiều đơn vị cùng phát triển
  
  

• FE và BE tách source
  
  

• Nhiều FE dùng chung BE
  
  

• BE tách thành nhiều service
  
  

Mọi thay đổi liên quan:

• API contract
  
  

• Entity/Database
  
  

• Auth
  
  

• Domain/CORS
  
  

đều phải thông qua Core Team.

7.3. Quy định chính

Nguyên tắc chung

• Dùng contract-first (OpenAPI là nguồn chuẩn)
  
  

• Mọi thay đổi API hoặc DB phải được kiểm soát
  
  

• Mọi thay đổi breaking phải qua Core Team
  
  

Trường hợp FE và BE khác source, dùng chung DB

Rủi ro:

• Sai contract API
  
  

• Response làm FE vỡ
  
  

• Migration xung đột
  
  

Quy định:

• BE thay đổi API/DB phải update OpenAPI
  
  

• Mọi thay đổi DB phải có migration
  
  

• Staging dùng DB chung
  
  

Quy trình:

1. FE tạo ticket: API CONTRACT ISSUE
   
   

2. BE/Core xác nhận
   
   

3. Fix backward compatible hoặc tạo API v2
   
   

Trường hợp FE và BE dùng DB riêng khi dev

Quy định:

• Có DB baseline chung
  
  

• Staging dùng DB chung
  
  

Quy trình:

1. Nếu staging lỗi → so version migration
   
   

2. Không cho merge nếu thiếu migration
   
   

Trường hợp nhiều FE dùng chung một BE

Quy định:

• Dùng IdP chung (WSO2/Keycloak)
  
  

• Mỗi FE là một OAuth client riêng
  
  

• Gọi API bằng JWT
  
  

Quy trình:

1. FE đăng ký client_id
   
   

2. Core cấu hình redirectUri, scope
   
   

3. Core cấp quyền
   
   

Trường hợp FE chung source, BE nhiều service

Quy định:

• FE cấu hình baseURL theo service
  
  

• Auth dùng token chung
  
  

• CORS do Core Team quản lý
  
  

Quy trình:

1. Thêm service → tạo Integration Checklist
   
   

2. Core cấu hình CORS và token audience
   
   

Trường hợp thay đổi response làm FE vỡ

Quy định:

• Chỉ được thêm field (non-breaking)
  
  

• Không đổi kiểu dữ liệu
  
  

• Không rename field
  
  

• Breaking change phải tạo /api/v2
  
  

Quy trình:

1. Tạo BREAKING CHANGE REQUEST
   
   

2. Core duyệt
   
   

3. Thông báo FE
   
   

Trường hợp xung đột entity/model

Quy định:

• Entity dùng chung → coi là shared model
  
  

• Phải qua Data Model Change Request
  
  

Quy trình:

1. Partner đề xuất field + migration
   
   

2. Core review
   
   

3. Approve hoặc yêu cầu sửa
   
   

Trường hợp migration xung đột

Quy định:

• Không sửa migration đã merge
  
  

• Tạo migration mới để fix forward
  
  

Quy trình:

1. Rebase
   
   

2. Tạo migration mới
   
   

3. Test staging
   
   

Trường hợp seed/master data bị sửa

Quy định:

• Seed core do Core Team quản lý
  
  

• Partner chỉ được đề xuất
  
  

Quy trình:

1. Tạo MASTER DATA REQUEST
   
   

2. Core duyệt và triển khai

7.4. Quy trình triển khai tính năng nhiều tầng

1. Tạo ticket Feature
   
   

2. Chốt API contract (OpenAPI)
   
   

3. Chốt entity/migration
   
   

4. BE implement
   
   

5. FE integrate
   
   

6. Test staging
   
   

7. Release

7.5.Ví dụ minh họa

1. bảng mô tả các môi trường hệ thống: