Gitlab

Design · Phạm Mạnh Lực

Gitlab ## 1. Phần Mở đầu: Bối cảnh & Nỗi đau ### Bạn có bao giờ gặp cảnh này không? Hãy tưởng tượng bạn đang làm việc nhóm...

GITLAB

1. Phần Mở đầu: Bối cảnh & Nỗi đau

Bạn có bao giờ gặp cảnh này không? Hãy tưởng tượng bạn đang làm việc nhóm để viết một báo cáo quan trọng (hoặc code một tính năng website).

  • Thảm họa 1: Bạn sửa file, đồng nghiệp cũng sửa đúng file đó. Khi lưu lại, máy tính hỏi: "Bạn có muốn ghi đè không?". Bùm! Công sức của đồng nghiệp biến mất.
  • Thảm họa 2: File báo cáo của bạn có tên: Bao_cao.docx, Bao_cao_v2.docx, Bao_cao_final.docx, Bao_cao_final_that_su.docx. Bạn không biết đâu là bản chuẩn nhất.
  • Thảm họa 3: Code chạy ngon lành trên máy bạn, nhưng khi gửi sang máy sếp để demo thì báo lỗi tùm lum. Bạn thốt lên câu kinh điển: "Ủa, trên máy em chạy bình thường mà!".

lamviecnhom

Tại sao bạn phải quan tâm đến GitLab? Nếu bạn làm việc một mình, bạn có thể quản lý thủ công. Nhưng trong thế giới công nghệ (và cả quản lý dự án hiện đại), chúng ta cần sự cộng tác.

GitLab sinh ra để chữa dứt điểm những nỗi đau trên. Nó không chỉ là nơi lưu trữ file, mà là một "Nhà máy dây chuyền tự động". Nó giúp bạn:

  • Lưu lại mọi phiên bản lịch sử (Ai sửa? Sửa gì? Lúc nào?).
  • Kết hợp công việc của nhiều người mà không đánh nhau.
  • Có các "Robot" tự động kiểm tra lỗi và đưa sản phẩm đến tay khách hàng.

Tóm lại: Nếu Google Drive là cái kho để đồ, thì GitLab là cái kho thông minh có cả bảo vệ, thư ký ghi chép và robot vận chuyển.

2. Phần Lý thuyết cốt lõi (20% Kiến thức xương sống)

Định nghĩa Ẩn dụ: GitLab là "Căn bếp Trung tâm Thông minh"

Đừng nghĩ GitLab là server hay cloud gì đó cao siêu. Hãy hình dung quy trình làm phần mềm giống như quy trình nấu ăn trong một chuỗi nhà hàng lớn.

Git (Công cụ nền tảng): Là cuốn Sổ tay công thức nấu ăn. Mỗi khi bếp trưởng thay đổi gia vị, ông ấy ghi lại vào sổ (Commit). Cuốn sổ này giúp ông ấy biết món ăn đã thay đổi thế nào qua các năm.

GitLab: Là toàn bộ Căn bếp Trung tâm (Facility).

  • Nó chứa cuốn sổ tay (Git).
  • Nó có các bàn sơ chế riêng cho từng phụ bếp (Branch).
  • Nó có dây chuyền nếm thử tự động (CI/CD) để đảm bảo món ăn không bị mặn trước khi mang ra cho khách.

Nguyên lý hoạt động (Input -> Process -> Output)

  • Input (Nguyên liệu): Lập trình viên viết code (hoặc nhân viên viết tài liệu) trên máy tính cá nhân.
  • Process (Quy trình trong bếp GitLab):
    • Họ đẩy (Push) code lên GitLab.
    • Họ tạo một "Yêu cầu hợp nhất" (Merge Request) - giống như nói: "Sếp ơi, em vừa chế biến xong món rau, sếp kiểm tra xem có trộn vào nồi lẩu chung được không?".
    • Các Robot (CI/CD Runners) tự động chạy kiểm tra: Code có lỗi cú pháp không? Có làm hỏng tính năng cũ không?
  • Output (Món ăn): Nếu Robot báo "Xanh" (Pass) và Sếp duyệt (Approve), code sẽ được nhập vào kho chính và tự động triển khai lên website cho người dùng.

3 Thuật ngữ "Sống còn" (Phải thuộc lòng)

