ci cd là gì

CI/CD là gì? – Cũng rộng lớn một mon Tính từ lúc nội dung bài viết sớm nhất, ni mới mẻ sở hữu thời hạn ngồi viết lách lách tiếp. Dạo mới đây thông thường release những dự án công trình outsource nên cũng hoặc thực hiện documentation cũng như  phanh những dự án công trình mới mẻ cho nên việc setup CI/CD thông thường xuyên rộng lớn và tay chân rộng lớn. Thấy những kiến thức và kỹ năng này hoặc nên thời điểm hôm nay bản thân tiếp tục share quý khách tiến độ CI/CD theo người vận dụng mang lại “đại dự án” Teamcrop cũng như các dự án công trình outsourcing nhưng mà Moout tiến hành.

Bạn đang xem: ci cd là gì

CI/CD là gì?

Bạn tiếp tục thấy có tương đối nhiều khái niệm kể từ nhì lúa cho tới hàn lâm mang lại khái niệm CI/CD. Mình tiếp tục sử dụng cơ hội khái niệm của tớ nhằm quý khách dễ nắm bắt CI/CD là gì Theo phong cách thường thì nhất. CI/CD là 1 trong những cặp đôi việc làm, bao hàm CI (Continuous Integration) và CD (Continuous Delivery), ý rằng là quy trình tích phù hợp (integration) thông thường xuyên, nhanh gọn rộng lớn khi code giống như thông thường xuyên update phiên phiên bản mới mẻ (delivery).

Tại sao cần quan hoài cho tới CI/CD?

Ngày ni, với Xu thế agile/lean kéo theo việc trở nên tân tiến chức năng là vấn đề thông thường, cần thiết cần là trạng thái, ý lộn, cần thiết là cần thời gian nhanh. Nếu một chức năng nhưng mà mất mặt 2, 3 mon mới mẻ release thì kéo theo nhiều hệ quả như thực hiện ko tương thích nhu yếu quý khách hàng, hoặc phe đối lập vẫn tung ra trước tê liệt, mất mặt chuồn dòng sản phẩm ưu thế đứng vị trí số 1. Do tê liệt, việc thực hiện rời khỏi một thành phầm, chức năng yên cầu thần tốc là ưu tiên số một lúc này.

Bên cạnh tê liệt, nhằm nhanh gọn tung ra một chức năng, phiên phiên bản mới mẻ nếu như Theo phong cách cổ xưa tiếp tục mất không ít thời hạn vì chưng việc làm tay chân không hề ít và từng lượt release cũng kêu gọi một cơ số người rất to lớn nhằm update một thay cho thay đổi cho dù là nhỏ nhất. Bởi vậy, Xu thế CI/CD canh ty hỗ trợ những framework, workflow canh ty tiết kiệm ngân sách thời hạn, nguồn lực có sẵn của quy trình release (delivery).

Quy trình CI/CD tham ô khảo

Có thật nhiều tiến độ, khí cụ không giống nhau nhằm phần mềm CI/CD vô dự án công trình. Nội dung của nội dung bài viết này dựa vào tay nghề cho những dự án công trình của tớ thực hiện giống như đặc trưng là những khối hệ thống trang web, và viết lách vì chưng PHP (PHP hoặc Python hoặc abc…không quá cần thiết vô văn cảnh share về CI/CD).

