CI/CD là gì? Triển khai quy trình CI/CD với Gitlab

CI/CD là gì? Tầm quan trọng của quy trình CI CD là gì và tại sao bạn nên sử dụng chúng để phát triển phần mềm? Bài viết này sẽ cung cấp cho bạn câu trả lời cho câu hỏi đó và hơn thế nữa.

CI/CD là gì?

CI/CD là một bộ đôi công việc, bao gồm CI (Continuous Integration) và CD (Continuous Delivery) hoặc Continuous Deployment (Triển khai liên tục), ý nói là quá trình tích hợp (integration) thường xuyên, nhanh chóng hơn khi code cũng như thường xuyên cập nhật phiên bản mới (delivery).

Continuous Integration (CI)

Continuous Integration (CI) là một quy trình tự động hóa cho phép các nhà phát triển thường xuyên hợp nhất các thay đổi mã nguồn trở lại một nhánh chia sẻ hoặc “trunk”. Khi các cập nhật này được thực hiện, các bước kiểm tra tự động sẽ được kích hoạt để đảm bảo tính ổn định của các thay đổi mã nguồn đã hợp nhất.

Trong phát triển ứng dụng hiện đại, mục tiêu là có nhiều nhà phát triển làm việc đồng thời trên các tính năng khác nhau của cùng một ứng dụng. Tuy nhiên, nếu tổ chức chỉ hợp nhất tất cả các nhánh mã nguồn vào một ngày (gọi là “merge day”), công việc này có thể trở nên tẻ nhạt, thủ công và tốn thời gian.

Nguyên nhân là khi một nhà phát triển làm việc riêng lẻ thay đổi ứng dụng, có khả năng sẽ xung đột với các thay đổi đang được thực hiện đồng thời bởi các nhà phát triển khác. Vấn đề này càng phức tạp hơn nếu mỗi nhà phát triển tùy chỉnh môi trường phát triển tích hợp (IDE) của riêng mình thay vì cả nhóm đồng ý sử dụng một IDE dựa trên đám mây.

CI có thể được coi là giải pháp cho vấn đề có quá nhiều nhánh của một ứng dụng đang được phát triển cùng lúc mà có thể xung đột với nhau.

Thành công của CI có nghĩa là sau khi các thay đổi của nhà phát triển đối với ứng dụng được hợp nhất, các thay đổi đó sẽ được xác nhận bằng cách tự động xây dựng ứng dụng và chạy các mức độ kiểm tra tự động khác nhau, thường là kiểm tra đơn vị và kiểm tra tích hợp, để đảm bảo các thay đổi không phá vỡ ứng dụng. Điều này bao gồm kiểm tra mọi thứ từ các lớp và chức năng đến các module khác nhau cấu thành toàn bộ ứng dụng. Một trong những lợi ích của CI là nếu kiểm tra tự động phát hiện xung đột giữa mã nguồn mới và mã nguồn hiện có, việc sửa lỗi sẽ dễ dàng và nhanh chóng hơn.

Continuous Delivery (CD)

Continuous Delivery (CD) tự động hóa việc phát hành mã nguồn đã được xác nhận vào một kho lưu trữ sau khi tự động xây dựng và kiểm tra đơn vị và kiểm tra tích hợp trong CI. Vì vậy, để có quy trình Continuous Delivery hiệu quả, CI cần phải được tích hợp sẵn vào quy trình phát triển.

Trong Continuous Delivery, mỗi giai đoạn từ hợp nhất các thay đổi mã nguồn đến việc giao các bản xây dựng sẵn sàng cho sản xuất đều bao gồm tự động hóa kiểm tra và phát hành mã nguồn. Cuối cùng, đội ngũ vận hành có thể triển khai ứng dụng vào môi trường sản xuất một cách nhanh chóng.

