Phụ lục D2 — Mẫu Delivery Plan đầy đủ (FoodNow)

Bản in từ templates/delivery-plan/. Đọc kèm Ch30–Ch33.

D2.1 Delivery Plan

📎 Nguồn: templates/delivery-plan/FoodNow-Delivery-Plan.md

Tên tài liệu: Delivery Plan tổng thể — FoodNow MVP → R1 Dự án: FoodNow Phiên bản / ngày: v1.0 — 30/01/2026 (tuần 4); cập nhật v1.1 ngày 02/11/2026 cho giai đoạn sau go-live Mục đích & khi nào dùng: Nối Roadmap → Release Plan → lịch build/deploy thực tế: nhịp phát hành, môi trường, chiến lược nhánh/tag, trách nhiệm; dùng từ Sprint 0 và cập nhật khi đổi chiến lược.

1. Delivery Plan khác gì Release Plan và Gantt

2. Chiến lược đã chọn (quyết định DL-005, 30/01/2026)

• Giai đoạn MVP (mô hình A): GitFlow-lite + release theo sprint + tag SemVer. Lý do: hợp đồng theo mốc, app mobile qua app store, cần UAT, đội có Backend mới chưa quen trunk-based.
• Sau go-live (mô hình B, từ tuần 44): backend/web chuyển trunk-based + daily deploy; mobile vẫn theo release train 2 tuần vì app store review 1–3 ngày.
• Chi tiết: branching-strategy.md, tagging-and-versioning-policy.md, release-strategy-migration-plan.md.

3. Cấp phát hành và nhịp

Release cadence MVP: mỗi 2 tuần lên staging; UAT đợt rc; production một lần lớn (go-live) rồi hotfix.

3b. Mapping Sprint → Release candidate → Tag → Môi trường

4. Freeze và cửa sổ deploy

• Scope Freeze: 13/07 · Feature complete: 17/07 · Code freeze (release branch): 24/07.
• Cấm deploy: Tết (16–20/02), 27/04, 30/04–01/05, 02/09; chiều thứ Sáu cho production (trừ cutover); từ 17/09 đến go-live chỉ theo runbook.
• Cửa sổ go-live: thứ Bảy 02:00–06:00 (lượng đơn thấp nhất).

5. Trách nhiệm (Release Manager)

Release Manager = Dũng (kỹ thuật) với Hà chịu trách nhiệm lịch và truyền thông.

6. Lưu ý mobile

App Store/Google Play có review 1–3 ngày → không "daily deploy" bản app; chỉ backend, web và feature flag/remote config. Backend hỗ trợ ≥ 2 phiên bản app.

7. Liên kết

release-calendar.csv · environment-matrix.md · delivery-strategy-decision-matrix.md · release-log.csv · Ch30–33.

Cách dùng cho dự án của bạn

1. Sao chép bảng cấp phát hành; điền môi trường và người duyệt của bạn.
2. Chọn chiến lược A hay B bằng ma trận quyết định; ghi quyết định vào Decision Log.
3. Dựng Release Calendar từ Gantt (freeze, lễ, cửa sổ deploy).
4. Gán Release Manager và RACI.
5. Xem lại khi bối cảnh đổi (sau go-live, đổi hợp đồng).

D2.2 Release Calendar

📎 Nguồn: templates/delivery-plan/release-calendar.csv (bảng dưới là bản đọc của tệp CSV; công thức Excel giữ nguyên trong tệp gốc).

D2.3 Environment Matrix

📎 Nguồn: templates/delivery-plan/environment-matrix.md

Tên tài liệu: Environment Matrix — FoodNow Dự án: FoodNow MVP Phiên bản / ngày: v1.0 — 30/01/2026 Mục đích & khi nào dùng: Mô tả từng môi trường: mục đích, ai deploy, dữ liệu, cổng vào; dùng để tránh nhầm lẫn "code đang chạy ở đâu".

Quy tắc

1. Staging giống production: cùng cấu hình, cùng cache, cùng phiên bản dịch vụ ngoài (sandbox tương ứng).
2. Không dữ liệu thật ngoài production.
3. Mọi bản lên UAT/production phải có tag.
4. Khác biệt cấu hình staging–production phải nằm trong danh sách khác biệt được biết (config diff) và được rà trước go-live.
5. Truy cập production: quyền tối thiểu, ghi log, có người duyệt.

Config diff staging ↔ production (cập nhật 20/09/2026)

Cách dùng cho dự án của bạn

1. Liệt kê môi trường thực có; đừng tạo nhiều hơn đội quản lý nổi.
2. Ghi rõ ai deploy, cổng vào và dữ liệu.
3. Giữ danh sách khác biệt cấu hình; rà trước mỗi mốc lớn.
4. Ràng buộc quy tắc dữ liệu thật/giả.
5. Xem lại khi thêm môi trường mới.

D2.4 Chính sách nhánh

📎 Nguồn: templates/delivery-plan/branching-strategy.md

Tên tài liệu: Chính sách nhánh (Branching Policy) — FoodNow Dự án: FoodNow MVP → R1 Phiên bản / ngày: v1.1 — 08/05/2026 (v1.0 ngày 30/01/2026; v1.1 thêm luật nhánh ≤ 5 ngày sau sự cố Sprint 6) Mục đích & khi nào dùng: Quy định các loại nhánh, cách đặt tên, merge, bảo vệ và ngoại lệ; dùng cho mọi repo của dự án.

