GitLab

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ù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.

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).

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.

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.

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.

Đâ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.

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.

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.

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ù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.

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ộ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.

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.

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.

Đâ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ợ).

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.

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 độ.

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ù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.

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).

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.

Đâ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ộ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).

Đâ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 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.

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.

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ù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.

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).

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.

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).

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.

Đâ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).

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”.

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).

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ù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.

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).

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).

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ợ).

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).

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ỳ.

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ệ.

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.

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ù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.

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ộ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.

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).

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 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).

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.

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).

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ù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.

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).

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.

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ộ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.

Đâ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.

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ỳ.

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.

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ù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.

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ộ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.

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.

Đị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ẻ.

Đâ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.

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.

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.

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ù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.

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ở 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.

Đâ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).

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 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.

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ộ.

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ệ.