Continuous Delivery thường có nghĩa là các thay đổi của nhà phát triển đối với ứng dụng được kiểm tra lỗi tự động và tải lên một kho lưu trữ (như GitHub hoặc container registry), nơi chúng có thể được triển khai vào môi trường sản xuất thực tế bởi đội ngũ vận hành. Đây là câu trả lời cho vấn đề về sự thiếu minh bạch và giao tiếp giữa các nhóm phát triển và kinh doanh. Mục đích của Continuous Delivery là có một mã nguồn luôn sẵn sàng để triển khai vào môi trường sản xuất và đảm bảo rằng việc triển khai mã nguồn mới cần ít nỗ lực nhất có thể.

Continuous Deployment

Continuous Deployment là giai đoạn cuối cùng của một pipeline CI/CD trưởng thành. Continuous Deployment là một phần mở rộng của Continuous Delivery và có thể đề cập đến việc tự động hóa phát hành các thay đổi của nhà phát triển từ kho lưu trữ vào sản xuất, nơi chúng có thể được sử dụng bởi khách hàng.

Continuous Deployment giải quyết vấn đề quá tải đội ngũ vận hành với các quy trình thủ công làm chậm quá trình giao ứng dụng. Nó xây dựng trên các lợi ích của Continuous Delivery bằng cách tự động hóa giai đoạn tiếp theo trong pipeline.

Trong thực tế, Continuous Deployment có nghĩa là các thay đổi của nhà phát triển đối với một ứng dụng đám mây có thể được triển khai trực tiếp trong vài phút sau khi viết (với điều kiện là nó vượt qua các bài kiểm tra tự động). Điều này làm cho việc nhận và tích hợp phản hồi của người dùng liên tục trở nên dễ dàng hơn. Tất cả các thực hành CI/CD liên kết với nhau làm cho quy trình triển khai ít rủi ro hơn, dễ dàng hơn khi phát hành các thay đổi cho ứng dụng theo từng phần nhỏ thay vì tất cả cùng một lúc.

Tuy nhiên, vì không có bước kiểm tra thủ công nào trước khi đưa vào sản xuất, Continuous Deployment phụ thuộc nhiều vào việc thiết kế tốt các bài kiểm tra tự động. Điều này có nghĩa là Continuous Deployment có thể yêu cầu một khoản đầu tư lớn ban đầu vì các bài kiểm tra tự động sẽ cần được viết để phù hợp với nhiều giai đoạn kiểm tra và phát hành trong pipeline CI/CD.

Tại sao phải quan tâm đến CI/CD?

Ngày nay, với xu hướng agile/lean dẫn đến việc phát triển tính năng là điều bình thường, quan trọng phải là thần thái, ý lộn, quan trọng là phải nhanh. Nếu một tính năng mà mất 2, 3 tháng mới release thì dẫn đến nhiều hệ lụy như làm không phù hợp nhu cầu khách hàng, hoặc đối thủ đã ra mắt trước đó, mất đi cái lợi thế dẫn đầu. Do đó, việc làm ra một sản phẩm, tính năng đòi hỏi thần tốc là ưu tiên số một hiện nay.

Bên cạnh đó, để nhanh chóng ra mắt một tính năng, phiên bản mới nếu theo cách cổ điển sẽ mất nhiều thời gian bởi công việc chân tay khá nhiều và mỗi lần release cũng huy động một cơ số người không nhỏ để cập nhật một thay đổi dù là nhỏ nhất. Bởi vậy, xu hướng CI/CD giúp cung cấp các framework, workflow giúp tiết kiệm thời gian, nguồn lực của quá trình release (delivery).

Ưu điểm và nhược điểm của CI/CD

Ưu điểm của CI/CD