1. Chiến lược theo repo

2. GitFlow-lite

Bỏ so với GitFlow đầy đủ: không dùng nhánh support/*; không tạo release/* cho từng sprint (chỉ cho rc); merge bằng squash để giữ lịch sử gọn.

3. Đặt tên nhánh

feature/FN-123-them-gio-hang · bugfix/FN-456-loi-tinh-gia · release/1.0.0 · hotfix/1.0.1 Quy tắc: bắt đầu bằng loại nhánh, có mã Jira, chữ thường không dấu, nối bằng gạch ngang.

4. Pull Request

• PR nhỏ (< 400 dòng thay đổi); review trong 24 giờ; ≥ 1 approver (thanh toán: 2).
• CI xanh (build, test, lint, quét bảo mật) mới được merge.
• Dùng pull-request-template.md; liên kết story Jira.
• Merge bằng squash vào develop; merge commit cho release/* và hotfix/* về main.

5. Nhánh sống lâu và luật 5 ngày (v1.1)

• Nhánh feature/* không được mở quá 5 ngày làm việc; ngày thứ 4 báo trong Daily; ngày thứ 5 phải tách nhỏ, rebase hoặc dùng feature flag.
• Cập nhật (rebase/merge từ develop) ít nhất mỗi ngày.
• Chia tính năng lớn thành PR nhỏ ẩn sau feature flag thay vì một nhánh dài.
• Bảng theo dõi nhánh cũ hằng tuần (tuổi nhánh).

6. Bảo vệ nhánh

Xem branch-protection-checklist.md: bắt buộc PR, ≥ 1 review, CI xanh, cấm force-push main/develop, cấm xoá.

7. Ngoại lệ

Hotfix khẩn cấp có thể có 1 approver (Tech Lead) sau khi Hà và Bảo duyệt; ghi vào release log.

Cách dùng cho dự án của bạn

1. Chọn chiến lược cho từng repo bằng ma trận (delivery-strategy-decision-matrix.md).
2. Định nghĩa bảng nhánh; thêm luật tuổi nhánh phù hợp đội bạn.
3. Bật branch protection theo checklist.
4. Đo tuổi nhánh hằng tuần; báo khi > 5 ngày.
5. Xem lại sau mỗi sự cố merge; ghi thay đổi vào lịch sử phiên bản.

D2.5 Chính sách tag và phiên bản

📎 Nguồn: templates/delivery-plan/tagging-and-versioning-policy.md

Tên tài liệu: Chính sách đánh số phiên bản và tag — FoodNow Dự án: FoodNow MVP Phiên bản / ngày: v1.0 — 30/01/2026 (chốt cùng Delivery Plan) Mục đích & khi nào dùng: Quy định cách đánh số, khi nào tag, ánh xạ tag ↔ Release Plan ↔ Jira Fix Version ↔ môi trường; dùng cho mọi repo.

1. Semantic Versioning (SemVer) MAJOR.MINOR.PATCH

Trước go-live dùng 0.x: v0.N.0 = bản cuối Sprint N (chưa phải sản phẩm hoàn chỉnh).

2. Tag là gì và quy tắc

• Tag đóng dấu một commit cụ thể, bất biến (không di chuyển/xoá).
• Mọi bản lên UAT hoặc production phải có tag. Bản staging cuối sprint cũng tag v0.N.0.
• Chỉ pipeline/Release Manager tạo tag v* (bảo vệ tag).
• Tag đặt trên main (bản production), release/* (rc), develop (sprint).

3. Quy ước tag theo Release Plan

4. Ánh xạ tag ↔ Release Plan ↔ Jira ↔ môi trường

Quy tắc: mọi story trong bản phát hành gắn Fix Version tương ứng; release notes sinh từ Fix Version.

5. Mobile

• versionName = SemVer (ví dụ 1.0.0); versionCode/build number tăng đơn điệu mỗi bản gửi store.
• Backend hỗ trợ ≥ 2 phiên bản app gần nhất; có cơ chế force update khi phiên bản quá cũ hoặc có lỗi bảo mật.

6. Rollback và truy vết

• Rollback = deploy lại tag cũ (ví dụ từ v1.0.1 về v1.0.0) theo runbook; không sửa tay trên server.
• Audit: ghi ai duyệt, khi nào, tag nào chạy ở đâu trong release-log.csv.
• Nhiều phiên bản hỗ trợ: dùng cherry-pick/backport từ main sang nhánh hỗ trợ (chỉ sửa lỗi nghiêm trọng).

Cách dùng cho dự án của bạn

1. Chọn SemVer + hậu tố; định nghĩa v0.N.0 nếu phát hành theo sprint.
2. Ghi bảng tag ↔ Release Plan ↔ Fix Version ↔ môi trường.
3. Bật bảo vệ tag; chỉ pipeline/Release Manager được tạo.
4. Quy định mobile (versionCode, force update, hỗ trợ ≥ 2 phiên bản).
5. Ghi mọi tag vào release log kèm người duyệt.

D2.6 Release Log (tag v0.1.0 → v1.0.1)

📎 Nguồn: templates/delivery-plan/release-log.csv (bảng dưới là bản đọc của tệp CSV; công thức Excel giữ nguyên trong tệp gốc).

D2.7 DORA metrics (12 tuần)

📎 Nguồn: templates/delivery-plan/dora-metrics.csv (bảng dưới là bản đọc của tệp CSV; công thức Excel giữ nguyên trong tệp gốc).