Dưới đó là quá trình thường thì của quy trình release chức năng vô một dự án công trình nằm trong khối hệ thống Teamcrop.
– Bước 1: [Manual] Khởi tạo nên repository và sở hữu branch mặc định là master và dev. Cài bịa đặt bên trên Gitlab 9.
– Bước 2: [Manual] Trừ owner rời khỏi, thì những coder tiếp tục push code chức năng lên branch dev
– Bước 3: [Auto] Hệ thống tự động hóa tiến hành test source code, nếu như PASS thì tiếp tục deploy tự động hóa (rsync) code lên server beta.
– Bước 4: [Manual] Tester/QA tiếp tục vô khối hệ thống beta nhằm thực hiện UAT (User Acceptance Testing) và confirm là tất cả OK.
– Bước 5: [Manual] Coder hoặc owner tiếp tục vô tạo nên Merge Request, và merge kể từ branch dev quý phái branch master.
– Bước 6: [Manual] Owner tiếp tục accept merge request.
– Bước 7: [Auto] Hệ thống tiếp tục tự động hóa tiến hành test source code, nếu như PASS tiếp tục enable chức năng được chấp nhận deploy lên production server.
– Bước 8: [Manual] Owner review là merge request OK, test OK. Tiến hành nhấn nút nhằm deploy những thay cho thay đổi lên môi trường thiên nhiên production.
– Bước 9: [Manual] Tester/QA tiếp tục vô khối hệ thống production nhằm thực hiện UAT và confirm tất cả OK. Nếu ko OK, Owner hoàn toàn có thể nhấn nút Deploy phiên phiên bản master trước tê liệt nhằm rollback khối hệ thống về tình trạng stable trước tê liệt.
– Bước 10: [Manual] Thắp nhang và kỳ vọng quý khách hàng ko nguyền rủa hoặc gmail complain.

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

Trong phạm vi nội dung bài viết này, bản thân tiếp tục chỉ dẫn quý khách thiết lập Gitlab 9 nhằm quản lý và vận hành source code, và bên trên technology Git. Đòi căn vặn của toàn bộ setup này là bên trên server vẫn chuyên chở Docker, nếu như chúng ta chưa tồn tại docker bên trên server thì hoàn toàn có thể tìm hiểu thêm những nội dung bài viết về docker bên trên bloghoctap giống như lần tìm kiếm thêm thắt trên top mạng tìm kiếm google.

CI/CD là gì

Đây là thắc mắc hoặc, cũng chính vì trước tê liệt theo người dùng Gitlab 8, tuy vậy, vì thế những giới hạn về UI/UX giống như ko tích phù hợp ngon miệng vụ CI/CD nên những lúc phiên bản 9 tung ra, tôi đã test dùng và thấy phiên bản 9 tương thích rộng lớn mang lại workflow nên đưa ra quyết định vệ sinh quý phái Gitlab 9.

CI/CD là gì

Bạn chạy câu mệnh lệnh sau sẽ tạo một container chứa chấp Gitlab 9.

docker run rẩy --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 sử dụng docker tiếp tục hiểu được ý nghĩa câu mệnh lệnh bên trên. Đơn giản là bản thân dùng image gitlab/gitlab-ce:9.0.3-ce.0. Có mount rời khỏi 3 folder phía bên ngoài máy ở thục mục /gitlab9 nhằm lỡ sở hữu chuyện gì chỉ việc stop, remove container, khi chạy docker run rẩy lại thì vẫn tồn tại tài liệu, source code. Câu mệnh lệnh bên trên sở hữu map 2 port là 8080 và 2222 ứng cho tới 2 port 80 và 22 vô container. Mình mapping port vậy cũng chính vì bên trên server dev này còn có thật nhiều service không giống và đã sở hữu port 80 và 22 (ssh ^^!).

Sau khi chúng ta start container thì hoàn toàn có thể truy vấn vô kể từ ip hoặc tên miền (mà các bạn vẫn trỏ DNS), ví dụ: http://code.teamcrop.com:8080 là hoàn toàn có thể vô gitlab 9, thông tin tài khoản khoác toan là `root`.

Không sở hữu gì cao siêu ở thiết lập này, hoàn toàn có thể tìm hiểu thêm thêm thắt ở trang chủ của Gitlab.com nhé.

Quản lý sourcecode vì chưng Gitlab

Về phần này thì bản thân ko cần thiết rằng dông dài, giống như một khối hệ thống git thường thì (như github..), chúng ta cũng có thể lần hiểu thêm thắt về git và Gitlab nhằm team hoàn toàn có thể nằm trong thao tác và quản lý và vận hành sourcecode bên trên Gitlab.