1. Mã nguồn nhỏ hơn và đơn giản hơn: Các thay đổi mã nguồn nhỏ hơn, dễ kiểm tra và ít gây ra các hậu quả không mong muốn.
2. Giảm thời gian trung bình để giải quyết (MTTR): Các vấn đề được phát hiện và sửa chữa nhanh chóng hơn, giúp giảm thời gian trung bình để khắc phục sự cố.
3. Cô lập lỗi tốt hơn và nhanh hơn: Dễ dàng xác định và cô lập các lỗi trong mã nguồn, giảm thiểu ảnh hưởng đến các phần khác của hệ thống.
4. Tăng độ tin cậy của kiểm tra: Do các thay đổi mã nguồn nhỏ hơn và cụ thể hơn, các bài kiểm tra trở nên đáng tin cậy hơn.
5. Tăng tốc độ phát hành: Tốc độ phát hành tăng giúp phát hiện và sửa chữa lỗi nhanh hơn, cải thiện quy trình phát triển.
6. Giảm số lượng lỗi không quan trọng: Sử dụng CI/CD giúp giảm số lượng lỗi không quan trọng tồn đọng trong danh sách công việc.
7. Nhận phản hồi từ khách hàng và nhân viên: CI/CD giúp thu thập phản hồi từ khách hàng và nhân viên nhanh chóng hơn, cải thiện sản phẩm.
8. Tự động hóa giảm thiểu lỗi: Tự động hóa trong CI/CD giảm thiểu số lượng lỗi có thể xảy ra trong các bước của pipeline CI/CD.

Nhược điểm của CI/CD

1. Doanh nghiệp phải luôn cảnh giác và thực hiện lặp lại: Tránh việc tự động hóa sai quy trình ngay từ đầu và cần phải cẩn trọng trong việc chọn thứ tự đúng của quy trình.
2. Mã nguồn phải sẵn sàng và được đưa vào sản xuất ngay lập tức: Tính khẩn trương này có thể gây lo lắng cho doanh nghiệp nếu mã nguồn phải được triển khai ngay khi kết quả hiện tại thành công.
3. Dashboard có thể không quen thuộc với tất cả các thành viên: Các nhóm có thể tạo ra một dashboard mà không phải thành viên nào cũng biết trước, dẫn đến các sai lầm logic.
4. Cần đồng bộ hóa CI và CD: CI và CD cần phải được thực hiện đồng bộ với nhau. Điều này đòi hỏi sự chú ý và chi tiết từ yếu tố con người để đảm bảo hoạt động trơn tru.

CI/CD khác gì DevOps?

CI/CD là một phần quan trọng của phương pháp DevOps, nhưng hai khái niệm này không hoàn toàn giống nhau:

• CI/CD: Tập trung vào việc tự động hóa quy trình tích hợp và triển khai mã nguồn, giảm thiểu lỗi và tăng tốc độ phát hành phần mềm.
• DevOps: Tập trung vào việc hợp tác giữa các nhóm phát triển và vận hành, tự động hóa các quy trình để cải thiện hiệu quả và chất lượng của các bản phát hành phần mềm. DevOps bao gồm CI/CD như một phần của quy trình tự động hóa tổng thể.

Tầm quan trọng của DevSecOps:

DevSecOps nhấn mạnh rằng an ninh cần được tích hợp từ đầu đến cuối trong quy trình DevOps. Điều này bao gồm việc:

• Tích hợp an ninh vào CI/CD pipeline: Đảm bảo rằng các bước kiểm tra an ninh được thực hiện tự động trong suốt quy trình tích hợp và triển khai mã nguồn.
• Chia sẻ trách nhiệm an ninh: Tất cả các nhóm liên quan (phát triển, vận hành, an ninh) đều chịu trách nhiệm về an ninh của ứng dụng.
• Cải thiện nhận thức và kỹ năng về an ninh: Đào tạo và nâng cao nhận thức về an ninh cho tất cả các thành viên trong nhóm để họ có thể phát hiện và xử lý các vấn đề an ninh một cách hiệu quả.

Vậy ta có thể hiểu tóm gọn như sau:

• CI/CD: Tự động hóa quy trình tích hợp và triển khai mã nguồn.
• DevOps: Hợp tác giữa các nhóm phát triển và vận hành, tối ưu hóa quy trình phát triển và triển khai phần mềm.
• DevSecOps: Tích hợp an ninh vào quy trình DevOps từ đầu đến cuối, đảm bảo an ninh là trách nhiệm chung.

CI/CD là một phần quan trọng trong DevOps, giúp tăng tốc độ và độ tin cậy của các bản phát hành phần mềm, trong khi DevOps giúp cải thiện sự hợp tác và hiệu quả tổng thể. DevSecOps bổ sung thêm yếu tố an ninh, đảm bảo rằng các ứng dụng được phát hành một cách an toàn và bảo mật.