Thuật ngữ Giải thích đời thường (Ẩn dụ) Ví dụ thực tế
Repository (Repo) Cái Kho Tổng. Nơi chứa tất cả code, tài liệu, lịch sử chỉnh sửa của dự án. Giống như một folder dự án trên Google Drive, nhưng xịn hơn gấp 10 lần.
Branch (Nhánh) Bản nháp/Vũ trụ song song. Bạn copy kho tổng ra một bản riêng để vọc vạch mà không ảnh hưởng đến bản chính. Bạn muốn thử đổi màu logo website sang màu hồng. Bạn tạo nhánh thu-nghiem-mau-hong. Nếu xấu thì xóa, bản chính (màu xanh) vẫn an toàn.
Merge Request (MR) Phiếu trình ký. Sau khi vọc vạch xong ở Branch, bạn gửi yêu cầu này để xin nhập cái mới vào cái cũ. "Sếp ơi, em sửa xong lỗi đăng nhập rồi, sếp xem code và cho em nhập vào bản chính nhé."
CI/CD Dây chuyền Robot. Tính năng "ăn tiền" nhất của GitLab. Tự động hóa việc kiểm tra và giao hàng. Bạn vừa lưu file code, GitLab tự động chạy 100 bài test. Nếu đúng, nó tự copy file đó lên server thật. Bạn không cần làm thủ công.

3. Phần Ứng dụng thực tế (80% Giá trị thực chiến)

Case Study 1: Team Lập trình & Nỗi lo "Code rác" (Minh họa Branching)

  • Bối cảnh: Một nhóm 5 lập trình viên cùng làm một App bán hàng.
  • Vấn đề: Ông A sửa tính năng "Giỏ hàng", ông B sửa tính năng "Thanh toán". Cả hai cùng sửa một file cấu hình chung. Khi gộp lại, App sập vì code đá nhau. Hơn nữa, ông A hay quên dấu chấm phẩy (syntax error) làm cả hệ thống ngừng chạy.

GitLab giải quyết thế nào?

  1. Phân nhánh (Branching): Ông A làm trên nhánh feature/cart, ông B làm trên nhánh feature/payment. Không ai đụng ai.
  2. Merge Request & Review: Khi ông A làm xong, tạo MR. Ông B vào đọc code (Code Review) và bình luận ngay trên dòng code: "Đoạn này logic sai rồi A ơi".
  3. CI (Robot kiểm tra): Ngay khi ông A đẩy code lên, GitLab Runner tự động chạy test. Nếu thiếu dấu chấm phẩy, Robot báo đỏ (Fail) ngay lập tức. Ông A không thể nhập code lỗi vào kho chung được.

Kết quả: Code trong kho chính (Master/Main branch) luôn sạch và chạy tốt.

Case Study 2: Team Marketing & Quản lý nội dung (Docs as Code)

  • Bối cảnh: Team Marketing quản lý trang Blog của công ty. Bài viết cần sửa đổi liên tục, qua nhiều người duyệt (Content Writer -> Editor -> Manager).
  • Vấn đề: Gửi file Word qua lại qua Zalo/Email rất lộn xộn. Lỡ tay xóa mất đoạn văn hay ho từ tuần trước không khôi phục được.

GitLab giải quyết thế nào?

  • Version Control: Mỗi bài viết là một file Markdown. Mỗi lần sửa câu chữ, GitLab lưu lại một "Commit".
  • So sánh (Diff): Manager có thể xem chính xác Editor đã sửa từ ngữ nào (GitLab hiện màu đỏ cho chữ bị xóa, màu xanh cho chữ được thêm vào).
  • Rollback (Quay ngược thời gian): Nếu bài viết mới đăng bị sai thông tin nghiêm trọng, chỉ cần 1 cú click để khôi phục lại phiên bản cũ từ hôm qua.

Case Study 3: Freelancer & Khách hàng khó tính (Minh họa CI/CD)

  • Bối cảnh: Bạn làm website cho khách. Khách muốn xem tiến độ hàng ngày nhưng bạn ngại deploy (đưa web lên mạng) thủ công vì tốn thời gian cài đặt.
  • Vấn đề: Khách hỏi: "Hôm nay làm được gì rồi?". Bạn phải chụp màn hình gửi, rất thiếu chuyên nghiệp.

GitLab giải quyết thế nào?

  • Auto DevOps (CD): Bạn cấu hình GitLab CI/CD.
  • Mỗi khi bạn code xong một tính năng (ví dụ: xong cái Banner), bạn đẩy code lên GitLab.
  • GitLab tự động đóng gói và đưa lên một trang web dùng thử (Staging environment).
  • Bạn chỉ cần gửi link cho khách: "Anh vào link này xem nhé, em mới cập nhật Banner".

Kết quả: Khách hàng hài lòng vì thấy tiến độ thực tế, bạn rảnh tay tập trung code.

ci/cd

Bảng Ưu/Nhược điểm của GitLab

