GitLab
GitLab là nền tảng DevOps all-in-one. Cung cấp quản lý source code (Git), CI/CD, issue, security, deploy trên một hệ thống duy nhất, phù hợp team dev & DevOps.
Bắt đầu với Git
Tài liệu → Bắt đầu với Git- Các kiến thức Git cơ bản bạn sẽ dùng mỗi ngày trong GitLab.
- Làm local → push → merge request.
- Dùng branch cho mọi thay đổi.
- Ưu tiên hoàn tác an toàn (revert) sau khi đã push.
Mục đích / Kết quả
Workflow của GitLab được xây trên Git. Tab này giúp bạn quen với các kiến thức Git cơ bản dùng hằng ngày trong GitLab: clone, branch, commit, push và merge.
- Dùng Git ở local để tạo thay đổi an toàn (branches).
- Push thay đổi lên GitLab để người khác review.
- Nắm tối thiểu các lệnh bạn sẽ dùng mỗi ngày.
- Biết khi nào nên dùng merge vs rebase trong bối cảnh làm việc nhóm.
Dành cho ai + Khi nào dùng
Dùng phần này khi bạn mới học Git hoặc trước đây chỉ dùng Git qua GUI. Đây cũng là cách ôn nhanh nhất trước khi bạn bắt đầu làm việc với merge requests trong GitLab.
- Bạn viết code hoặc tài liệu và cần cộng tác.
- Bạn hay gặp conflicts và muốn hiểu vì sao.
- Bạn muốn các bước thao tác có thể lặp lại (CLI) cho các tác vụ phổ biến.
- Bạn dự định dùng CI/CD và cần lịch sử commit gọn gàng.
Vị trí trong điều hướng + Tab liên quan
Đây không phải là một trang GitLab đơn lẻ—nó là nền tảng dùng ở mọi nơi. Nên đi kèm với **Quản lý mã nguồn** (MRs) và **Projects** (cấu hình repo).
- Các khái niệm Git xuất hiện trong: Repositories, Merge requests, trigger CI pipelines.
- Bước tiếp theo: thiết lập SSH keys hoặc access tokens để xác thực.
- Liên kết chéo: Quản lý mã nguồn → Branches/MRs.
- Liên kết chéo: Projects → bảo vệ default branch mặc định.
Mô hình tư duy / Luồng
Hãy nghĩ Git như một dòng thời gian các ảnh chụp (commits). Branch là con trỏ trỏ tới commit, và remote branch nằm trên GitLab. Bạn làm việc ở local rồi đồng bộ lên GitLab.
- Sửa file → git status để xem thay đổi.
- git add để stage đúng phần thay đổi cần đưa vào.
- git commit tạo một snapshot kèm message.
- git push publish lên GitLab.
- Mở Merge Request để merge vào default branch.
Đối tượng & Thuật ngữ
Các thuật ngữ này sẽ xuất hiện liên tục trong UI và tài liệu GitLab. Nắm được chúng sẽ giúp xử lý sự cố nhanh hơn nhiều.
- Repository: lịch sử phiên bản của dự án.
- Commit: một snapshot kèm tác giả + message.
- Branch: một nhãn di động cho một nhánh công việc.
- Remote (origin): bản repo trên GitLab.
- Merge: gộp branches; Conflict: chồng chéo chỉnh sửa.
- Tag: một mốc được đặt tên trong lịch sử (thường dùng cho releases).
Máy trạng thái / Vòng đời
Một thay đổi đi theo vòng đời đơn giản: nháp → review → tích hợp. Git giúp bạn cô lập công việc đến khi sẵn sàng.
- Working tree: file đã đổi nhưng chưa stage.
- Staged: đã chọn các thay đổi sẵn sàng commit.
- Committed: đã lưu local trong lịch sử Git.
- Pushed: đã publish lên remote GitLab.
- Merged: đã tích hợp vào branch đích.
Các “việc cần làm” cốt lõi
Đây là các công việc Git phổ biến nhất khi bạn làm với GitLab.
- Tạo feature branch và push lên.
- Cập nhật branch của bạn với các thay đổi mới nhất từ default branch.
- Giải một merge conflict đơn giản.
- Revert một commit lỗi theo cách an toàn.
- Xem lịch sử để biết “đã đổi gì” và “vì sao”.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Pull (hoặc fetch) trước khi bắt đầu một thay đổi lớn.
- Commit theo các phần nhỏ, dễ đọc, với message rõ ràng.
- Dùng branch cho mọi thay đổi (kể cả thay đổi nhỏ).
Không nên
- Không commit secrets; dùng GitLab CI variables hoặc secret manager.
- Không force-push lên branch dùng chung trừ khi team có quy ước rõ.
- Không xử lý conflict bằng cách chọn bừa ‘theirs/ours’ mà không đọc nội dung.
Quyền hạn & Vai trò
Không áp dụng cho tool/tab này (Git là local; quyền GitLab áp dụng ở Projects/Groups).
Dữ liệu & Tích hợp
Tích hợp chính ở đây là các phương thức xác thực để Git giao tiếp an toàn với GitLab.
- Ưu tiên SSH keys cho máy dev bạn kiểm soát.
- Dùng Personal Access Tokens khi bắt buộc xác thực qua HTTPS.
- Rotate keys/tokens khi mất thiết bị.
- Lưu credential trong keychain của hệ điều hành, không lưu plaintext trong config.
Happy path workflow #1: Tạo feature branch và mở MR
- Clone repo từ GitLab (HTTPS hoặc SSH).
- Tạo branch: git checkout -b feature/<name>.
- Thực hiện thay đổi nhỏ; chạy test local nếu có thể.
- Stage và commit với message rõ ràng.
- Push branch lên GitLab: git push -u origin feature/<name>.
- Trong GitLab, tạo Merge Request từ branch mới.
- Nhờ reviewer và xử lý comment bằng các commit tiếp theo.
- Merge khi pipeline và review đều “xanh”.
Happy path workflow #2: Đồng bộ branch với default branch
- Fetch thay đổi mới nhất: git fetch origin.
- Chuyển sang branch của bạn.
- Cập nhật bằng merge: git merge origin/<default-branch>.
- Giải conflicts nếu có, rồi commit merge.
- Chạy test/build local (hoặc dựa vào CI).
- Push branch đã cập nhật lên GitLab.
- Xác nhận MR hiển thị “up to date” và pipeline chạy lại.
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Làm một mình vs làm với team | Làm một mình: rebase để lịch sử gọn (nếu team cho phép). | Làm team/branch dùng chung: dùng merge để tránh rewrite lịch sử. |
| Cần hoàn tác một commit | Đã push: dùng git revert (an toàn, tạo commit mới). | Chưa push: có thể reset/amend cẩn thận. |
| Xuất hiện conflict | Conflict nhỏ: xử lý local và commit. | Conflict lớn: pair với tác giả / tách thành các MR nhỏ hơn. |
| Phương thức xác thực | Laptop quản lý tốt: SSH keys thường dễ nhất. | Môi trường bị hạn chế: dùng HTTPS + PAT theo nguyên tắc tối thiểu quyền. |
Lỗi thường gặp (và cách tránh)
- Commit secrets — Thêm bước scan secrets và chuyển secrets sang CI variables.
- Một commit siêu lớn — Commit theo các bước logic nhỏ; reviewer dễ hiểu và revert an toàn.
- Quên push branch — Luôn push sau commit đầu tiên; mở MR dạng draft sớm.
- Làm trực tiếp trên default branch — Tạo branch trước; bật bảo vệ default branch trong GitLab settings.
- Commit message mơ hồ — Dùng message theo “ý định”: “Fix X bằng cách Y”, kèm ticket ID nếu có.
Thế nào là “tốt”
- Mọi thay đổi đều nằm trên branch và được review qua MR.
- Commit nhỏ và message giải thích ý định.
- Branch được cập nhật tương đối thường xuyên theo target branch.
- Không commit secrets; credential được xử lý bằng cách an toàn.
- Conflicts được giải với hiểu biết, không đoán mò.
Checklist
Pre-check
- Bạn có thể xác thực vào GitLab (SSH key hoặc token).
- Bạn biết tên default branch của repo.
- Bạn có thể chạy test hoặc lint cơ bản ở local.
- Bạn biết quy ước của team về rebase vs merge.
- Bạn có pattern đặt tên branch nhất quán.
Post-check
- Branch đã được push và MR đã được tạo.
- Pipeline “xanh” (hoặc lỗi đã được hiểu rõ).
- Feedback của reviewer đã được xử lý.
- Mô tả MR có link tới ticket/ngữ cảnh.
- Branch được xoá sau khi merge (nếu theo policy team).
Bài thực hành (5–15 phút): Tạo một thay đổi nhỏ an toàn
Mục tiêu: Tạo branch, sửa một dòng README, và publish để review.
Các bước
- Clone một repo nhỏ từ GitLab.
- Tạo branch feature/readme-update.
- Sửa README với một cải thiện rõ ràng.
- Commit với message “Docs: làm rõ bước setup”.
- Push và mở một MR dạng draft.
- Nhờ teammate (hoặc tự bạn) review và merge khi sẵn sàng.
Xác minh bạn làm đúng
- MR hiển thị đúng branch và diff.
- Commit message rõ ràng và đúng scope.
- Không có file không liên quan bị thay đổi.
- Pipeline được kích hoạt (nếu có cấu hình).
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu với Git
- Trang tài liệu → SSH keys
- Trang tài liệu → Personal access tokens
- Trang tài liệu → Các lệnh Git phổ biến
Bắt đầu tổ chức công việc bằng Projects
Tài liệu → Bắt đầu tổ chức công việc bằng Projects- Project là “đại bản doanh” cho repo + planning + CI.
- Bắt đầu với mặc định an toàn: private + bảo vệ default branch.
- Dùng group để chia sẻ quyền truy cập và tiêu chuẩn chung.
- Template + labels = bớt hỗn loạn.
Mục đích / Kết quả
Projects là nơi code, issues, CI/CD và settings nằm cùng nhau. Tab này hướng dẫn bạn cách tạo project, setup cho team, và giữ project dễ bảo trì lâu dài.
- Tạo hoặc import project và hiểu cấu trúc của nó.
- Thiết lập visibility, default branch và các cấu hình thiết yếu.
- Kết nối thành viên với mức quyền phù hợp.
- Thiết lập quy ước cơ bản: README, labels, templates.
Dành cho ai + Khi nào dùng
Dùng phần này khi bạn bắt đầu repo mới, onboarding vào project có sẵn, hoặc muốn chuẩn hoá cách tổ chức của bạn dùng GitLab.
- Repo mới cho team hoặc project hackathon.
- Migrate từ nền tảng Git hosting khác.
- Bạn cần issues/labels nhất quán giữa nhiều repo.
- Bạn muốn bảo vệ các branch và tags quan trọng.
Vị trí trong điều hướng + Tab liên quan
Trong UI GitLab, Projects là khái niệm top-level. Từ một project, bạn sẽ đi tới Code, Issues, CI/CD, Security, Deployments và Settings.
- Liên quan: Quản lý mã nguồn (MRs, branches).
- Liên quan: Lập kế hoạch công việc (issues, boards).
- Liên quan: CI/CD (pipelines, runners).
- Liên quan: Mở rộng GitLab (webhooks, API).
Mô hình tư duy / Luồng
Project là một “container”: repository + cộng tác + tự động hoá. Hầu hết cấu hình nằm trong project settings, và nhiều thiết lập có thể kế thừa từ chính sách ở cấp group.
- Group → Project: group có thể áp tiêu chuẩn và quyền truy cập.
- Nội dung repo quyết định luồng làm code (branches/MRs).
- Issues/Boards theo dõi công việc và liên kết với commits & MRs.
- CI/CD chạy dựa trên file trong repo và các settings.
Đối tượng & Thuật ngữ
Projects kết nối một vài đối tượng cốt lõi để bạn có thể trace công việc end-to-end.
- Project: workspace cấp cao nhất cho một sản phẩm/dịch vụ.
- Group: tập hợp nhiều project với thành viên/settings dùng chung.
- Visibility: phạm vi truy cập private/internal/public.
- Members & roles: Guest/Reporter/Developer/Maintainer/Owner (tuỳ ngữ cảnh).
- Project settings: repository, merge requests, CI/CD, integrations.
Máy trạng thái / Vòng đời
Project thường “trưởng thành” từ ‘chỉ là repo’ thành một đơn vị delivery có governance và automation.
- Mới: tạo/import repo, cấu hình tối thiểu.
- Cộng tác: thêm members, README, issues, quy ước.
- Có governance: protected branches, approvals, policies.
- Tự động hoá: pipelines, environments, security scans.
- Vận hành: monitoring, xử lý incident, audit.
Các “việc cần làm” cốt lõi
Đây là các tác vụ ở cấp project giúp workflow trơn tru.
- Tạo/import project và chọn visibility.
- Thiết lập default branch và luật bảo vệ branch.
- Mời thành viên và gán role theo nguyên tắc tối thiểu quyền.
- Định nghĩa quy ước đặt tên branches và tags.
- Thêm templates (issue/MR) để cộng tác nhất quán.
Quyền hạn & Vai trò
GitLab dùng role-based access ở cấp group và project. Bắt đầu từ quyền tối thiểu, chỉ nâng quyền khi thật sự cần.
- Guest: quyền hạn chế (thường là issues và comments).
- Reporter: quyền đọc, thấy nhiều nội dung dự án hơn.
- Developer: push lên branch không bị bảo vệ; tạo MRs.
- Maintainer: quản lý project settings và protected branches (thường gặp).
- Owner (group): quản lý billing/policies; không phải lúc nào cũng có ở cấp project.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Tạo README và ghi chú “cách chạy” ngay ngày đầu.
- Bảo vệ default branch và yêu cầu merge qua MR.
- Dùng group để chia sẻ quyền truy cập và tiêu chuẩn.
Không nên
- Không gán mọi người làm Maintainer mặc định.
- Không để default branch không được bảo vệ trong repo của team.
- Không dựa vào “truyền miệng”—hãy đóng gói vào templates.
Dữ liệu & Tích hợp
Projects tích hợp với các công cụ qua integrations có sẵn, webhooks và CI variables.
- Dùng webhooks cho chatops hoặc thông báo deploy.
- Dùng CI variables ở cấp project/group cho secrets và cấu hình môi trường.
- Kết nối container/package registries khi phù hợp.
- Nếu có thể, chuẩn hoá integrations ở cấp group.
Happy path workflow #1: Tạo project với mặc định an toàn
- Tạo project mới (blank, template hoặc import).
- Đặt visibility (thường là private cho đa số team).
- Chọn default branch (hay dùng main).
- Thêm README và cấu trúc thư mục cơ bản.
- Bật/xác nhận workflow Merge Request (yêu cầu MRs).
- Bảo vệ default branch (không push trực tiếp).
- Thêm issue template và MR template.
- Mời teammates với role phù hợp.
Happy path workflow #2: Chuẩn hoá một project có sẵn
- Rà soát settings và permissions hiện tại.
- Bật branch protection cho default branch.
- Thêm CODEOWNERS hoặc approval rules nếu tổ chức dùng.
- Tạo labels/milestones và một board cơ bản.
- Thêm CONTRIBUTING.md + CODE_OF_CONDUCT nếu phù hợp.
- Thêm khung CI (dù chỉ là job lint/test).
- Thiết lập required status checks (pipeline phải pass).
- Tài liệu hoá cách release/versioning (tags/releases).
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Project cá nhân vs project team | Cá nhân: governance nhẹ hơn; giữ đơn giản. | Team: bảo vệ branches, yêu cầu review, thêm templates. |
| Group vs project độc lập | Nếu nhiều repo: dùng group để chia sẻ members/settings. | Chỉ 1 repo: project độc lập vẫn ổn lúc đầu. |
| Chọn visibility | Mặc định private cho công việc nội bộ. | Public chỉ khi bạn sẵn sàng cộng tác mở. |
| Tên default branch | Dùng chuẩn tổ chức (main/master) nhất quán. | Nếu migrate, đổi tên cẩn thận và cập nhật CI/docs. |
Lỗi thường gặp (và cách tránh)
- Ai cũng là Maintainer — Dùng Developer cho đa số; giữ Maintainer cho admin repo.
- Không có templates — Thêm issue/MR templates để giảm hỏi-đáp qua lại.
- Default branch không được bảo vệ — Bảo vệ và yêu cầu MR với pipeline pass.
- Settings lệch chuẩn giữa các repo — Dùng mặc định cấp group và tài liệu hoá tiêu chuẩn.
- Secrets trong repo — Chuyển sang CI variables; rotate nếu đã lộ.
Thế nào là “tốt”
- Người mới có thể hiểu project từ README + templates.
- Default branch được bảo vệ; thay đổi merge qua MR.
- Roles theo nguyên tắc tối thiểu quyền và được rà soát định kỳ.
- Labels/milestones làm planning rõ ràng.
- CI cơ bản chạy trên mọi MR.
Checklist
Pre-check
- Visibility của project đúng mục tiêu (private/internal/public).
- Default branch đã chọn và được ghi rõ.
- Bạn biết ai nên là Maintainer vs Developer.
- Issue/MR templates đã phác thảo.
- Có quy ước đặt tên branch/tag release.
Post-check
- Mọi người có thể clone và đóng góp mà không phải đoán.
- MRs yêu cầu review (nếu muốn) và CI pass.
- Protected branches/tags đã cấu hình.
- Có bộ labels cốt lõi để triage.
- Docs mô tả cách run/test/release.
Bài thực hành (5–15 phút): Tạo ‘starter’ project trong 10 phút
Mục tiêu: Tạo một repo để teammate có thể dùng ngay.
Các bước
- Tạo một project trống.
- Thêm README + mục “Local setup”.
- Thêm ISSUE_TEMPLATE và MERGE_REQUEST_TEMPLATE.
- Bảo vệ default branch và yêu cầu MRs.
- Mời một teammate làm Developer.
Xác minh bạn làm đúng
- Không thể push trực tiếp lên default branch.
- Templates xuất hiện khi tạo issues/MRs.
- Teammate có thể tạo branch và mở MR.
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu tổ chức công việc bằng Projects
- User docs → Projects
- User docs → Thành viên & quyền trong Project
- User docs → Protected branches / tags (Repository settings)
Bắt đầu lập kế hoạch công việc
Tài liệu → Bắt đầu lập kế hoạch công việc- Issue là “nguồn sự thật” cho công việc.
- Board trực quan hoá trạng thái bằng labels.
- Milestones/iterations giúp đóng khung thời gian (timebox) cho việc giao hàng.
- Liên kết MR với issue để truy vết.
Mục đích / Kết quả
Lập kế hoạch trong GitLab xoay quanh Issues, Boards, Milestones, và Labels. Tab này giúp bạn theo dõi công việc từ ý tưởng → bàn giao mà không mất ngữ cảnh.
- Tạo issue với tiêu chí nghiệm thu (acceptance criteria) rõ ràng.
- Dùng labels và boards để trực quan hoá luồng.
- Nhóm công việc theo milestones/iterations.
- Liên kết thay đổi code ngược về các hạng mục kế hoạch.
Dành cho ai + Khi nào dùng
Dùng phần này khi bạn cần backlog gọn nhẹ, lập kế hoạch kiểu sprint, hoặc nhìn xuyên đội/nhóm mà không phải đổi công cụ.
- Team product/engineering quản lý backlog.
- Triage và ưu tiên hoá bug.
- Lập kế hoạch sprint bằng milestones/iterations.
- Theo dõi deliverables qua nhiều repo thông qua groups.
Vị trí trong điều hướng + Tab liên quan
Các tính năng planning nằm trong navigation của project/group (Issues, Boards, Milestones/Iterations, Epics nếu có). Hãy kết nối planning với MRs và kết quả CI.
- Liên quan: Quản lý mã nguồn (liên kết MR với issue).
- Liên quan: CI/CD (trạng thái pipeline trên MR).
- Liên quan: Projects (quy ước labels/templates).
- Liên quan: Monitoring (issues cho incident).
Mô hình tư duy / Luồng
Một luồng hữu ích: ghi nhận công việc thành issues → refine → kéo qua board → triển khai bằng MR → đóng issue kèm tham chiếu. Giữ issue là “nguồn sự thật” duy nhất.
- Issue là mỏ neo kế hoạch (vì sao/cái gì).
- Labels giúp ghi nhanh loại/độ ưu tiên/trạng thái.
- Boards trực quan hoá trạng thái theo label.
- Milestones/iterations nhóm issues theo timebox.
- Merge requests triển khai và đóng issues.
Đối tượng & Thuật ngữ
Chỉ cần các đối tượng này là đủ để có workflow planning mạnh.
- Issue: đơn vị công việc (tính năng, bug, task).
- Label: gắn thẻ linh hoạt cho trạng thái/loại/độ ưu tiên.
- Board: màn hình trực quan issue theo labels.
- Milestone/Iteration: nhóm theo khung thời gian.
- Epic (nếu bật): hạng mục cấp cao bao trùm nhiều issues.
- Assignee/Weight: người chịu trách nhiệm và tín hiệu effort.
Máy trạng thái / Vòng đời
Giữ trạng thái đơn giản và “ép” bằng labels/cột board. Đừng mô hình hoá quá phức tạp ngay từ đầu.
- Backlog → Ready → Doing → Review → Done (ví dụ).
- Chuyển trạng thái khi đạt tiêu chí (không phải theo thời gian).
- Dùng ‘Review’ khi code đã lên MR và đang chờ duyệt.
- Dùng ‘Done’ khi đã merge + xác minh.
Các “việc cần làm” cốt lõi
Đây là các động tác planning giúp team luôn thẳng hàng.
- Viết issue chất lượng: ngữ cảnh, bước thực hiện, acceptance criteria.
- Triage: gắn label và ưu tiên nhanh.
- Tổ chức một buổi refinement hàng tuần.
- Di chuyển issues qua board theo tiến độ thực tế.
- Tự động đóng issue từ MR bằng keyword (nếu hỗ trợ).
Quyền hạn & Vai trò
Hầu hết thao tác planning cần quyền truy cập cơ bản ở project. Nếu bạn không thể kéo issue hoặc sửa labels, hãy nhờ Maintainer chỉnh permissions.
- Tạo issues: thường cần Developer/Reporter tuỳ cấu hình.
- Sửa labels/boards: thường là Maintainer.
- Board cấp group: cần quyền ở group.
- Confidential issues: quyền xem phụ thuộc role.
- Ở dự án nhạy cảm, audit ai được đổi labels ưu tiên.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Giữ bộ status labels nhỏ, khớp với các cột trên board.
- Dùng templates cho bug/feature để chuẩn hoá thông tin.
- Liên kết issues với MRs sớm để truy vết.
Không nên
- Đừng tạo hàng chục label chồng chéo.
- Đừng kéo issue nếu chưa thống nhất “Done” nghĩa là gì.
- Đừng theo dõi việc quan trọng chỉ trong comments—hãy tóm tắt vào mô tả.
Dữ liệu & Tích hợp
Dữ liệu planning sẽ “đã” hơn khi được nối với code và incident.
- Dùng issue links/relationships để thể hiện phụ thuộc.
- Kết nối chat hoặc công cụ alerting để tạo incident issues.
- Nếu buộc phải đồng bộ trạng thái: dùng webhooks/API, nhưng ưu tiên native trước.
- Xuất/report từ milestones để cập nhật tiến độ.
Happy path workflow #1: Triage một bug report mới
- Tạo issue theo bug template (bước tái hiện, expected/actual).
- Gắn labels: type::bug, priority::?, status::backlog.
- Gán owner (hoặc đặt ‘needs-triage’).
- Thêm ghi chú severity/impact và ảnh/logs.
- Nếu tái hiện được, thêm task tạo minimal failing test.
- Chuyển sang Ready khi acceptance criteria đã rõ.
- Liên kết hoặc tạo MR khi bắt đầu triển khai.
- Đóng khi đã merge và xác minh trên môi trường mục tiêu.
Happy path workflow #2: Lập kế hoạch một sprint nhỏ với board
- Rà soát backlog và làm sạch tiêu đề/mô tả.
- Ước lượng/weight issues (nhẹ nhàng).
- Tạo milestone/iteration cho khoảng thời gian sprint.
- Chọn một tập issue thực tế đưa vào milestone.
- Dùng board có cột (Backlog/Ready/Doing/Review/Done).
- Chỉ chuyển issue sang Ready khi acceptance criteria hoàn chỉnh.
- Trong sprint, di chuyển issue khi trạng thái thay đổi.
- Cuối sprint, review Done vs chưa Done và rút kinh nghiệm.
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Cần luồng đơn giản vs quy trình phức tạp | Đơn giản: 4–5 cột và vài label. | Phức tạp: cân nhắc epics/roadmaps nếu có. |
| Cách biểu diễn trạng thái | Dùng labels/boards cho trạng thái (khuyến nghị). | Tránh nhét trạng thái vào title kiểu “[WIP] …”. |
| Mô hình ownership | Một assignee: rõ ràng cho team nhỏ. | Nhiều owner: dùng issue links/checklists để tách việc. |
| Thế nào là ‘Done’ | Merge + xác minh + cập nhật docs (nếu cần). | Chỉ merge: chỉ khi việc xác minh được xử lý ở nơi khác. |
Lỗi thường gặp (và cách tránh)
- Issue mơ hồ — Thêm acceptance criteria và các gạch đầu dòng “định nghĩa Done”.
- Bùng nổ labels — Giới hạn label; lưu trữ cái không dùng; áp quy ước đặt tên.
- Board không khớp thực tế — Sửa cột/labels để phản ánh cách team làm thật.
- Không có link giữa issue và MR — Tham chiếu issue trong mô tả MR; dùng closing keywords nếu hỗ trợ.
- Công việc bị “giấu” trong comments — Tóm tắt quyết định vào mô tả issue để người mới đọc được.
Thế nào là “tốt”
- Backlog dễ hiểu mà không cần họp.
- Board phản ánh thực tế trong vòng 24 giờ.
- Mọi issue đang làm đều link tới MR hoặc checklist rõ ràng.
- Scope milestone ổn định sau khi sprint bắt đầu (ít bất ngờ).
- Mục Done có bằng chứng xác minh (CI, ảnh chụp, ghi chú).
Checklist
Pre-check
- Bạn có issue templates cho bug/feature.
- Bạn có bộ status labels nhỏ và các mức ưu tiên.
- Cột board map 1:1 với status labels.
- Ngày milestone/iteration đã được định nghĩa.
- Team thống nhất tiêu chí ‘Ready’ và ‘Done’.
Post-check
- Có sprint summary (đã ship gì, chưa ship gì).
- Labels được cập nhật nhất quán.
- Các issue ‘needs-triage’ cũ đã được xử lý hoặc đóng.
- Insight được ghi lại cho sprint sau.
- Metrics (cycle time, throughput) được review nếu có.
Bài thực hành (5–15 phút): Dựng một planning board gọn nhẹ
Mục tiêu: Tạo board 5 cột và di chuyển 1 issue xuyên suốt.
Các bước
- Tạo labels: status::backlog, status::ready, status::doing, status::review, status::done.
- Tạo board dùng các labels này làm cột.
- Tạo một issue có acceptance criteria.
- Chuyển issue từ backlog → ready.
- Tạo draft MR và chuyển issue sang doing/review tương ứng.
Xác minh bạn làm đúng
- Cột board hiển thị đúng các labels.
- Issue có acceptance criteria rõ ràng.
- Issue có link tới MR (dù là draft).
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu lập kế hoạch công việc
- User docs → Issues
- User docs → Issue boards
- User docs → Milestones / Iterations (timebox planning)
Bắt đầu quản lý mã nguồn
Tài liệu → Bắt đầu quản lý mã nguồn- Merge Request (MR) là “mặt tiền” cộng tác quan trọng nhất.
- Giữ MR nhỏ, có ngữ cảnh + kế hoạch test.
- Dùng pipelines + approvals như các “cổng” chất lượng.
- Bảo vệ nhánh mặc định để áp chính sách.
Mục đích / Kết quả
Quản lý code trong GitLab xoay quanh branches, merge requests (MRs), review và approvals. Tab này cho bạn cách ship code an toàn với các kiểm tra chất lượng rõ ràng, dự đoán được.
- Tạo MR dễ review.
- Dùng diff, thảo luận (discussion) và approvals hiệu quả.
- Bảo vệ branches và áp “quality gates”.
- Truy vết thay đổi tới issues và releases.
Dành cho ai + Khi nào dùng
Dùng phần này nếu bạn sẽ cộng tác trên một repository: feature branches, code review, và merge sẵn sàng cho release.
- Dev tạo feature/bugfix branches.
- Reviewer duyệt thay đổi.
- Maintainer thiết lập chính sách merge.
- Team muốn chiến lược merge nhất quán.
Vị trí trong điều hướng + Tab liên quan
Trong một project, bạn sẽ dùng Repository (files/branches), Merge requests, và Settings để cấu hình chính sách merge. Luồng code gắn chặt với CI/CD và Planning.
- Liên quan: CI/CD (pipeline checks).
- Liên quan: Projects (protected branches/settings).
- Liên quan: Planning work (issues mà MR sẽ đóng).
- Liên quan: Secure (kết quả security trên MR nếu bật).
Mô hình tư duy / Luồng
Hãy coi mỗi MR như một “đề xuất” nhỏ: vì sao → đổi gì → kiểm chứng thế nào. GitLab sẽ chồng thêm kiểm tra tự động (CI) và kiểm tra con người (review/approval).
- Branch chứa thay đổi của bạn.
- MR mô tả mục tiêu và là nơi review.
- Pipeline xác thực build/test/security (tuỳ cấu hình).
- Approvals áp chính sách review.
- Merge strategy tích hợp thay đổi vào nhánh đích.
Đối tượng & Thuật ngữ
Đây là các “viên gạch” của cộng tác code trong GitLab.
- Merge Request (MR): đề xuất thay đổi từ nhánh nguồn → nhánh đích.
- Diff: màn hình xem thay đổi theo từng file.
- Review discussion: bình luận dạng luồng trên diff.
- Approval rules: quy định ai phải duyệt.
- Protected branches: giới hạn ai được push/merge.
- CODEOWNERS: quy định reviewer bắt buộc theo đường dẫn (nếu dùng).
Máy trạng thái / Vòng đời
Một MR thường đi theo: draft → ready → approved → merged. Dùng vòng đời này để giảm “churn” và tránh review khi còn dang dở.
- Draft: lấy feedback sớm; chưa sẵn sàng merge.
- Ready: scope ổn; yêu cầu review chính thức.
- Approved: đủ reviewer bắt buộc đã đồng ý.
- Merged: đã tích hợp vào nhánh đích.
- Closed: bỏ/được thay thế (có giải thích).
Các “việc cần làm” cốt lõi
Đây là các việc giúp code review vừa nhanh vừa an toàn.
- Tạo MR từ feature branch.
- Viết mô tả review được (ngữ cảnh + kế hoạch test).
- Phản hồi comment bằng các commit bổ sung.
- Xử lý merge conflicts.
- Chọn cách merge (merge commit/squash/rebase) theo policy của team.
Quyền hạn & Vai trò
Quyền hạn quan trọng nhất ở protected branches và chính sách merge.
- Developers: thường tạo branches + MRs.
- Maintainers: cấu hình MR settings, approvals, protected branches.
- Quyền merge có thể bị giới hạn theo policy.
- Nếu không push được branch: kiểm tra branch protection hoặc role.
- Nếu không approve được: kiểm tra bạn có nằm trong nhóm approver bắt buộc không.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Mở draft MR sớm để lấy hướng đi.
- Giữ MR nhỏ; nếu lớn thì tách thành các MR xếp tầng (stacked) nếu có thể.
- Thêm kế hoạch test và ảnh/logs khi phù hợp.
Không nên
- Đừng merge khi pipeline đỏ trừ khi bạn chấp nhận rủi ro một cách rõ ràng.
- Đừng bỏ qua review threads—hãy resolve công khai.
- Đừng né branch protection bằng cách push trực tiếp.
Dữ liệu & Tích hợp
MR sẽ “xịn” hơn khi đi kèm automation và khả năng truy vết.
- Yêu cầu pipeline pass trước khi merge (khuyến nghị).
- Kết nối issues: dùng references hoặc closing keywords.
- Dùng webhooks/chat integrations để thông báo sự kiện MR.
- Liên kết deployments/environments ở tab Deploy nếu bạn release từ GitLab.
Happy path workflow #1: Tạo một MR chất lượng cao
- Tạo feature branch và push lên GitLab.
- Mở MR và viết: ngữ cảnh, tóm tắt thay đổi, kế hoạch test.
- Thêm labels (type, priority) và link issue liên quan.
- Gán reviewers / CODEOWNERS nếu dùng.
- Chạy pipeline; sửa lỗi cho tới khi xanh.
- Xử lý comment bằng commit; giữ threads ở trạng thái resolved.
- Đảm bảo đủ approvals.
- Merge theo chiến lược của team và xoá branch.
Happy path workflow #2: Giải quyết conflict và giữ review “đúng nghĩa”
- Fetch thay đổi mới nhất từ nhánh đích.
- Merge hoặc rebase (theo policy) để cập nhật branch của bạn.
- Resolve conflicts ở local và chạy tests.
- Push branch đã cập nhật lên GitLab.
- Xác nhận MR hết conflict và pipeline xanh.
- Nếu review bị “lạc nhịp”, yêu cầu re-review các file thay đổi.
- Merge khi approvals vẫn hợp lệ (hoặc re-approve nếu yêu cầu).
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Kích thước MR | Nhỏ: review nhanh; merge thường xuyên. | Lớn: tách MR nhỏ để giảm rủi ro. |
| Cách merge | Squash: lịch sử gọn cho feature branches. | Merge commit: giữ bối cảnh branch; hợp cho thay đổi phức tạp. |
| Trạng thái pipeline | Xanh: tiếp tục review/merge. | Đỏ: sửa trước; chỉ override khi đã đồng thuận rõ ràng. |
| Chính sách review | Nhẹ: 1 reviewer cho thay đổi ít rủi ro. | Nghiêm: CODEOWNERS + nhiều approvals cho path quan trọng. |
Lỗi thường gặp (và cách tránh)
- Không có test plan trong MR — Thêm bước verify; kèm screenshots hoặc logs cho thay đổi UI/hành vi.
- Quá nhiều thay đổi không liên quan — Tách thành các MR khác nhau theo từng mục tiêu.
- Để threads chưa resolve — Resolve discussion hoặc tóm tắt lý do không đổi.
- Merge khi branch chưa cập nhật — Sync với nhánh đích để tránh conflict bất ngờ lúc merge.
- Bỏ qua approval rules — Dùng protected branches/approval settings để áp chính sách nhất quán.
Thế nào là “tốt”
- Mô tả MR trả lời được: vì sao, đổi gì, kiểm chứng thế nào.
- Diff đủ nhỏ để review trong một lần ngồi.
- Pipeline xanh và có các checks phù hợp.
- Approvals khớp với ownership và mức rủi ro.
- Branch được dọn dẹp sau khi merge.
Checklist
Pre-check
- Tên branch có ý nghĩa và đúng quy ước.
- MR link tới issue hoặc có ngữ cảnh đầy đủ.
- Test plan được viết rõ và khả thi.
- Pipeline đã được cấu hình cho project.
- Reviewer đã được chọn (hoặc CODEOWNERS tự kích hoạt).
Post-check
- Mọi discussion đã resolve hoặc được tóm tắt.
- Đủ approvals.
- Pipeline xanh trên commit mới nhất.
- Merge đúng phương thức.
- Branch được xoá (nếu policy).
Bài thực hành (5–15 phút): Mở một MR “chuẩn vàng”
Mục tiêu: Tạo MR để teammate review trong dưới 10 phút.
Các bước
- Làm một thay đổi nhỏ (một file hoặc một function).
- Mở MR và viết: Vấn đề → Giải pháp → Kế hoạch test.
- Thêm 1 label và link issue (hoặc tạo mới).
- Nhờ 1 người review và phản hồi feedback.
- Merge khi xanh.
Xác minh bạn làm đúng
- Mô tả MR đầy đủ (ngữ cảnh + test plan).
- Diff tập trung và nhỏ.
- Reviewer đọc hiểu mà không cần họp.
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu quản lý mã nguồn
- User docs → Merge requests
- User docs → Protected branches
- User docs → CODEOWNERS và approvals (nếu dùng)
Bắt đầu với GitLab CI/CD
Tài liệu → Bắt đầu với GitLab CI/CD- Pipelines được định nghĩa trong
.gitlab-ci.yml. - Jobs chạy trên runners; stages điều khiển thứ tự.
- Dùng variables cho cấu hình/bí mật.
- Chặn (gate) deploy jobs bằng rules + protections.
Mục đích / Kết quả
GitLab CI/CD tự động hoá việc build, test và deploy mã nguồn bằng pipelines được định nghĩa trong file .gitlab-ci.yml. Tab này hướng dẫn bạn tạo pipeline đầu tiên và giữ nó dễ bảo trì.
- Tạo pipeline chạy cho mọi push/MR.
- Hiểu jobs, stages và artifacts.
- Chọn và quản lý runners.
- Dùng variables an toàn cho cấu hình và secrets.
Dành cho ai + Khi nào dùng
Dùng phần này khi bạn muốn build/test lặp lại được, nhận feedback nhanh trong code review, hoặc tự động hoá phát hành.
- Developers thêm bước test/build.
- DevOps/SRE quản lý runners và deploy jobs.
- Teams muốn chất lượng được kiểm tra nhất quán.
- Projects muốn dùng templates/components để tái sử dụng.
Vị trí trong điều hướng + Tab liên quan
CI/CD nằm trong từng project (Pipelines, Jobs, Schedules, Settings > CI/CD). Nó gắn chặt với code review và các môi trường triển khai (environments).
- Liên quan: Managing code (yêu cầu pipeline pass để merge).
- Liên quan: Deploying & releasing (environments).
- Liên quan: Managing infrastructure (runners, Kubernetes).
- Liên quan: Extending GitLab (API, triggers, webhooks).
Mô hình tư duy / Luồng
Pipeline là một chuỗi stages, mỗi stage chứa các jobs. Jobs chạy trên runners. File YAML quyết định khi nào job chạy và chạy gì.
- Sự kiện kích hoạt pipeline (push, MR, schedule, manual).
- Pipeline chạy stages theo thứ tự (build → test → deploy).
- Jobs chạy trên runners (shared hoặc self-hosted).
- Artifacts/Reports được truyền giữa các stages.
- Trạng thái trả về MR như một “cổng” chất lượng.
Đối tượng & Thuật ngữ
Các thuật ngữ này xuất hiện liên tục khi setup và troubleshoot CI/CD.
.gitlab-ci.yml: file định nghĩa pipeline.- Pipeline: một lần chạy đầy đủ các jobs đã cấu hình.
- Job: một đơn vị công việc do runner thực thi.
- Stage: nhóm jobs có thứ tự.
- Runner: agent thực thi jobs.
- Artifacts: file được lưu từ jobs để dùng ở stage sau/tải về.
- Variables: cấu hình key-value (bao gồm secrets).
Máy trạng thái / Vòng đời
Pipelines và jobs đi qua các trạng thái quen thuộc trong UI.
- Created/queued: đang chờ runner.
- Running: đang chạy trên runner.
- Success: kết thúc với exit code 0.
- Failed: job hoặc script lỗi.
- Canceled/skipped: không chạy do rules hoặc bị dừng thủ công.
Các “việc cần làm” cốt lõi
Đây là các việc setup CI/CD cốt lõi cho hầu hết repo.
- Thêm pipeline tối thiểu với jobs lint + test.
- Chọn runner phù hợp (shared vs specific).
- Cache dependencies để build nhanh hơn.
- Lưu secrets trong CI/CD variables.
- Dùng rules để kiểm soát khi nào job chạy (MR vs main vs tags).
Quyền hạn & Vai trò
Cấu hình CI/CD thường do Maintainers kiểm soát, đặc biệt ở phần runner và variables.
- Sửa
.gitlab-ci.yml: ai có quyền push vào branch đó. - CI/CD settings (variables, protected variables): thường là Maintainer.
- Đăng ký runner: thường Maintainer/Admin tuỳ phạm vi.
- Protected branches + protected variables phối hợp để an toàn hơn.
- Nếu job không đọc được variable: kiểm tra phạm vi “protected”.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Bắt đầu với pipeline nhỏ rồi mở rộng dần.
- Dùng artifacts cho test reports và build outputs.
- Dùng protected variables cho credential production.
Không nên
- Đừng lưu secrets trong repo hoặc YAML.
- Đừng chạy job tốn kém ở mọi commit nếu không cần—hãy dùng rules/schedules.
- Đừng bỏ qua năng lực runner; pipeline bị xếp hàng là tín hiệu cần scale runners.
Dữ liệu & Tích hợp
CI/CD có thể tích hợp với container/package registry, environments và các đích deploy bên ngoài.
- Publish build artifacts lên Package/Container Registry (nếu dùng).
- Kích hoạt downstream pipelines hoặc tool deploy bên ngoài.
- Gửi thông báo job sang chat tools qua integrations/webhooks.
- Dùng API/trigger tokens để chạy pipeline bằng code (least privilege).
Happy path workflow #1: Thêm pipeline đầu tiên
- Tạo
.gitlab-ci.ymlở root của repo. - Định nghĩa stages: build và test (tối thiểu).
- Thêm một job đơn giản cho mỗi stage với lệnh script.
- Commit và push lên feature branch.
- Mở MR và kiểm tra pipeline tự chạy.
- Sửa lỗi; lặp tới khi xanh.
- Đặt pipeline là bắt buộc trước khi merge (nếu muốn).
- Merge và xác nhận pipeline cũng chạy trên nhánh mặc định.
Happy path workflow #2: Thêm deploy job một cách an toàn
- Định nghĩa environment (staging) và một deploy job trong stage deploy.
- Lưu credential triển khai dưới dạng CI/CD variables.
- Giới hạn deploy job bằng rules (chỉ default branch hoặc tags).
- Ban đầu để deploy là manual để giảm rủi ro.
- Chạy pipeline và trigger deploy thủ công.
- Xác minh app/service đã cập nhật ở staging.
- Thêm bước rollback hoặc job rollback riêng.
- Sau đó mới tự động hoá deploy rộng hơn nếu phù hợp.
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Chọn runner | Dùng shared runners để khởi đầu nhanh trên GitLab.com. | Dùng self-managed runners cho môi trường tuỳ chỉnh, tốc độ hoặc tuân thủ. |
| Tần suất chạy job | Chạy test nhanh ở mọi commit MR. | Lên lịch scan nặng/job nightly để giảm chi phí/thời gian. |
| Quản lý secrets | Dùng CI/CD variables (protected/masked) cho secrets. | Tránh secrets trong YAML hoặc file repo. |
| Chiến lược deploy | Manual deploy trước (staging) để kiểm chứng. | Auto deploy chỉ sau khi đủ tự tin và có guardrails. |
Lỗi thường gặp (và cách tránh)
- Pipeline chạy quá chậm — Thêm caching, giảm scope job, và chạy song song khi an toàn.
- Jobs bị kẹt queued — Scale runners hoặc chỉnh tags/runner selection.
- Lộ secrets trong logs — Mask variables và tránh in secrets; audit output job.
- Deploy chạy trên mọi branch — Dùng rules để giới hạn deploy ở protected branches/tags.
- Trùng lặp YAML — Dùng includes/templates/components để tái sử dụng logic pipeline.
Thế nào là “tốt”
- Pipelines tự chạy trên MRs và main.
- Các test quan trọng nhanh (<10 phút) và ổn định.
- Artifacts/reports hiển thị rõ khi fail.
- Secrets nằm trong protected variables, không nằm trong YAML.
- Deploy jobs được chặn và có thể audit.
Checklist
Pre-check
- Bạn đã commit một
.gitlab-ci.ymltối thiểu. - Runners sẵn sàng và phù hợp yêu cầu job.
- Scripts chạy được theo kiểu non-interactive.
- Các variables cần cho jobs đã được khai báo.
- Bạn biết sự kiện nào cần trigger pipelines.
Post-check
- Pipeline xanh trên các commit mới nhất.
- Fail cung cấp logs đủ hành động được.
- Deploy jobs được giới hạn đúng.
- Artifacts/reports được thu thập.
- CI settings khớp yêu cầu merge.
Bài thực hành (5–15 phút): Tạo pipeline 2 stage
Mục tiêu: Tạo pipeline nhỏ chạy lệnh lint và test.
Các bước
- Thêm stages: lint, test.
- Tạo lint job (formatter hoặc linter cơ bản).
- Tạo test job (unit tests).
- Push branch và mở MR để xem trạng thái pipeline.
- Cố tình làm hỏng một thứ để thấy fail, rồi sửa lại.
Xác minh bạn làm đúng
- MR hiển thị pipeline status.
- Job logs giải thích rõ cái gì fail.
- Sửa xong pipeline chuyển từ đỏ sang xanh.
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu với GitLab CI/CD
- CI/CD docs → Pipelines
- CI/CD docs → Runners
- Admin docs → CI/CD settings (instance/project)
Bắt đầu bảo mật ứng dụng của bạn
Tài liệu → Bắt đầu bảo mật ứng dụng của bạn- Bảo mật là một vòng lặp: scan → phân loại (triage) → sửa → xác minh.
- Bắt đầu với các scan “tín hiệu cao”, rồi mở rộng sau.
- Xem các phát hiện như các hạng mục công việc bình thường.
- Nếu lộ secrets, hãy xoay vòng (rotate) ngay lập tức.
Mục đích / Kết quả
GitLab có thể giúp bạn tìm và khắc phục lỗ hổng như một phần của quá trình phát triển. Tab này tập trung vào các thói quen bảo mật thân thiện cho người mới: chạy scan trong CI và xem kết quả cùng với thay đổi mã nguồn.
- Thêm các jobs scan bảo mật (khi có sẵn).
- Phân loại phát hiện và tập trung vào rủi ro thật.
- Sửa lỗ hổng có truy vết (issues/MRs).
- Kiểm soát secrets và dependencies.
Dành cho ai + Khi nào dùng
Dùng phần này khi bạn muốn nhận phản hồi bảo mật sớm hơn (trước khi phát hành) và có quy trình rõ ràng để xử lý phát hiện.
- Teams đưa bảo mật vào CI pipelines.
- Developers chịu trách nhiệm rủi ro từ dependency và code.
- Maintainers đặt chính sách “merge gate”.
- Bất kỳ ai phản hồi báo cáo lỗ hổng.
Vị trí trong điều hướng + Tab liên quan
Các tính năng Security thường xuất hiện trong điều hướng của project và trong widget của MR (tuỳ cấu hình và gói). Chúng dựa vào CI/CD để chạy scan.
- Liên quan: CI/CD (nơi scan được thực thi).
- Liên quan: Managing code (review kết quả security trong MRs).
- Liên quan: Planning (tạo issues cho findings).
- Liên quan: Deploying (chặn phát hành nếu có issue nghiêm trọng).
Mô hình tư duy / Luồng
Bảo mật là một vòng lặp: scan → review findings → sửa → xác minh → theo dõi. Hãy để scan gần với code và xem findings như hạng mục công việc bình thường.
- Chạy scan trên MRs và trên nhánh mặc định.
- Triage findings (mức độ nghiêm trọng, độ tin cậy, khả năng khai thác).
- Tạo issues cho phần việc cần làm; ghi nhận ngoại lệ.
- Sửa qua MR và chạy lại scan để xác minh.
- Theo dõi trạng thái theo thời gian (xu hướng, lỗi lặp lại).
Đối tượng & Thuật ngữ
Thuật ngữ bảo mật có thể khác nhau, nhưng các khái niệm sau lặp lại nhiều trong tài liệu Security của GitLab.
- Vulnerability (lỗ hổng): điểm yếu có thể gây tác động.
- Finding (phát hiện): kết quả scan có thể là lỗ hổng.
- Severity (mức độ): mức tác động (high/critical...).
- Dependency scanning: kiểm tra thư viện có CVE đã biết.
- SAST: kiểm tra pattern trong source code (khi hỗ trợ).
- Secret detection: phát hiện credential bị lộ (khi hỗ trợ).
Máy trạng thái / Vòng đời
Hãy coi security findings là công việc được theo dõi với trạng thái rõ ràng.
- Detected: scan báo ra một finding.
- Triaged: đã xác thực hoặc đánh dấu false positive.
- Planned: tạo issue với ưu tiên và người phụ trách.
- Fixed: code được merge và đã re-scan.
- Accepted: chấp nhận rủi ro kèm lý do và ngày review lại (nếu dùng).
Các “việc cần làm” cốt lõi
Bảo mật cho người mới trong GitLab chủ yếu là tạo vòng lặp phản hồi và hành động theo nó.
- Bật ít nhất một scan trong CI (dependency scanning thường là khởi đầu tốt).
- Review output scan trên MRs và ưu tiên các mục critical.
- Tạo issues cho việc sửa và liên kết với MRs.
- Ngăn lộ secrets bằng scan + thói quen credential tốt.
- Cập nhật dependencies và base images định kỳ.
Quyền hạn & Vai trò
Thiết lập và policy bảo mật thường bị giới hạn; hãy phối hợp với Maintainer hoặc người phụ trách security.
- Ai được đổi cấu hình CI sẽ ảnh hưởng phạm vi scan.
- Ai được dismiss/resolve findings tuỳ cấu hình/gói.
- Bảo vệ security variables (tokens/keys) như secrets production.
- Giữ audit trail cho các rủi ro đã chấp nhận/ngoại lệ.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Bắt đầu với ít scan “tín hiệu cao” rồi mở rộng dần.
- Ưu tiên critical/high trong các đường code có thể bị tác động.
- Ghi rõ vì sao cái nào là false positive hoặc rủi ro chấp nhận.
Không nên
- Đừng chặn mọi MR vì các finding “tín hiệu thấp” ngay từ đầu.
- Đừng bỏ qua cập nhật dependencies—đa số fix là nâng phiên bản.
- Đừng dán secrets vào issues/MRs hoặc job logs.
Dữ liệu & Tích hợp
Security có thể tích hợp với tool bên ngoài, nhưng lúc đầu nên giữ đơn giản.
- Đưa kết quả scan vào issues/boards để đi theo workflow.
- Thông báo kênh security khi có finding critical.
- Dùng package/container scanning nếu bạn publish artifacts.
- Nếu export sang SIEM/ticketing, hãy giữ một “nguồn sự thật” duy nhất.
Happy path workflow #1: Thêm dependency scanning vào CI (starter)
- Xác định package manager của project (npm, pip, ...).
- Thêm/bật job hoặc template dependency scanning (tuỳ GitLab bạn đang dùng có hỗ trợ).
- Chạy pipeline trên một branch và xác nhận kết quả xuất hiện trong job logs hoặc MR widgets.
- Triage 3 findings đầu: kiểm tra phiên bản và package bị ảnh hưởng.
- Tạo issues cho lỗ hổng thật với owner và due date.
- Sửa bằng cách nâng dependency hoặc áp dụng biện pháp giảm thiểu.
- Chạy lại pipeline để xác nhận findings giảm/biến mất.
- Ghi nhận rủi ro chấp nhận (accepted) với lý do và ngày review lại.
Happy path workflow #2: Ngăn chặn và xử lý khi lộ secrets
- Bật secret detection (nếu có) hoặc thêm job scan secrets cơ bản.
- Nếu phát hiện secret, hãy rotate ngay (coi như đã bị lộ).
- Xoá secret khỏi code và thay bằng CI variables hoặc tham chiếu vault.
- Bật masking/protection cho các variables liên quan.
- Cập nhật kiểm soát truy cập (least privilege).
- Tạo incident issue mô tả sự cố và các hành động đã làm.
- Thêm guardrails: pre-commit hooks hoặc CI checks.
- Nhắc team bằng checklist ngắn “không commit secrets”.
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Phạm vi scan | Bắt đầu với dependency scanning (giá trị cao với đa số ứng dụng). | Thêm SAST/container scans khi pipeline đã ổn định. |
| Xử lý findings | Lỗ hổng thật: tạo issue + sửa qua MR. | False positive: ghi rõ lý do và cách bạn kiểm chứng. |
| Chặn merge (gating) | Lúc đầu chỉ chặn critical/high. | Chặn thêm hạng mục khác khi team trưởng thành hơn. |
| Lộ secrets | Nếu lộ: rotate ngay, rồi cân nhắc dọn lịch sử nếu cần. | Nếu chưa chắc lộ: vẫn rotate và thêm kiểm tra phòng ngừa. |
Lỗi thường gặp (và cách tránh)
- Coi findings là “nhiễu” — Hãy triage; tập trung vào severity và khả năng khai thác; tinh chỉnh scan sau.
- Chặn dev quá sớm — Bắt đầu bằng việc hiển thị; tăng mức chặn dần dần.
- Không rotate secrets sau khi phát hiện — Luôn rotate—giả định đã bị lộ.
- Sửa mà không xác minh — Chạy lại scan và thêm kiểm tra hồi quy.
- Không có owner cho việc security — Chỉ định owner hoặc rotation; theo dõi trong milestones.
Thế nào là “tốt”
- Security scans chạy trên MRs và nhánh mặc định.
- Findings critical được triage trong SLA đã thống nhất.
- Fix được liên kết tới issues và xác minh bằng re-scan.
- Secrets không bao giờ nằm trong repo; variables được protected/masked.
- Rủi ro chấp nhận (accepted) được ghi lại và review định kỳ.
Checklist
Pre-check
- Ít nhất một scan job chạy trong CI.
- Có security owner/rotation.
- Team biết cách tạo/triage security issues.
- Cách quản lý secrets đã rõ (variables/vault).
- Có lịch cập nhật dependencies.
Post-check
- Findings critical đã giảm hoặc được track với due dates.
- Kết quả scan hiển thị trong MR review.
- Ngoại lệ được ghi rõ kèm lý do.
- Secrets đã rotate nếu có bất kỳ dấu hiệu lộ.
- Thay đổi security được đưa vào release notes khi cần.
Bài thực hành (5–15 phút): Triage một security finding từ đầu đến cuối
Mục tiêu: Chọn một finding thật và đi từ detection → fix → verify.
Các bước
- Chạy pipeline có kèm security scan.
- Chọn một finding mức độ cao (high severity).
- Xác minh phiên bản hiện tại có bị ảnh hưởng không (kiểm tra version package).
- Tạo issue với acceptance criteria (nâng cấp + tests pass).
- Sửa qua MR và chạy lại pipeline.
- Ghi kết quả vào issue và đóng issue.
Xác minh bạn làm đúng
- Issue có liên kết tới MR.
- Pipeline chứng minh bản sửa đã đúng.
- Finding đã được resolve hoặc giảm trong report về sau.
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu bảo mật ứng dụng của bạn
- User/CI docs → Security scanning (SAST/Dependency/Secret detection tuỳ áp dụng)
- User docs → Vulnerability management (nếu gói của bạn có)
- CI/CD docs → Variables (protect/mask)
Bắt đầu triển khai và phát hành ứng dụng của bạn
Tài liệu → Bắt đầu triển khai và phát hành ứng dụng của bạn- Phát hành an toàn: staging → xác minh → promote.
- Dùng rules + protected refs để kiểm soát deploy.
- Gắn version bằng tags/releases để dễ audit.
- Luôn có đường lui (rollback).
Mục đích / Kết quả
Triển khai và phát hành trong GitLab thường dùng CI/CD jobs, environments và gắn thẻ phát hành (release tagging). Tab này giúp bạn ship an toàn theo thói quen “staging trước”, kèm bước xác minh rõ ràng.
- Định nghĩa environments (staging/production) và deploy jobs.
- Chặn deploy bằng rules và approvals.
- Dùng tags/releases để versioning.
- Rollback khả thi và hiển thị rõ ràng.
Dành cho ai + Khi nào dùng
Dùng phần này khi bạn muốn GitLab “lái” quy trình release: build artifacts, deploy ra environments, và theo dõi “đang chạy gì ở đâu”.
- Teams làm continuous delivery.
- Dịch vụ cần staging và production tương đồng.
- Release managers điều phối cutover.
- Ứng dụng deploy lên Kubernetes/VMs/cloud.
Vị trí trong điều hướng + Tab liên quan
Tính năng deploy nằm quanh CI/CD, Environments và Releases (cấp project). Chúng phụ thuộc vào pipeline vững và quản lý secrets tốt.
- Liên quan: CI/CD (deploy jobs).
- Liên quan: Managing infrastructure (clusters, runners).
- Liên quan: Monitoring (xác minh sau deploy).
- Liên quan: Secure (đừng ship lỗ hổng critical).
Mô hình tư duy / Luồng
Một luồng release an toàn là: build → test → deploy lên staging → xác minh → promote lên production. GitLab theo dõi luồng này qua pipeline stages và lịch sử environment (nếu cấu hình).
- Build artifacts một lần; deploy đúng artifact đó cho mọi env.
- Dùng rules để kiểm soát ref nào được deploy (main/tags).
- Lúc đầu ưu tiên bước manual cho production.
- Ghi release notes và version tags.
- Xác minh hậu deploy bằng monitoring/health checks.
Đối tượng & Thuật ngữ
Các đối tượng sau giúp bạn quản lý release mà không phải “đoán mò”.
- Environment: đích deploy như staging/prod.
- Deployment: bản ghi một lần chạy deploy job.
- Release: gói thay đổi có version (thường gắn với tags).
- Tag: đặt tên cho một commit (v1.2.3).
- Rollback: quay về deployment/version trước đó.
- Feature flags: kiểm soát rollout dần (nếu dùng).
Máy trạng thái / Vòng đời
Deployments có các trạng thái đơn giản, dễ audit để bạn chuẩn hoá.
- Pending: pipeline đang chờ phê duyệt manual.
- Deployed (staging): đang chạy để xác minh.
- Promoted: đã deploy production.
- Rolled back: đã quay về phiên bản trước.
- Verified: monitoring xác nhận ổn định (theo định nghĩa của team).
Các “việc cần làm” cốt lõi
Các việc này bao phủ hầu hết setup release cho người mới.
- Thêm deploy jobs cho staging và production.
- Giới hạn deploy jobs bằng rules và protected refs.
- Lưu credentials môi trường dưới dạng protected variables.
- Tạo tags/releases cho các lần deploy có version.
- Thêm kế hoạch/job rollback (dù là manual).
Quyền hạn & Vai trò
Deploy là thao tác rủi ro cao. Hãy “gác cổng” bằng role và bằng bảo vệ branch/tag.
- Chỉ cho Maintainers (hoặc nhóm release) deploy production.
- Dùng protected environments/variables nếu hệ thống của bạn có.
- Khoá credentials production theo protected branches/tags.
- Ban đầu dùng job manual (nút play) cho production.
- Audit ai được tạo tags/releases nếu đó là thứ điều khiển deploy production.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Deploy cùng một artifact cho staging và production.
- Thêm bước xác minh rõ ràng (smoke tests/health checks).
- Giữ deploy production là manual cho tới khi bạn thật sự tin pipeline.
Không nên
- Đừng deploy từ các branch “ngẫu nhiên”.
- Đừng để credentials trong job scripts hoặc file trong repo.
- Đừng ship dịch vụ quan trọng khi chưa có đường rollback.
Dữ liệu & Tích hợp
Deploy thường tích hợp với cloud platforms và registries.
- Đẩy image lên container registry rồi deploy theo tag đó.
- Dùng Kubernetes contexts/secrets qua CI variables.
- Thông báo Slack/Teams khi có sự kiện deploy qua integrations/webhooks.
- Ghi metadata deploy để audit (commit SHA, tag, link pipeline).
Happy path workflow #1: Deploy theo hướng staging-first
- Đảm bảo stages build + test hoạt động ổn.
- Thêm job deploy:staging chạy trên nhánh mặc định (hoặc MR pipeline) bằng rules.
- Lưu staging credentials dưới dạng CI/CD variables.
- Deploy và chạy smoke tests tự động (job hoặc check bên ngoài).
- Nếu cần, kiểm tra thủ công URL/health của environment.
- Thêm deploy:production là job manual, giới hạn theo tags hoặc protected branch.
- Tạo release tag (vX.Y.Z) và chạy pipeline.
- Bấm deploy production và xác minh bằng monitoring.
Happy path workflow #2: Release bằng tags và release notes
- Áp dụng semantic versioning (hoặc chuẩn của tổ chức).
- Tạo tag cho commit phát hành.
- Tạo release notes (thủ công hoặc script) và publish một release entry.
- Để pipeline build và publish artifacts/images cho tag đó.
- Deploy artifact đã gắn tag lên production (manual gate).
- Ghi bằng chứng xác minh (link dashboard, tests).
- Nếu cần rollback: deploy lại tag trước đó.
- Khép vòng: cập nhật changelog và link issues/MRs đã gồm trong release.
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Trigger deploy | Push lên nhánh mặc định sẽ deploy staging. | Chỉ tags mới deploy production để kiểm soát chặt hơn. |
| Cách promote | Promote thủ công: an toàn ở giai đoạn đầu. | Promote tự động: chỉ sau khi đủ tự tin và có guardrails. |
| Chiến lược artifact | Build một lần, deploy cùng artifact cho mọi env. | Tránh rebuild theo env (giảm drift). |
| Rollback | Rollback nhanh: deploy lại tag/image trước đó. | Rollback phức tạp: cần lên kế hoạch migrations DB. |
Lỗi thường gặp (và cách tránh)
- Deploy từ feature branches — Giới hạn deploy jobs về main/tags bằng rules.
- Rebuild cho production — Promote đúng artifact đã build trong CI.
- Không có bước verify sau deploy — Thêm smoke checks và theo dõi metrics quan trọng.
- Credentials nằm trong scripts — Chuyển sang protected variables; mask output.
- Không có plan rollback — Ghi rõ bước rollback; luôn giữ bản cũ deploy lại được.
Thế nào là “tốt”
- Deploy staging diễn ra trước deploy production.
- Deploy production có “cổng” (manual + protected refs).
- Phiên bản release truy vết được về commits/MRs.
- Deployments được xác minh bằng tín hiệu quan sát được.
- Rollback được tài liệu hoá và thỉnh thoảng test lại.
Checklist
Pre-check
- Pipeline build artifacts/images ổn định.
- Môi trường staging tồn tại và truy cập được.
- Credentials lưu dưới dạng protected/masked variables.
- Rules giới hạn nơi deploy jobs được chạy.
- Quy trình versioning/release notes đã rõ.
Post-check
- Đã hoàn tất verify trên staging.
- Deploy production có ghi lại version + link pipeline.
- Monitoring xác nhận hệ thống ổn định.
- Đường rollback sẵn sàng (tag/artifact trước đó).
- Release notes đã publish và có liên kết.
Bài thực hành (5–15 phút): Thêm “cổng” manual cho deploy production
Mục tiêu: Tạo job deploy production chỉ chạy thủ công trên tags.
Các bước
- Thêm job deploy:production vào `.gitlab-ci.yml`.
- Đặt `rules` để job chỉ xuất hiện cho tags (hoặc protected branch).
- Lưu production credentials dưới dạng protected variables.
- Chạy pipeline theo tag và xác nhận job là ‘manual’ (có nút play).
- Bấm chạy và xác minh kết quả deploy.
Xác minh bạn làm đúng
- Job không xuất hiện cho các branch “ngẫu nhiên”.
- Credentials không bị in ra trong logs.
- Kết quả deploy xác minh được qua URL/health check.
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu triển khai và phát hành ứng dụng của bạn
- CI/CD docs → Environments và deployments
- User docs → Releases và tags
- CI/CD docs → Rules và variables
Bắt đầu quản lý hạ tầng của bạn
Tài liệu → Bắt đầu quản lý hạ tầng của bạn- Xem hạ tầng như code: MR + plan + review + apply.
- Giữ apply ở dạng manual và bị giới hạn quyền.
- Dùng runner tags để kiểm soát môi trường thực thi.
- Tách credentials theo từng môi trường.
Mục đích / Kết quả
Công việc hạ tầng trong GitLab thường là Infrastructure as Code (IaC), hạ tầng runners, và tích hợp cloud/Kubernetes. Tab này giúp bạn quản lý thay đổi hạ tầng với cùng kỷ luật MR + CI như khi làm code ứng dụng.
- Theo dõi thay đổi hạ tầng như code ứng dụng (MRs + review).
- Tự động hoá plan/apply an toàn trong CI.
- Quản lý năng lực runners và môi trường thực thi.
- Giữ credentials theo môi trường an toàn và có phạm vi rõ ràng.
Dành cho ai + Khi nào dùng
Dùng phần này nếu team của bạn quản lý Terraform/Ansible/Kubernetes manifests, hoặc bạn cần chạy CI jobs trong các môi trường cụ thể.
- Nhóm Platform/DevOps/SRE.
- Nhóm ứng dụng tự sở hữu Kubernetes manifests.
- Bất kỳ ai quản lý GitLab runners.
- Teams muốn chuẩn hoá provisioning môi trường.
Vị trí trong điều hướng + Tab liên quan
Các chủ đề về hạ tầng kết nối xuyên suốt CI/CD (runners, jobs), Deployments (environments), và Integrations (clusters/cloud).
- Liên quan: CI/CD (runners, pipeline jobs).
- Liên quan: Deploying (environments, Kubernetes).
- Liên quan: Secure (secrets và tuân thủ).
- Liên quan: Monitoring (sức khoẻ hạ tầng sau thay đổi).
Mô hình tư duy / Luồng
Hãy coi thay đổi hạ tầng là “high-risk”: đề xuất trong MR → chạy ‘plan’ → review → apply kèm approvals. Tách các kiểm tra chỉ-đọc khỏi thao tác ghi thay đổi.
- MR kích hoạt các job ‘plan’ (chỉ-đọc).
- Review output (diffs, plans) ngay trong MR.
- Apply jobs là manual và bị giới hạn vào protected refs.
- Dùng variables theo môi trường và scope rõ ràng.
- Audit thay đổi qua lịch sử pipeline/job.
Đối tượng & Thuật ngữ
Công việc hạ tầng thường dùng các khái niệm sau trong GitLab.
- Runner tags: định tuyến jobs đến đúng executor.
- Protected variables: giới hạn secrets cho protected refs.
- Environments: ánh xạ deploy/apply jobs đến mục tiêu.
- IaC ‘plan’ vs ‘apply’: xem trước vs áp dụng thay đổi.
- Kubernetes contexts/namespaces: cô lập mục tiêu.
Máy trạng thái / Vòng đời
Một vòng đời hạ tầng ổn định sẽ giảm nguy cơ outage.
- Đề xuất thay đổi: tạo MR kèm output plan.
- Đã duyệt: platform owners ký duyệt.
- Đã áp dụng: chạy apply manual từ pipeline được bảo vệ.
- Đã xác minh: health checks/monitoring xác nhận ổn định.
- Hậu kiểm: nếu có sự cố, tạo issue và ghi lại hành động.
Các “việc cần làm” cốt lõi
Đây là các việc tối thiểu để tự động hoá hạ tầng một cách an toàn.
- Tạo stage pipeline cho lint/validate IaC.
- Thêm job ‘plan’ chạy trên MRs.
- Thêm job ‘apply’ ở dạng manual và được bảo vệ.
- Đặt runner tags cho các môi trường đặc thù (Docker-in-Docker, privileged, v.v.).
- Tài liệu hoá quy trình escalation/rollback.
Quyền hạn & Vai trò
Vận hành hạ tầng nên bị giới hạn. Dùng protected branches/tags, protected variables, và quyền deploy hạn chế (nếu hệ thống hỗ trợ).
- Giữ apply jobs là manual và chỉ cho Maintainers/nhóm platform.
- Dùng credentials tách riêng theo môi trường (staging vs prod).
- Giới hạn credentials production chỉ cho protected refs.
- Dùng runners riêng cho các job cần quyền cao (privileged).
- Rà soát quyền đăng ký runner và cấu hình admin định kỳ.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Chạy validate và kiểm tra format trên mọi MR.
- Hiển thị plan output trong MR để review.
- Tách credentials và runners giữa staging và production.
Không nên
- Đừng cho phép ‘apply’ trên các branch chưa review.
- Đừng dùng chung một cloud credential cho tất cả mọi thứ.
- Đừng trộn thay đổi hạ tầng và ứng dụng trong một MR trừ khi bắt buộc.
Dữ liệu & Tích hợp
Hạ tầng thường tích hợp với cloud providers và Kubernetes. Hãy giữ kết nối an toàn và audit được.
- Lưu kubeconfig/cloud credentials dưới dạng protected variables.
- Dùng credentials ngắn hạn khi có thể.
- Gắn tag runners để chỉ một số job nhất định chạm được vào network prod.
- Gửi thông báo thay đổi đến kênh ops qua webhooks/integrations.
Happy path workflow #1: IaC plan/apply qua MR
- Tạo branch cho một thay đổi hạ tầng (ví dụ: Terraform).
- MR kích hoạt validate + plan jobs (chỉ-đọc).
- Review plan output cùng platform owner.
- Điều chỉnh nếu plan rủi ro/khác kỳ vọng.
- Lấy approvals theo yêu cầu.
- Merge vào nhánh mặc định.
- Chạy pipeline được bảo vệ và kích hoạt apply job manual.
- Xác minh sức khoẻ hệ thống qua dashboard monitoring.
Happy path workflow #2: Thiết lập runner tags cho infra jobs
- Xác định job cần môi trường đặc biệt (privileged, Docker, network).
- Cấp phát runner riêng cho môi trường đó.
- Gán runner tags (ví dụ: `infra`, `k8s`, `privileged`).
- Trong `.gitlab-ci.yml`, đặt `tags:` cho các job tương ứng.
- Test bằng một job dry-run an toàn.
- Khoá quyền sửa pipeline config trên protected branches.
- Theo dõi thời gian chờ (queue time) của runner và scale khi cần.
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Tách plan/apply | Luôn tách plan (MR) khỏi apply (protected). | Chỉ gộp cho dự án nhỏ hoặc môi trường rủi ro thấp. |
| Vị trí runner | Dùng shared runners cho lint/validation cơ bản. | Dùng runner riêng cho apply jobs cần quyền cao hoặc truy cập mạng. |
| Chiến lược credentials | Credentials theo môi trường + least privilege. | Tránh một key/token “toàn quyền”. |
| Xác minh thay đổi | Tự động hoá health checks sau apply. | Nếu thủ công, yêu cầu bằng chứng trong issue/release notes. |
Lỗi thường gặp (và cách tránh)
- Apply job chạy ở mọi push — Đặt apply là manual + giới hạn bằng rules/protected refs.
- Plan output không được review — Đính kèm artifacts plan và yêu cầu approval trước apply.
- Dùng chung credentials prod — Tách credentials; giới hạn scope; xoay vòng định kỳ.
- Privileged runner dùng cho mọi thứ — Tag và chỉ route job cần quyền cao; các job khác dùng runner an toàn hơn.
- Không có rollback — Định nghĩa bước rollback; giữ cấu hình cũ deploy lại được.
Thế nào là “tốt”
- Thay đổi hạ tầng được code-review kèm plan outputs rõ ràng.
- Apply là manual và chỉ chạy trên protected refs.
- Credentials được scope theo môi trường và được bảo vệ.
- Định tuyến runner giúp tránh truy cập prod vô tình.
- Mỗi thay đổi đều có bước xác minh rõ ràng.
Checklist
Pre-check
- Repo IaC có bước format/validate.
- Job plan chạy trên MRs và tạo artifacts.
- Job apply là manual và được giới hạn.
- Runner tags được định nghĩa và có tài liệu.
- Có plan rollback cho hệ thống quan trọng.
Post-check
- Apply chỉ chạy từ protected pipeline.
- Thay đổi được ghi nhận (commit/tag/pipeline).
- Monitoring xác nhận ổn định.
- Credentials không bị lộ trong logs.
- Ghi chú sau thay đổi được lưu trong issue/MR.
Bài thực hành (5–15 phút): Tạo pipeline ‘chỉ plan’ an toàn
Mục tiêu: Thêm validate + plan jobs chỉ chạy trên merge requests.
Các bước
- Thêm job `validate` (format/lint).
- Thêm job `plan` chỉ chạy cho MRs (rules).
- Lưu credentials chỉ-đọc cần thiết dưới dạng protected variables (hoặc mock cho lab).
- Mở MR và xác nhận plan output được đính kèm như artifact.
- Review và merge.
Xác minh bạn làm đúng
- Job plan không sửa đổi hạ tầng.
- Artifacts truy cập được từ MR.
- Không có giá trị nhạy cảm xuất hiện trong logs.
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu quản lý hạ tầng của bạn
- CI/CD docs → Runners
- CI/CD docs → Variables và protected variables
- CI/CD docs → Environments (khi thay đổi hạ tầng ánh xạ tới mục tiêu)
Bắt đầu giám sát ứng dụng của bạn trong GitLab
Tài liệu → Bắt đầu giám sát ứng dụng của bạn trong GitLab- Vận hành theo vòng lặp: phát hiện → giảm thiểu → sửa → rút kinh nghiệm.
- Dùng incident issues làm “nguồn sự thật” (record of truth).
- Thêm smoke checks để xác minh sau deploy.
- Luôn track các việc follow-up bằng issues.
Mục đích / Kết quả
Giám sát giúp “khép vòng” sau khi bạn deploy: bạn cần tín hiệu để xác nhận thay đổi đang hoạt động tốt. Tab này giúp bạn thiết lập workflow monitoring cơ bản, gắn kết incidents với issues và các bản sửa.
- Định nghĩa thế nào là ‘khỏe’ (SLO-lite).
- Tạo workflow incident bằng issues.
- Thu thập bằng chứng và các hành động follow-up.
- Xác minh bản sửa sau các lần triển khai.
Dành cho ai + Khi nào dùng
Dùng phần này khi team của bạn vận hành dịch vụ và cần cách làm lặp lại được để phát hiện, phản hồi, và học từ sự cố.
- Dev on-call và SREs.
- Teams ship thường xuyên và cần tín hiệu rollback nhanh.
- Bất kỳ ai làm incident reviews/postmortems.
- Dự án có môi trường staging/production.
Vị trí trong điều hướng + Tab liên quan
Monitoring và xử lý incident kết nối với Issues (ghi nhận incidents), CI/CD (xác minh deploy), và Projects (templates và phân quyền).
- Liên quan: Deploying (xác minh sau deploy).
- Liên quan: Planning (incident issues và follow-ups).
- Liên quan: CI/CD (smoke checks tự động).
- Liên quan: Extending (tích hợp công cụ alert qua webhooks/API).
Mô hình tư duy / Luồng
Một vòng lặp vận hành đơn giản là: phát hiện → phân loại (triage) → giảm thiểu → sửa → rút kinh nghiệm. Dùng GitLab issues để ghi lại incident và theo dõi các việc follow-up như công việc bình thường.
- Phát hiện qua alerts/dashboards (nội bộ hoặc bên ngoài).
- Triage: xác định mức độ nghiêm trọng và người phụ trách.
- Giảm thiểu: rollback, tắt feature flag, scale, v.v.
- Sửa qua MR + deploy.
- Học qua post-incident review và action items.
Đối tượng & Thuật ngữ
Bạn sẽ gặp các khái niệm này trong monitoring và incident workflows.
- Incident: gián đoạn dịch vụ cần phản ứng.
- Severity: phân loại mức độ ảnh hưởng/khẩn cấp.
- Runbook: các bước chẩn đoán/giảm thiểu được ghi lại.
- Postmortem: review sự cố và cách cải thiện.
- Smoke test: xác minh nhanh sau deploy.
- Alert routing: ai được thông báo và khi nào.
Máy trạng thái / Vòng đời
Định nghĩa mô hình trạng thái incident tối thiểu để ai cũng biết bước tiếp theo là gì.
- Open: incident đang diễn ra; đang giảm thiểu.
- Monitoring: đã giảm thiểu, theo dõi tái diễn.
- Resolved: dịch vụ ổn định; đã xác định nguyên nhân gốc.
- Follow-up: action items được theo dõi đến khi hoàn tất.
- Closed: bài học được ghi lại và chia sẻ.
Các “việc cần làm” cốt lõi
Đây là các việc monitoring/incident “starter” bạn có thể triển khai nhanh.
- Tạo incident issue template (severity, timeline, actions).
- Định nghĩa owner/rotation cho on-call response.
- Thêm xác minh sau deploy (checklist thủ công hoặc CI job).
- Tích hợp alerts để tự tạo issues (tuỳ chọn).
- Theo dõi follow-up tasks bằng milestones/boards.
Quyền hạn & Vai trò
Incident response cần cộng tác nhanh. Đảm bảo nhóm on-call có quyền tạo/sửa incident issues và có thể kích hoạt rollback/deploy theo quy định.
- Đảm bảo responders có thể tạo/sửa issues ở project/group liên quan.
- Giới hạn trigger deploy/rollback production cho nhóm tin cậy.
- Giữ các kênh liên lạc incident dễ truy cập.
- Dùng confidential issues cho incident nhạy cảm nếu cần.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Viết một incident template ngắn và dùng nhất quán.
- Giới hạn thời gian điều tra và ưu tiên giảm thiểu trước.
- Ghi timeline ngay khi đang xử lý (không để sau).
Không nên
- Đừng chờ nguyên nhân gốc “hoàn hảo” mới khôi phục dịch vụ.
- Đừng để follow-up actions biến mất—hãy track bằng issues.
- Đừng chạy thay đổi rủi ro khi đang incident nếu không có rollback rõ ràng.
Dữ liệu & Tích hợp
Monitoring thường tích hợp với công cụ bên ngoài; hãy giữ GitLab làm “hệ thống ghi nhận” (system of record) cho các việc incident.
- Dùng webhooks/API để tạo issues từ alerts (PagerDuty, Opsgenie, v.v.).
- Đẩy thông báo deployment lên chat tools.
- Lưu runbooks trong repo/Wiki để version hoá cập nhật.
- Gắn link dashboards/logs làm bằng chứng trong issues.
Happy path workflow #1: Xử lý incident bằng issue
- Tạo một incident issue bằng template.
- Đặt severity và chỉ định incident lead.
- Ghi nhận triệu chứng ban đầu và mức ảnh hưởng.
- Chạy các bước giảm thiểu (rollback/tắt feature/scale).
- Cập nhật issue với các mốc timeline khi hành động diễn ra.
- Khi ổn định, tạo follow-up issues (root cause, tests, cải thiện monitoring).
- Fix bằng MR và deploy; xác minh bằng smoke checks.
- Tổ chức post-incident review ngắn và đóng incident issue.
Happy path workflow #2: Thêm smoke check sau deploy
- Xác định 3–5 luồng người dùng quan trọng cần verify (login, API chính, mua hàng, v.v.).
- Triển khai smoke test nhẹ (script hoặc external check).
- Thêm CI job chạy sau deploy (hoặc checklist manual).
- Làm output của job rõ ràng (pass/fail + link logs).
- Fail fast: nếu smoke fail, rollback hoặc dừng promotion.
- Ghi lại kết quả trong deployment notes hoặc release issue.
- Tinh chỉnh smoke tests theo thời gian dựa trên incidents.
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Alert tự tạo issue? | Có: phản hồi nhanh hơn; cần tuning để tránh noise. | Không: bắt đầu thủ công; tự động hoá khi quy trình ổn định. |
| Xử lý theo severity | Cao: có incident lead riêng + cập nhật thường xuyên. | Thấp: workflow issue bình thường có thể đủ. |
| Giảm thiểu vs điều tra | Ưu tiên giảm thiểu nếu đang còn ảnh hưởng. | Điều tra sâu hơn khi dịch vụ đã ổn định. |
| Độ sâu postmortem | Nhẹ: review 15–30 phút cho sự cố nhỏ. | Sâu: postmortem có cấu trúc cho outage lớn. |
Lỗi thường gặp (và cách tránh)
- Không ghi timeline — Ghi mốc thời gian ngay khi làm; dán logs/links vào issue.
- Quá nhiều người “đụng tay” — Chỉ định incident lead; phân vai (comms, mitigation, scribe).
- Bỏ qua follow-ups — Tạo follow-up issues ngay và gán owner/deadline.
- Deploy fix rủi ro khi đang incident — Ưu tiên rollback/feature flag; ship fix sau khi ổn định.
- Không verify sau deploy — Thêm smoke checks và bước xem dashboard.
Thế nào là “tốt”
- Incidents được ghi lại với severity và timeline đầy đủ.
- Bước giảm thiểu rõ ràng và có thể đảo ngược.
- Follow-up actions được track bằng issues có owner.
- Có cơ chế xác minh sau deploy và đáng tin.
- Runbooks được cải thiện sau mỗi incident.
Checklist
Pre-check
- Có incident issue template.
- Đã định nghĩa on-call ownership.
- Có đường rollback cho dịch vụ quan trọng.
- Đã định nghĩa smoke checks cho critical paths.
- Responders truy cập được dashboards/logs.
Post-check
- Incident issue có timeline hoàn chỉnh.
- Nguyên nhân gốc và yếu tố góp phần được ghi lại (tuỳ mức độ).
- Follow-up issues đã được tạo và ưu tiên.
- Đã xác định cải tiến monitoring.
- Runbook được cập nhật theo bài học.
Bài thực hành (5–15 phút): Tạo incident template và chạy ‘tabletop’
Mục tiêu: Mô phỏng một outage nhỏ và luyện workflow.
Các bước
- Tạo một incident issue template.
- Tạo một incident giả và phân vai.
- Viết timeline ngắn các hành động (mô phỏng mitigation).
- Tạo 2 follow-up issues và đưa lên board.
- Đóng incident và viết 3 bài học rút ra.
Xác minh bạn làm đúng
- Template dễ dùng.
- Follow-up issues rõ việc và có người nhận.
- Bài học được ghi lại và nhìn thấy được.
Link tài liệu chính thức
- Trang tài liệu → Get started → Bắt đầu giám sát ứng dụng của bạn trong GitLab
- User docs → Incident management (nếu có trong cấu hình của bạn)
- User docs → Issues và templates
- CI/CD docs → Post-deploy jobs / environments
Bắt đầu mở rộng GitLab
Tài liệu → Bắt đầu mở rộng GitLab- Mở rộng qua webhooks (sự kiện) và API (hành động).
- Dùng token theo nguyên tắc ít quyền nhất (least privilege) và lưu trữ an toàn.
- Thiết kế tích hợp theo hướng idempotent và có giám sát.
- Ghi rõ người sở hữu và xoay vòng credential.
Mục đích / Kết quả
Mở rộng GitLab nghĩa là tích hợp GitLab với các công cụ của bạn và tự động hóa workflow thông qua webhooks, APIs và tokens. Tab này giúp bạn bắt đầu an toàn với mức truy cập tối thiểu cần thiết.
- Sử dụng đúng personal/project/group access tokens.
- Thiết lập webhooks cho các sự kiện bạn quan tâm.
- Gọi GitLab API để tự động hóa đơn giản.
- Xây tích hợp gọn nhẹ mà không làm suy giảm bảo mật.
Dành cho ai + Khi nào dùng
Dùng phần này khi bạn cần kết nối GitLab với chat, công cụ CI, hệ thống triển khai, cổng nội bộ, hoặc khi bạn muốn script để quản lý projects/issues/MRs.
- Kỹ sư tự động hoá các tác vụ admin lặp lại.
- Teams tích hợp thông báo lên chat.
- Platform teams xây tooling nội bộ.
- Bất kỳ ai cần đồng bộ dữ liệu giữa các hệ thống.
Vị trí trong điều hướng + Tab liên quan
Các “điểm mở rộng” thường nằm trong Settings của project/group (Integrations/Webhooks) và trong cài đặt hồ sơ (tokens).
- Liên quan: Projects (tích hợp ở mức project hoặc group).
- Liên quan: CI/CD (pipeline triggers, variables).
- Liên quan: Monitoring (tự động hoá alert → issue).
- Liên quan: Security (token scopes, least privilege).
Mô hình tư duy / Luồng
Mở rộng hoạt động bằng cách nhận sự kiện (webhooks) hoặc gửi yêu cầu (API). Giữ tích hợp tối giản: chỉ chọn các sự kiện và quyền bạn thực sự cần.
- Chọn nguồn sự kiện (project/group/system).
- Chọn phương thức gửi (webhook đến service của bạn).
- Xác thực bằng token có scope nhỏ nhất có thể.
- Xử lý retry và xác thực chữ ký (ở phía service của bạn).
- Ghi log/audit hành động và xoay vòng credential.
Đối tượng & Thuật ngữ
Đây là các khái niệm cốt lõi khi tích hợp GitLab bằng lập trình.
- Access token: credential để gọi API (nhiều loại).
- Token scopes: token được phép làm gì.
- Webhook: GitLab gửi payload sự kiện đến endpoint của bạn.
- Event types: push, merge request, issue, pipeline, release, v.v.
- Rate limits: giới hạn sử dụng API (tuỳ mô hình/phiên bản cung cấp).
Máy trạng thái / Vòng đời
Hãy coi tích hợp như hệ thống production và quản lý vòng đời rõ ràng.
- Prototype: scope tối thiểu + project test.
- Production: ít quyền nhất, monitoring, alerting.
- Rotation: xoay vòng token định kỳ và quản lý khoá.
- Deprecation: gỡ webhooks và tokens không dùng.
- Audit: rà soát quyền truy cập và logs định kỳ.
Các “việc cần làm” cốt lõi
Các tự động hoá “starter” cho hiệu quả nhanh.
- Đẩy thông báo MR/pipeline lên chat.
- Tự tạo issues từ alerts bên ngoài.
- Đồng bộ metadata dự án lên dashboard nội bộ.
- Kích hoạt pipelines từ hệ thống bên ngoài (công cụ release).
- Quản lý hàng loạt labels/members giữa các projects qua API.
Quyền hạn & Vai trò
Automation chỉ an toàn bằng đúng mức an toàn của credential. Luôn ưu tiên scope tối thiểu và cân nhắc dùng credential cấp project/group khi có thể.
- Ưu tiên project/group tokens cho automation có phạm vi hẹp (nếu có).
- Dùng Personal Access Tokens cẩn thận; đừng nhúng vào client apps.
- Giới hạn scopes ở read-only trừ khi thật sự cần quyền ghi.
- Lưu tokens trong secret stores hoặc CI/CD variables (protected/masked).
- Rotate/revoke token ngay nếu bị lộ.
Nên / Không nên & Bẫy thường gặp
Nên / Không nên & Bẫy thường gặp
Nên
- Xác thực chữ ký/token webhook ở phía receiver.
- Dùng idempotency để retry không tạo dữ liệu trùng.
- Ghi log hành động kèm correlation IDs (event ID, project ID).
Không nên
- Đừng cấp scope cấp admin cho tác vụ đọc đơn giản.
- Đừng hardcode token trong mobile/web clients hoặc repos.
- Đừng tạo nhiều webhooks chồng chéo—bắt đầu ít và có tài liệu rõ ràng.
Dữ liệu & Tích hợp
GitLab hỗ trợ nhiều tích hợp, nhưng các “khối xây” cốt lõi vẫn là: webhooks + API + CI triggers.
- Bắt đầu với một integration endpoint cho mỗi mục đích (chat, alerts, deploy).
- Dùng endpoint theo môi trường (staging vs prod).
- Giám sát lỗi (HTTP 4xx/5xx) trong webhook delivery logs.
- Ghi rõ người sở hữu tích hợp và điểm liên hệ.
Happy path workflow #1: Thêm webhook cho sự kiện merge request
- Tạo một endpoint/service nhận webhook (có thể là serverless function).
- Trong GitLab project settings, thêm webhook URL.
- Chọn loại sự kiện: merge request events.
- Thêm secret token/xác thực chữ ký trong receiver.
- Test delivery từ GitLab và xác nhận parse payload đúng.
- Đẩy thông báo lên chat hoặc ghi log để quan sát.
- Thêm hành vi an toàn khi retry (dedupe theo event ID).
- Giám sát và cảnh báo khi delivery fail lặp lại.
Happy path workflow #2: Dùng API để tự động hoá một việc lặp
- Chọn một tác vụ (vd: thêm label cho issues, liệt kê MRs, tạo milestone).
- Tạo access token với scope tối thiểu cần thiết.
- Viết script nhỏ gọi GitLab API endpoint.
- Test trên sandbox project trước.
- Thêm xử lý lỗi (rate limits, retries).
- Lưu token an toàn (không để trong code).
- Chạy script thủ công, rồi lên lịch nếu cần.
- Ghi tài liệu automation và cách vô hiệu hoá nó.
Điểm ra quyết định
| Tình huống | Nếu A… | Nếu B… |
|---|---|---|
| Cần push hay pull integration | Push: dùng webhooks cho sự kiện real-time. | Pull: dùng API polling nếu không dùng webhooks được. |
| Loại credential | Token có phạm vi hẹp (project/group) cho automation hẹp. | Personal token chỉ khi không có lựa chọn tốt hơn. |
| Lưu credential ở đâu | Secret store phía server / CI variables (protected). | Tuyệt đối không trong client apps hoặc repos. |
| Mức ảnh hưởng automation | Thấp: script chỉ đọc là an toàn nhất. | Cao: cần approvals/logging và giới hạn write scopes. |
Lỗi thường gặp (và cách tránh)
- Receiver webhook chấp nhận mọi request — Xác thực secret/chữ ký và giới hạn IP nếu có thể.
- Không dedupe khi retry — Dùng idempotency keys; bỏ qua event IDs trùng.
- Token scope quá rộng — Tạo token riêng cho từng automation với scope tối thiểu.
- Token nằm trong repo — Chuyển sang secret storage và rotate ngay.
- Không có monitoring — Cảnh báo khi lỗi lặp lại và theo dõi trạng thái webhook delivery.
Thế nào là “tốt”
- Tích hợp dùng token theo least-privilege và được rotate định kỳ.
- Webhook events được validate và retry idempotent.
- Thay đổi do automation được ghi log và audit được.
- Ownership và tài liệu rõ ràng.
- Tokens/webhooks không dùng được xoá bỏ.
Checklist
Pre-check
- Bạn biết chính xác event/action mình cần.
- Receiver endpoint sẵn sàng và đã được bảo vệ.
- Token scope tối thiểu và có tài liệu.
- Secrets được lưu ngoài code.
- Có test project để thử nghiệm an toàn.
Post-check
- Webhook deliveries thành công ổn định.
- Delivery trùng không gây tạo trùng.
- Logs có event IDs và kết quả.
- Có kế hoạch rotate token.
- Tích hợp có tài liệu kèm owner/liên hệ.
Bài thực hành (5–15 phút): Làm webhook ‘hello world’
Mục tiêu: Nhận một event từ GitLab và log an toàn.
Các bước
- Tạo endpoint log JSON body + headers (nhưng không log secrets).
- Thêm webhook ‘push events’ trong sandbox project.
- Thêm xác thực secret token.
- Push một commit để kích hoạt webhook.
- Xác nhận bạn đã log: project ID, user, ref, commit SHA.
Xác minh bạn làm đúng
- Request không có secret sẽ bị từ chối.
- Logs hiển thị đúng project/ref/commit.
- Không có giá trị nhạy cảm bị in ra.
Link tài liệu chính thức
- Docs home → Get started → Get started extending GitLab
- User docs → Webhooks / Integrations
- User docs → Personal access tokens
- API docs → GitLab REST API / GraphQL (tuỳ trường hợp)