CI/CD Pipeline là gì?

CI/CD Pipeline là một chuỗi các bước tự động hóa được sử dụng để đảm bảo rằng mã nguồn được kiểm tra, tích hợp, và triển khai một cách nhất quán và an toàn. Pipeline này bao gồm tất cả các giai đoạn từ khi một nhà phát triển commit mã nguồn vào hệ thống cho đến khi mã nguồn được triển khai vào môi trường sản xuất.

Các thành phần chính của CI/CD Pipeline

1. Source Stage (Giai đoạn nguồn): Giai đoạn này bắt đầu khi một nhà phát triển commit mã nguồn mới vào hệ thống quản lý mã nguồn (như Git). Việc commit này sẽ kích hoạt pipeline CI/CD.
2. Build Stage (Giai đoạn xây dựng): Mã nguồn được biên dịch và xây dựng thành các gói ứng dụng hoặc container. Giai đoạn này đảm bảo rằng mã nguồn có thể được xây dựng thành công và sẵn sàng cho các bước kiểm tra tiếp theo.
3. Test Stage (Giai đoạn kiểm tra): Mã nguồn được kiểm tra bằng cách chạy các bài kiểm tra tự động như unit tests, integration tests, và end-to-end tests. Giai đoạn này nhằm đảm bảo rằng mã nguồn không có lỗi và hoạt động như mong đợi.
4. Deploy Stage (Giai đoạn triển khai): Mã nguồn đã qua kiểm tra được triển khai vào các môi trường staging hoặc production. Triển khai có thể được thực hiện tự động (continuous deployment) hoặc yêu cầu sự chấp thuận của con người (continuous delivery)

Ví dụ về CI/CD Pipeline

• Developer Commit: Nhà phát triển commit mã nguồn mới vào hệ thống Git.
• Automated Build: Hệ thống CI/CD tự động biên dịch mã nguồn và xây dựng thành gói ứng dụng.
• Automated Testing: Hệ thống chạy các bài kiểm tra tự động để đảm bảo mã nguồn không có lỗi.
• Staging Deployment: Mã nguồn đã kiểm tra được triển khai vào môi trường staging để kiểm tra cuối cùng.
• Production Deployment: Nếu mã nguồn vượt qua tất cả các bài kiểm tra, nó được triển khai vào môi trường production.
• Monitoring and Feedback: Hệ thống giám sát và thu thập phản hồi từ người dùng để cải thiện các phiên bản tiếp theo.

Áp dụng CI/CD với Gitlab 9

Trong khuôn khổ bài viết này, mình sẽ hướng dẫn mọi người cài đặt Gitlab 9 để quản lý source code, và trên công nghệ Git. Đòi hỏi của tất cả setup này là trên server đã cài Docker, nếu các bạn chưa có docker trên server thì có thể tham khảo các bài viết về docker trên TopDev cũng như tìm kiếm thêm trên google.

Bạn chạy câu lệnh sau để tạo một container chứa Gitlab 9.

docker run --detach 
--hostname code.teamcrop.com 
--publish 8080:80 --publish 2222:22 
--name gitlab9 
--restart=always 
--volume /gitlab9/config:/etc/gitlab 
--volume /gitlab9/logs:/var/log/gitlab 
--volume /gitlab9/data:/var/opt/gitlab 
gitlab/gitlab-ce:9.0.3-ce.0

Nếu ai từng dùng docker sẽ hiểu ý nghĩa câu lệnh trên. Đơn giản là mình sử dụng image gitlab/gitlab-ce:9.0.3-ce.0. Có mount ra 3 thư mục bên ngoài máy ở thục mục /gitlab9 để lỡ có chuyện gì chỉ cần stop, remove container, khi chạy docker run lại thì không bị mất dữ liệu, source code. Câu lệnh trên có map 2 port là 8080 và 2222 tương ứng tới 2 port 80 và 22 trong container. Mình mapping port vậy bởi vì trên server dev này có rất nhiều service khác và đã chiếm port 80 và 22 (ssh ^^!).