Đặc điểm Ưu điểm (Được gì?) Nhược điểm (Mất gì?)
Tính năng "All-in-one". Có cả quản lý dự án (như Trello), chứa code, CI/CD mạnh mẽ nhất hiện nay. Vì quá nhiều tính năng nên giao diện hơi rối rắm cho người mới (so với GitHub).
Triển khai Cho phép cài đặt trên máy chủ riêng của công ty (Self-managed). Tuyệt vời cho bảo mật dữ liệu. Cần kiến thức quản trị hệ thống nếu muốn tự cài đặt bản riêng (thay vì dùng bản Cloud).
Chi phí Bản miễn phí (Free tier) cực kỳ hào phóng, cho phép tạo kho riêng tư (Private repo) không giới hạn. Bản trả phí khá đắt nếu bạn cần các tính năng quản lý cấp cao cho doanh nghiệp lớn.

4. Góc nhìn đa chiều

Hiểu lầm phổ biến

  • "GitLab và GitHub là một": Sai.
    • GitHub: Giống như mạng xã hội của lập trình viên (Facebook for Devs). Nổi tiếng về mã nguồn mở.
    • GitLab: Giống như một nhà máy khép kín cho doanh nghiệp. Mạnh hơn về quy trình tự động hóa (DevOps).
  • "GitLab chỉ dành cho Coder": Sai. Designer, Tester, Project Manager đều dùng được. Nó có bảng Kanban (giống Trello) để quản lý task, có Wiki để viết tài liệu.

Cảnh báo quan trọng (Rủi ro bảo mật)

  • Một lỗi sơ đẳng của người mới (Newbie): Đừng bao giờ viết mật khẩu (password database, API Key) trực tiếp vào code rồi đẩy lên GitLab.
  • Dù bạn có xóa dòng đó đi, lịch sử (History) vẫn còn lưu lại. Hacker có thể lục lại quá khứ để lấy mật khẩu.
  • Giải pháp: Hãy dùng tính năng "CI/CD Variables" (Biến môi trường) trong phần cài đặt của GitLab để giấu mật khẩu.

a

5. Thực hành & Hành động

Bạn không thể học bơi bằng cách đọc sách. Hãy dành 30 phút làm ngay các bước sau:

Bước 1: Tạo tài khoản và "Nhà bếp" đầu tiên (5 phút)

  • Truy cập gitlab.com và đăng ký tài khoản miễn phí.
  • Bấm nút "New Project" -> Chọn "Create blank project".
  • Đặt tên: Du-an-dau-tay. Chọn chế độ Private (Riêng tư).
  • Tick vào ô "Initialize repository with a README". Bấm Create project.

Bước 2: Tập làm "Bếp trưởng" (10 phút)

  • Vào file README.md (đây là file giới thiệu dự án), bấm nút Edit (hoặc Web IDE).
  • Viết vài dòng giới thiệu bản thân.
  • Kéo xuống dưới, phần Commit message, viết: "Cập nhật giới thiệu lần đầu".
  • Bấm Commit changes.
  • Chúc mừng! Bạn vừa tạo một "Save point" đầu tiên.

Bước 3: Thử tạo Nhánh và Hợp nhất (15 phút)

  • Tìm nút (+) cạnh tên file hoặc menu Branch, tạo một branch mới tên là thu-nghiem.
  • Chuyển sang nhánh thu-nghiem, sửa lại nội dung file README (ví dụ thêm sở thích). Commit lại.
  • Bây giờ, hãy tìm nút "Create Merge Request".
  • Bạn sẽ thấy giao diện so sánh: Bên trái là bản gốc, bên phải là bản bạn vừa sửa.
  • Bấm Merge. Nội dung từ thu-nghiem sẽ được nhập vào bản chính.

6. Tổng kết & Kiểm tra

3 Điểm cốt lõi phải nhớ (Take-away)

  1. GitLab là kho thông minh: Không chỉ lưu code (Repository), mà còn quản lý quy trình làm việc từ A-Z.
  2. Tư duy Branching (Phân nhánh): Luôn tạo bản nháp (Branch) để làm việc, không bao giờ sửa trực tiếp trên bản chính (Master/Main) nếu làm việc nhóm.
  3. CI/CD là vũ khí bí mật: Tự động hóa việc kiểm tra và triển khai giúp tiết kiệm thời gian và giảm lỗi con người.

Câu hỏi kiểm tra tư duy

  • Tình huống: Bạn lỡ tay xóa một file quan trọng và đã lỡ bấm "Lưu". GitLab có cứu được bạn không? Bằng cách nào?
  • Tư duy: Tại sao người ta nói "Merge Request" là nơi quan trọng nhất để học hỏi trong team lập trình?
  • So sánh: Sự khác biệt lớn nhất giữa việc gửi file code qua Zalo và dùng GitLab là gì?
  • Ứng dụng: Nếu bạn là một nhà văn viết tiểu thuyết, bạn có thể dùng GitLab để quản lý các chương truyện không? Branch sẽ đóng vai trò gì?
  • Thuật ngữ: Trong ẩn dụ "Nhà bếp trung tâm", CI/CD tương ứng với bộ phận nào?

Bạn hãy để lại câu trả lời cho phần bài tập dưới phần bình luận nhé!