Thông thông thường, những khối hệ thống quản lý và vận hành sourcecode ko tất nhiên cách thức CI/CD. Nếu mình muốn thực hiện thì buộc cần links cho tới repository, phân quyền đầy đủ loại nhằm khối hệ thống tê liệt hoàn toàn có thể lấy source code kể từ respository. Trước trên đây theo người dùng Jenkins mang lại việc này. Tuy nhiên, kể từ khi Gitlab tung ra chức năng Gitlab CI, tất nhiên sự đủng đỉnh, phiền hà và rề rề của Jenkins thì bản thân đưa ra quyết định chia ly với Jenkins và cho tới với Gitlab CI luôn luôn, và trái khoáy là 1 trong những cặp đôi tuyệt vời nhất. Code nhằm ở Gitlab, rồi vô tê liệt sở hữu mang lại thiết lập CI/CD nhằm test và deploy code tự động hóa.

Cũng như một trong những các bạn mới mẻ lần thứ nhất xúc tiếp với Gitlab CI, tôi đã từng thấy nó khó khăn hiểu và cao siêu vì thế setup tùm lum. Rồi setup đoạn lại ko biết nó chạy thế này, cách thức deploy source code rời khỏi sao. Tuy nhiên, sau đó 1 vài ba “va chạm” ăm ắp những giọt mồ hôi và nước đôi mắt thì cũng cầm và nắm chắc cơ hội Gitlab CI vận hành, và ni share mang lại quý khách nhằm áp dụng mang lại workflow của tớ.

Để sử dụng được Gitlab CI thì các bạn cần phải có 2 bộ phận sau: tệp tin `.gitlab-ci.yml` nằm ở vị trí folder gốc của dự án công trình và Gitlab Runner.

Tham khảo thêm thắt việc thực hiện xây dựng GIT lương lậu cao bên trên Topdev

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

Mặc toan Gitlab không tồn tại cách thức này về CI mang lại dự án công trình của công ty, chỉ lúc nào dự án công trình của công ty sở hữu tệp tin .gitlab-ci.yml nằm ở vị trí folder gốc thì Gitlab mới mẻ nhận dạng được dự án công trình của mình muốn vận dụng Gitlab CI. File này còn có format và cần thiết hợp thức thì mới có thể hoàn toàn có thể hoạt động và sinh hoạt được, ko thì khi chúng ta push code lên thì Gitlab tiếp tục báo lỗi tệp tin format nội dung của tệp tin thông số kỹ thuật ko hợp thức. Tham khảo cú pháp của thông số kỹ thuật này tại https://docs.gitlab.com/ce/ci/yaml/

Trong tệp tin này còn có gì? File này còn có một trong những section nhằm khai báo như trước đó khi chạy test thì làm những gì, khi test thì tiến hành mệnh lệnh gì (vd chạy linter kiểm tra cú pháp, chạy PHPUnit test…), test đoạn rồi thì tiến hành deploy chuồn đâu (beta, production..) với câu mệnh lệnh gì (vd: rsync..). Tùy đặc trưng ngôn từ xây dựng, cơ hội gói gọn của dự án công trình nhưng mà sẽ sở hữu những mệnh lệnh ứng tiến hành.

Tới trên đây những các bạn sẽ sở hữu thắc mắc là vậy đồ vật gi tiếp tục chạy, thực đua những câu mệnh lệnh, hướng dẫn vô tệp tin config trên? Hay là Gitlab Server tiếp tục chạy. Nếu là Gitlab server chạy thì nếu như dự án công trình bản thân tiến hành những mệnh lệnh không tồn tại thì sao, vì thế gitlab server thì cũng chỉ chứa chấp gitlab và những program mang lại nó chứ đâu thể chuyên chở sẵn những program? Dường như, từng lượt chạy thì những vấn đề tương quan cho tới tệp tin tạm thời sở hữu bị reset lại hoặc không?