Sau khi bạn start container thì có thể truy cập vào từ ip hoặc domain (mà bạn đã trỏ DNS), ví dụ: http://code.teamcrop.com:8080 là có thể vào gitlab 9, tài khoản mặc định là `root`.

Không có gì cao siêu ở cài đặt này, có thể tham khảo thêm ở trang chủ của Gitlab.com nhé.

Quản lý sourcecode bằng Gitlab

Về phần này thì mình không cần nói dài dòng, cũng như một hệ thống git thông thường (như github..), bạn có thể tìm hiểu thêm về git và Gitlab để team có thể cùng làm việc và quản lý sourcecode trên Gitlab.

CI/CD với Gitlab CI

Thông thường, các hệ thống quản lý sourcecode không kèm theo cơ chế CI/CD. Nếu bạn muốn triển khai thì buộc phải liên kết đến repository, phân quyền đủ kiểu để hệ thống đó có thể lấy source code từ respository. Trước đây bên mình sử dụng Jenkins cho việc này. Tuy nhiên, từ khi Gitlab ra mắt tính năng Gitlab CI, kèm theo sự chậm chạp, rắc rối và rề rề của Jenkins thì mình quyết định chia tay với Jenkins và đến với Gitlab CI luôn, và quả là một bộ đôi hoàn hảo. Code để ở Gitlab, rồi trong đó có cho cài đặt CI/CD để test và deploy code tự động.

Cũng như một số bạn mới lần đầu tiếp xúc với Gitlab CI, mình đã từng thấy nó khó hiểu và cao siêu vì setup tùm lum. Rồi setup xong lại không biết nó chạy thế nào, cơ chế deploy source code ra sao. Tuy nhiên, sau một vài “va chạm” đầy mồ hôi và nước mắt thì cũng nắm và hiểu được cách Gitlab CI vận hành, và nay chia sẻ cho mọi người để vận dụng cho workflow của mình.

Để dùng được Gitlab CI thì bạn cần có 2 thành phần sau: file `.gitlab-ci.yml` nằm ở thư mục gốc của dự án và Gitlab Runner.

Tham khảo thêm việc làm lập trình GIT lương cao tại Topdev

File .gitlab-ci.yml là gì?

Mặc định Gitlab không có cơ chế nào về CI cho dự án của bạn, chỉ khi nào dự án của bạn có file .gitlab-ci.yml nằm ở thư mục gốc thì Gitlab mới nhận dạng được dự án của bạn muốn áp dụng Gitlab CI. File này có định dạng và cần hợp lệ thì mới có thể hoạt động được, không thì khi bạn push code lên thì Gitlab sẽ báo lỗi file định dạng nội dung của file cấu hình không hợp lệ. Tham khảo cú pháp của cấu hình này tại https://docs.gitlab.com/ce/ci/yaml/

Trong file này có gì? File này có một số section để khai báo như trước khi chạy test thì làm gì, khi test thì thực hiện lệnh gì (vd chạy linter check cú pháp, chạy PHPUnit test…), test xong rồi thì thực hiện deploy đi đâu (beta, production..) với câu lệnh gì (vd: rsync..). Tùy đặc thù ngôn ngữ lập trình, cách đóng gói của dự án mà sẽ có các lệnh tương ứng thực hiện.

Tới đây các bạn sẽ có câu hỏi là vậy cái gì sẽ chạy, thực thi các câu lệnh, chỉ dẫn trong file config trên? Hay là Gitlab Server sẽ chạy. Nếu là Gitlab server chạy thì nếu dự án mình thực hiện những lệnh không có thì sao, vì gitlab server thì cũng chỉ chứa gitlab và các program cho nó chứ đâu thể cài sẵn các program? Bên cạnh đó, mỗi lần chạy thì các thông tin liên quan đến file tạm có bị reset lại hay không?

Nếu bạn đi đến đây thì bạn đã đoán được là thực ra “cái thứ” thực thi các chỉ dẫn, câu lệnh trong file .gitlab-ci.yml không phải là Gitlab Server (là cái container đang chạy gitlab 9 mình start ở trên), mà đó chính là Gitlab Runner. Wow! Welcome to matrix!

Gitlab Runner là gì?

Gitlab Runner là thành phần cực kỳ quan trọng trong workflow Gitlab CI. Nếu không có Runner thì sẽ không có lệnh test, deploy nào được thực thi. Runner có nhiều loại, phân biệt dựa vào cái gọi là executor. Khi khởi tạo runner, bạn sẽ phải chọn nó là loại executor nào, và nó sẽ quyết định môi trường thực thi các câu lệnh trong file config ở trên. Bạn có thể tham khảo link https://docs.gitlab.com/runner/executors/ để biết sự khác nhau của các executor cũng như cách cài đặt, cấu hình chúng.

Do đặc thù hệ thống đã có docker, nên bên mình chỉ sử dụng executor loại Docker mà thôi. Và bên dưới là câu lệnh docker để start một Gitlab Runner.

docker run -d --name gitlab-runner --restart always 
-v /srv/gitlab-runner/config:/etc/gitlab-runner 
-v /var/run/docker.sock:/var/run/docker.sock 
gitlab/gitlab-runner:latest

Ở đây bạn sẽ thấy container này mount thư mục config ra ngoài, bởi vì mình muốn các cấu hình của runner không bị mất khi stop/remove container. Chỉ cần start lại là giữ được cấu hình. Ngoài ra, nó còn mount docker.sock vào bên trong container, đây là cách để executor loại docker có thể tận dụng lệnh docker bên ngoài host để thực hiện lệnh tạo container phụ trong quá trình runner chạy (test, deploy).

Start container lên chỉ là bước đầu, bởi vì lưu ý là tới thời điểm này, Runner này không có liên quan gì đến Gitlab server của chúng ta. Cần một bước link lại (gọi là register) runner này vào trong Gitlab server để mình có thể cho phép các dự án dùng runner trong quá trình CI/CD.

Xem link này https://docs.gitlab.com/runner/register/index.html để biết cách register runner này vào Gitlab Server.

Dưới đây là hình ảnh tham khảo bạn có thể dùng trong quá trình register 1 runner. Có 2 thông tin quan trọng là 1 cái URL và một random token. Và cái URL đặc biệt lưu ý là thường thêm /ci sau domain. Ví dụ ở trường hợp của mình setup là http://code.teamcrop.com/ci

Sau khi Runner đã được gán vào Gitlab Server, bạn có thể enable runner này cho một hoặc nhiều dự án trong Gitlab. Hình bên dưới minh họa việc gán Runner vào dự án trong phần cài đặt Pipeline của Gitlab 9.

Đến đây hầu như đã cấu hình xong. Dự án đã kích hoạt 1 runner, và dự án đã có file .gitlab-ci.yml. Từ bây giờ, mỗi lần code được đưa lên thì runner sẽ thực thi test cũng như deploy dựa trên các câu lệnh được khai báo trong file cấu hình.

Khai báo biến để dùng trong các câu lệnh

Trong một số trường hợp, bạn có thể khai báo biến để có thể dùng trong các lệnh của runner. Có 3 nơi có thể cấu hình biến:

1. Cấu hình ngay bên trong file .gitlab-ci.yml
2. Cấu hình trong dự án. Vào Settings // CI/CD Pipelines, phần Secret variables (xem hình)

3. Cấu hình bên trong file config của runner.

Bạn có nhớ lúc mình khởi tạo runner, có chỉ định một thư mục chứa config không, đây chính là nơi cấu hình chung cho runner này. Trong thư mục này sẽ có file là config.toml. Và bạn có thể gán biến trong cấu hình của từng runner. Cấu hình ở đây có một lợi thế là cứ runner này chạy sẽ nhận được biến đã cấu hình. Bạn không cần phải cấu hình nhiều lần ở từng dự án.

Ví dụ về một file .gitlab-ci.yml

Bên dưới là file cấu hình của một dự án trong hệ thống Microservices thuộc Teamcrop:

before_script:

- export "PATH=$PATH:/vendor/bin"
# Install ssh-agent if not already installed, it is required by Docker.
# (change apt-get to yum if you use a CentOS-based image)
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'