Nếu các bạn tiếp cận trên đây thì các bạn vẫn đoán được là thực rời khỏi “cái thứ” thực đua những hướng dẫn, câu mệnh lệnh vô tệp tin .gitlab-ci.yml ko cần là Gitlab Server (là dòng sản phẩm container đang hoạt động gitlab 9 bản thân start ở trên), nhưng mà tê liệt đó là Gitlab Runner. Wow! Welcome to tát matrix!

Gitlab Runner là gì?

Gitlab Runner là bộ phận khôn cùng cần thiết vô workflow Gitlab CI. Nếu không tồn tại Runner thì tiếp tục không tồn tại mệnh lệnh test, deploy này được thực đua. Runner có tương đối nhiều loại, phân biệt nhờ vào dòng sản phẩm gọi là executor. Khi khởi tạo nên runner, các bạn sẽ cần lựa chọn nó là loại executor này, và nó sẽ bị đưa ra quyết định môi trường thiên nhiên thực đua những câu mệnh lệnh vô tệp tin config phía trên. Quý khách hàng hoàn toàn có thể tìm hiểu thêm link https://docs.gitlab.com/runner/executors/ để biết sự không giống nhau của những executor giống như cơ hội thiết lập, thông số kỹ thuật bọn chúng.

Do đặc trưng khối hệ thống vẫn sở hữu docker, nên mặt mũi tôi chỉ dùng executor loại Docker nhưng mà thôi. Và bên dưới là câu mệnh lệnh docker nhằm start một Gitlab Runner.

Xem thêm: booklet là gì

docker run rẩy -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

Ở trên đây các bạn sẽ thấy container này mount folder config ra bên ngoài, cũng chính vì mình thích những thông số kỹ thuật của runner vẫn tồn tại khi stop/remove container. Chỉ cần thiết start lại là giữ vị thông số kỹ thuật. Trong khi, nó còn mount docker.sock vô phía bên trong container, đó là phương pháp để executor loại docker hoàn toàn có thể tận dụng tối đa mệnh lệnh docker phía bên ngoài host nhằm tiến hành mệnh lệnh tạo nên container phụ vô quy trình runner chạy (test, deploy).

Start container lên đơn thuần những bước đầu tiên, cũng chính vì cảnh báo là cho tới thời đặc điểm này, Runner này không tồn tại tương quan gì cho tới Gitlab server của tất cả chúng ta. Cần một bước liên kết lại (gọi là register) runner này vô vào Gitlab server nhằm bản thân hoàn toàn có thể được chấp nhận những dự án công trình sử dụng runner vô quy trình CI/CD.

Xem liên kết này https://docs.gitlab.com/runner/register/index.html để biết phương pháp register runner này vô Gitlab Server.

Dưới đó là hình hình ảnh tìm hiểu thêm chúng ta cũng có thể sử dụng vô quy trình register 1 runner. Có 2 vấn đề cần thiết là 1 trong những dòng sản phẩm URL và một random token. Và dòng sản phẩm URL quan trọng đặc biệt cảnh báo là thông thường thêm thắt /ci sau tên miền. Ví dụ ở tình huống của tớ setup là http://code.teamcrop.com/ci

Sau khi Runner đang được gán vô Gitlab Server, chúng ta cũng có thể enable runner này cho 1 hoặc nhiều dự án công trình vô Gitlab. Hình bên dưới minh họa việc gán Runner vô dự án công trình vô phần thiết lập Pipeline của Gitlab 9.

Đến trên đây đa số vẫn thông số kỹ thuật đoạn. Dự án vẫn kích hoạt 1 runner, và dự án công trình vẫn sở hữu tệp tin .gitlab-ci.yml. Từ lúc này, từng lượt code được trả lên thì runner tiếp tục thực đua test giống như deploy dựa vào những câu mệnh lệnh được khai báo vô tệp tin thông số kỹ thuật.

Khai báo biến đổi nhằm sử dụng trong số câu lệnh

Trong một trong những tình huống, chúng ta cũng có thể khai báo biến đổi nhằm hoàn toàn có thể sử dụng trong số mệnh lệnh của runner. Có 3 điểm hoàn toàn có thể thông số kỹ thuật biến:

1. Cấu hình ngay lập tức phía bên trong tệp tin .gitlab-ci.yml
2. Cấu hình vô dự án công trình. Vào Settings // CI/CD Pipelines, phần Secret variables (xem hình)

3. Cấu hình phía bên trong tệp tin config của runner.

Bạn sở hữu ghi nhớ khi bản thân khởi tạo nên runner, sở hữu hướng đẫn một folder chứa chấp config ko, trên đây đó là điểm thông số kỹ thuật cộng đồng mang lại runner này. Trong folder này sẽ sở hữu tệp tin là config.toml. Và chúng ta cũng có thể gán biến đổi vô thông số kỹ thuật của từng runner. Cấu hình ở trên đây sở hữu một ưu thế là cứ runner này chạy tiếp tục cảm nhận được biến đổi vẫn thông số kỹ thuật. Quý khách hàng không cần thiết phải thông số kỹ thuật rất nhiều lần ở từng dự án công trình.

Ví dụ về một tệp tin .gitlab-ci.yml

Bên bên dưới là tệp tin thông số kỹ thuật của một dự án công trình vô khối hệ thống Microservices nằm trong Teamcrop:

before_script:

- export "PATH=$PATH:/vendor/bin" # Install ssh-agent if not already installed, it is required by Docker. # (change apt-get to tát 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 tát 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 tát $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 tát $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ụ bên trên, phần test theo người thực hiện 3 việc:
– Chạy linter nhằm đáp ứng sourcecode không xẩy ra lỗi cú pháp (phplint)
– Kiểm tra source code sở hữu theo gót chuẩn chỉnh PSR2 hay là không.
– Chạy PHPUnit

Còn về phần deploy thì sở hữu thông số kỹ thuật 2 task là deploy dev và production. Tại task dev thì tự động và lấy code kể từ branch dev. Còn task production deploy kể từ branch master, tuy vậy, sở hữu chính sách deploy manual, tức là nhấn thì mới có thể deploy.

Về phần deploy source code thì dùng rsync nhằm đẩy code kể từ repo quý phái server. Quý khách hàng tiếp tục thấy cú pháp kiểu như nhau, chỉ không giống là thông số kỹ thuật đẩy chuồn đâu, với user này và private key này.

Do đặc trưng của commandline nên dùng privatekey nhằm nhất quán code trải qua rsync. Do tê liệt, vô project bản thân sở hữu thông số kỹ thuật privatekey của user. Và mặt mũi server nhận (beta, production) tôi đã trả public key vô tệp tin authorized_keys. Quý khách hàng hoàn toàn có thể lần hiểu thêm thắt về setup và generate cặp public/private key mang lại user deploy nhằm tương hỗ quy trình này bên trên link https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys–2. Hay cụt gọn gàng là tiến hành câu mệnh lệnh “ssh-keygen -t rsa -C “[email protected]” -b 4096″, nhập vài ba vấn đề là bạn đã sở hữu public key (id_rsa.pub) nhằm đem đặt lên server (beta, production) và private key (id_rsa) đem bỏ vô setting biến đổi môi trường thiên nhiên.

—-
Dựa bên trên những tay nghề CI/CD mang lại khối hệ thống Teamcrop.com theo gót quy mô microservice với trên 40 repository rộng lớn nhỏ, kỳ vọng nội dung bài viết này về CI/CD là gì sẽ hỗ trợ được mang lại quy trình setup CI/CD mang lại khối hệ thống của công ty, giống như tăng cường quy trình trở nên tân tiến dự án công trình. Nếu thấy nội dung bài viết hoặc và hữu ích, hãy share cho những bạn bè không giống nhằm nằm trong trao thay đổi và chia sẻ.

Đừng bỏ qua thời cơ lần việc developer lên tới mức 3000 USD bên trên Topdev

TopDev via Võ Duy Tuấn

Xem thêm: ibuprofen là thuốc gì