# Run ssh-agent (inside the build environment)
- eval $(ssh-agent -s)

# For Docker builds disable host key checking. Be aware that by adding that
# you are suspectible to man-in-the-middle attacks.
# WARNING: Use this only with the Docker executor, if you use it with shell
# you will overwrite your user's SSH config.
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *ntStrictHostKeyChecking nonn" > ~/.ssh/config'

variables:

# Change this base on project name
DEPLOYMENT_FOLDER_NAME: "tc-file"

test:

image: voduytuan/gitlab-php-ci
script:
- bash ./ci/phplint.sh ./src/
- phpcs --config-set ignore_errors_on_exit 1
- phpcs --config-set ignore_warnings_on_exit 1
- phpcs --standard=PSR2 --ignore=./src/index.php --error-severity=1 --warning-severity=8 -w --colors ./src/
- phpunit --configuration ci/phpunit.xml

dev:

image: voduytuan/gitlab-php-ci
stage: deploy
script:
- ssh-add <(echo "$DEPLOYER_BETA_KEY")
- echo "Deploy to $DEPLOYMENT_FOLDER_NAME"
- rsync -avuz -e "ssh -p 22" --exclude-from="ci/deploy_exclude.txt" $CI_PROJECT_DIR/src/ $DEPLOYER_BETA_USER@$DEPLOYER_BETA_IP:/teamcrop/services/$DEPLOYMENT_FOLDER_NAME/src
only:
- dev

production:

image: voduytuan/gitlab-php-ci
stage: deploy
script:
- ssh-add <(echo "$DEPLOYER_PRODUCTION_KEY")
- echo "Deploy to $DEPLOYMENT_FOLDER_NAME"
- rsync -avuz -e "ssh -p 22" --exclude-from="ci/deploy_exclude.txt" $CI_PROJECT_DIR/src/ $DEPLOYER_PRODUCTION_USER@$DEPLOYER_PRODUCTION_IP:/teamcrop/services/$DEPLOYMENT_FOLDER_NAME/src
only:
- master
when: manual

Trong ví dụ trên, phần test bên mình làm 3 việc:
– Chạy linter để đảm bảo sourcecode không bị lỗi cú pháp (phplint)
– Kiểm tra source code có theo chuẩn PSR2 hay không.
– Chạy PHPUnit

Còn về phần deploy thì có cấu hình 2 task là deploy dev và production. Ở task dev thì auto và lấy code từ branch dev. Còn task production deploy từ branch master, tuy nhiên, có chế độ deploy manual, tức là nhấn thì mới deploy.

Về phần deploy source code thì sử dụng rsync để đẩy code từ repo sang server. Bạn sẽ thấy cú pháp giống nhau, chỉ khác là cấu hình đẩy đi đâu, với user nào và private key nào.

Do đặc thù của commandline nên sử dụng privatekey để đồng bộ code thông qua rsync. Do đó, trong project mình có cấu hình privatekey của user. Và bên server nhận (beta, production) mình đã đưa public key vào file authorized_keys. Bạn có thể tìm hiểu thêm về setup và generate cặp public/private key cho user deploy để hỗ trợ quá trình này tại link https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys–2. Hay ngắn gọn là thực hiện câu lệnh “ssh-keygen -t rsa -C “youremail@gmail.com” -b 4096″, nhập vài thông tin là bạn đã có public key (id_rsa.pub) để đem bỏ lên server (beta, production) và private key (id_rsa) đem bỏ vào setting biến môi trường.

Hy vọng bài viết này về CI/CD là gì sẽ giúp được cho quá trình setup CI/CD cho hệ thống của bạn, cũng như tăng tốc quá trình phát triển dự án. Nếu thấy bài viết hay và hữu ích, hãy chia sẻ cho các anh em khác để cùng trao đổi và giao lưu.

Đừng bỏ lỡ cơ hội tìm việc developer lên đến 3000 USD tại Topdev

TopDev cập nhật chỉnh sửa từ bài viết gốc của tác giả Võ Duy Tuấn