Tích hợp liên tục/Phân phối liên tục hoặc Deployment liên tục (CI/CD)

CI/CD là gì?

CI/CD, hay tích hợp liên tục/phân phối liên tục (hoặc triển khai liên tục), là một phương pháp phát triển phần mềm được hỗ trợ bởi tự động hóa, giúp tăng tốc chu kỳ phát hành thông qua các bản cập nhật thường xuyên và đáng tin cậy.

CI/CD là thuật ngữ chung bao gồm nhiều giai đoạn khác nhau trong quy trình DevOps . CI (tích hợp liên tục) là phương pháp tích hợp các thay đổi mã vào kho lưu trữ chung nhiều lần mỗi ngày.

CD có thể mang hai ý nghĩa khác nhau: phân phối liên tục (continuous delivery), tự động hóa việc chuẩn bị mã nguồn để phát hành, hoặc triển khai liên tục (continuous deployment), tự động đưa các bản dựng cuối cùng đến người dùng cuối. Dù bằng cách nào, việc kiểm thử thường xuyên của CI/CD giúp phát hiện lỗi và khiếm khuyết từ sớm, biến nó trở thành một phần cốt lõi của mọi quy trình DevOps .

Tích hợp liên tục (CI) là gì?

Tích hợp liên tục (CI) là một quy trình phát triển phần mềm tự động giúp tăng tốc độ phát triển đồng thời đảm bảo mã nguồn sạch và chất lượng cao trong mỗi lần commit. CI yêu cầu các nhà phát triển thường xuyên kiểm tra hoặc cam kết mã của họ vào một kho lưu trữ chung tập trung, thường là nhiều lần trong ngày.

CI là một phương pháp thực hành tốt nhất DevOps và là một giai đoạn trong vòng đời DevOps , nơi việc xác minh tự động giúp phát hiện các vấn đề từ sớm, trước khi chúng trở nên nghiêm trọng hơn.

Thực hành CI (Computational Integration) nghĩa là tích hợp những thay đổi nhỏ, thường xuyên thay vì những cập nhật lớn, không thường xuyên. Tự động hóa việc kiểm thử, hợp nhất và cập nhật mã giúp các nhóm có được mã sạch hơn, xác thực nhanh hơn, bản phát hành chất lượng cao hơn và quy trình phát triển dễ dàng mở rộng hơn.

Quá trình tích hợp liên tục hoạt động như thế nào?

CI là một quy trình liền mạch bắt đầu từ giai đoạn phát triển và kết thúc ở giai đoạn thử nghiệm. Mỗi lập trình viên sẽ đóng góp mã nguồn theo từng đợt nhỏ vào một kho lưu trữ chung, thường được gọi là kho lưu trữ chính, để toàn bộ nhóm có thể làm việc cộng tác và theo dõi các thay đổi. Kho lưu trữ đó nằm trong một hệ thống kiểm soát phiên bản như Unity VCS , Perforce hoặc Git .

Trên thực tế, nó hoạt động như sau:

1. Một lập trình viên kiểm tra mã nguồn vào kho lưu trữ dùng chung.

2. Mỗi lần commit vào nhánh chính (hoặc nhánh con) đều có thể kích hoạt quá trình biên dịch tự động.

3. Công cụ xây dựng tự động sẽ xác minh rằng bản sao mã nguồn hoặc nhánh được kiểm tra không có lỗi.

4. Sau khi quá trình biên dịch thành công, môi trường kiểm thử tự động sẽ xác thực bản phát hành.

Vì chu kỳ xây dựng và kiểm thử diễn ra nhanh chóng, các nhà phát triển nhận được phản hồi đủ nhanh để sửa các lỗi còn lại ngay lập tức, giúp duy trì chất lượng mã nguồn mà không làm chậm tiến độ của nhóm.

Cụ thể trong Unity , Unity Build Automation tự động chạy các bản dựng và kiểm thử này trên đám mây, mà bạn không cần phải duy trì máy chủ xây dựng hoặc cơ sở hạ tầng dành riêng cho nền tảng của mình.

Các quy tắc và nguyên tắc của CI

• Duy trì một kho lưu trữ mã nguồn tập trung: tránh lưu trữ mã nguồn từ các nhóm khác nhau trong các kho lưu trữ hoặc hệ thống riêng biệt.
• Hãy thường xuyên đưa mã nguồn vào kho lưu trữ chính: mã nguồn càng để lâu không được đưa vào kho lưu trữ, thì càng dễ xảy ra xung đột với kho lưu trữ trung tâm.
• Duy trì máy chủ biên dịch và máy chủ kiểm thử riêng biệt: các máy chủ biên dịch chuyên dụng giúp tăng tốc quá trình và tránh làm chậm tiến độ của các nhà phát triển khác.
• Tự động hóa quá trình biên dịch và kiểm thử: mỗi lần commit mã nguồn nên được biên dịch và kiểm thử tự động, chứ không phải thủ công.
• Sử dụng môi trường thử nghiệm giống với môi trường sản xuất: môi trường thử nghiệm nên mô phỏng môi trường sản xuất để đảm bảo sự nhất quán trong suốt quá trình triển khai.
• Cấp quyền truy cập sớm cho bộ phận QA vào các bản dựng: việc truy cập sớm cho phép QA phát hiện các lỗi liên quan đến yêu cầu sản xuất trước khi chúng đòi hỏi phải sửa chữa tốn kém.

Phân phối liên tục và triển khai liên tục

Phân phối liên tục là gì?

Phân phối liên tục là phương pháp tự động chuẩn bị mọi thay đổi mã đã được xác thực để phát hành, mà không cần tự động phát hành chúng.

Quy trình phân phối liên tục hoạt động như thế nào?

Sau khi mã vượt qua CI (Continuous Integration), quá trình phân phối liên tục sẽ chuyển mã đó vào môi trường thử nghiệm, một môi trường giống như môi trường sản xuất, nơi các bài kiểm tra đơn vị, tích hợp và hệ thống tự động được chạy, và bộ phận QA (Quality Attached Area) sẽ xem xét bản dựng. Mục tiêu là duy trì trạng thái "sẵn sàng phát hành" của bản dựng.

Triển khai liên tục là gì?

Triển khai liên tục tiến thêm một bước so với việc chỉ phân phối, tự động phát hành mọi thay đổi đã được xác thực trực tiếp lên môi trường sản xuất mà không cần bất kỳ bước phê duyệt thủ công nào.

Quá trình triển khai liên tục hoạt động như thế nào?

Mọi thay đổi vượt qua quá trình kiểm thử tự động đều được chuyển thẳng vào môi trường sản xuất thông qua cùng một quy trình, không cần bất kỳ bước kiểm soát thủ công nào ở giữa.

Có hai kỹ thuật giúp việc này an toàn hơn thay vì liều lĩnh: phát hành ẩn (dark release) triển khai mã mới lên môi trường sản xuất mà chưa cho bất kỳ người dùng nào sử dụng, và công tắc tính năng (feature toggle hoặc feature flag) cho phép nhóm bật hoặc tắt một tính năng cụ thể cho các phân khúc người dùng được chọn, độc lập với quá trình triển khai. Cả hai cùng nhau cho phép nhóm liên tục phát hành sản phẩm trong khi vẫn kiểm soát được ai thực sự nhìn thấy tính năng cụ thể và vào thời điểm nào.

Phân phối liên tục so với triển khai liên tục

Cả hai phương pháp đều đẩy mã đã được kiểm duyệt vào môi trường sản xuất một cách nhanh chóng và an toàn nhất có thể. Chúng khác nhau ở chỗ quyết định của con người nằm ở đâu:

CI/CD, or continuous integration/continuous delivery or deployment, is a software development practice enabled by automation. Frequent, reliable updates accelerate release cycles via continuous code delivery.

CI/CD explained

CI/CD is an umbrella term covering several DevOps phases. CI (continuous integration) is the practice of integrating code changes into a repo several times a day. CD has two meanings: Continuous delivery automates code integrations, while continuous deployment auto-releases final builds to end-users. CI/CD’s frequent testing reduces code errors and defects, making it crucial to every DevOps workflow.

What is continuous integration? (CI)

Continuous integration (CI) is an automated software development process that increases the speed of development while ensuring clean, quality code with every deployment. Continuous integration requires developers to frequently checkin/commit their units of code to a central shared repository many times a day.

CI is a DevOps best practice and stage in the DevOps lifecycle when developers checkin code to their shared code repository. An automated build tool verifies the checkin or branch to ensure there are no errors and that it’s ready to go into production. The main benefit here is that problems are usually caught early before they can snowball into bigger issues.

Practicing CI means integrating small subsets of changes in a shorter period of time, rather than substantial updates that take longer and less often. Automating workflows for testing, merging, and checking in changes to a shared repo means teams can deliver cleaner code at a faster rate. Cleaner code means faster validation, higher-quality releases, and a more efficient development pipeline that’s easier to scale.

How does continuous integration work?

Continuous integration is a simple and seamless process that begins in the development phase and ends in the testing environment. Continuous integration allows all developers to work collaboratively and keep track of their code. Every developer “commits” their code in small increments to a shared code repository, also known as the mainline repository. The code repository is maintained in a version control system like Unity VCS, Perforce, or Git. Every commit made to the repository’s main branch (or child branches if you choose) can trigger an automated build process linked to a build management system that takes the code and creates a build. Once the code is merged into the build system, the developers gain full access to their code builds. From here, they can see if their code is compiled correctly or if there is an error that they might need to fix. Build systems can be configured to support various testing frameworks.

Once the code is approved and the build cycle is successful, an automated testing environment is triggered to validate the quality of the build and subsequent release. Because the test and build process is extremely quick, the results of the code commits can be communicated quickly, empowering developers to fix any remaining errors in a timely manner. This whole process ensures that the codebase stays healthy and everyone can continue to work efficiently.

Rules and principles of CI

- Maintain one central code repository

Temporarily storing code from different developers in various teams into separate repositories or separate systems should be kept to a minimum.

- Commit/check in code to the mainline repository frequently

The longer a developer holds onto code without building or testing it, the more likely it is to be inconsistent with what’s stored in the central repository.

- Maintain separate build and test servers

Teams should maintain dedicated machines for build purposes only. This speeds up the build process and minimizes the impact on other developers' workflows.

- Builds and tests must be automated

Every piece of code committed to the central source code repository should be built and tested automatically with continuous integration tools.

- Use production-like testing environments

Testing environments should simulate the eventual production environment. This ensures the usefulness of the testing environment and keeps expectations consistent throughout deployment.

- Quality assurance teams should have access to builds

When QA has access to builds, any failure to meet production requirements can be detected early, reducing the risk of having to rework code builds later.

Continuous delivery vs continuous deployment

Continuous deployment and continuous delivery are practices used to take new code and push it into production as quickly and efficiently as possible. Continuous delivery follows CI – you can think of it as a checkpoint phase in the development pipeline before the final product is released to customers. Once code changes have been validated, they’re automatically delivered to the central repository.

Continuous deployment follows CI in the DevOps lifecycle, but the two processes are linked. CI integrates code into the build with automation; CD completes that process. DevOps automations evaluate the quality of the updates. Once they’ve been found to be clear of errors, they’re automatically deployed to production.

What is continuous delivery?

Continuous delivery refers to the building, testing, and delivery of code changes to software. In this process, code passes through various testing environments, such as automated unit testing, integration testing, and system testing, before being pushed to production. Continuous delivery happens in production-like staging environments where QAs review the code, fix bugs, and run automated tests to ensure that builds are always deployable and release-ready.

With continuous delivery, the goal is to keep changesets small enough that no updates to the main build will compromise the final product’s “production-ready” status. The final product may contain minor errors, but nothing substantial enough to compromise the user experience.

Practicing continuous delivery means developers can spend less time testing in-house, as the practice ensures that only stable code makes it to the delivery phase in the first place. It makes bug detection a simpler process, accelerating time to resolution.

What is continuous deployment?

Continuous deployment aims to continuously deploy code changes into production from the central repository once the build is stable. The operations team deploys the compiled code and installs the software in different environments (dev/test, staging, and production). Each change passes through an automated pipeline that pushes a working version of the application into production. Deployment can take different forms. A dark release is a deployment that’s hidden from users, while feature toggles or switches can be used to deploy specific subsets of a changeset to a group of users for testing and feedback.

Continuous deployment has numerous benefits for developers and customers. Devs using continuous deployment solutions no longer need to worry about manual build deployment and can focus on more skill-based tasks. Automation shortens feedback loops, which means products can be updated more quickly based on customer input. With continuous deployment, code is run and maintained in a simulated environment that ensures quality and enables real-time monitoring of the product. The main goal of continuous deployment is to release newer versions of the code consistently and automatically deploy those changes to end users.

How are CI/CD and DevOps related?

All software development begins with preproduction (the planning phase), followed by production (coding and asset creation). DevOps is a culture and a process aimed at making these processes more efficient. CI/CD is a phase within the DevOps lifecycle mandating the implementation of small but steady streams of code updates over time to ensure continuous, iterative improvement of the end product.

Regular, frequent software releases can be achieved by using specific tools and products to enable the integration, delivery, and deployment of code changes – this is called a CI/CD pipeline.

A CI/CD pipeline is a specific set of phases tied to tools and automation that enable the DevOps lifecycle to happen. While CI/CD is an integral part of a DevOps culture, DevOps encompasses much more across the software development life cycle – from collaboration to team structure, to observability, version control, and more.

The implementation of DevOps varies greatly across organizations, but at its core, DevOps cannot be accomplished without CI/CD. A CI/CD pipeline is intrinsically tied to a DevOps culture and its process of small, frequent releases.

Benefits of CI/CD

- Rapid iteration

Adopting CI/CD practices as part of your DevOps lifecycle speeds up development by automating the manual work of validating and deploying changes to the code base.

- Cleaner code

Checking in numerous small changes throughout the day substantially reduces the risk of build-breaking errors being introduced into your source code.

- Faster bug fixes

Merging smaller changesets more often with CI/CD makes it easier to identify code errors and fix them before they become a bigger problem.

- Shorter feedback loops

CI/CD helps shorten feedback loops – a core DevOps principle – because smaller, iterative changes are easier to integrate, test, and deploy.

- Better collaboration

CI/CD brings clarity to work by defining processes and timelines for code commits and build launches. With clearer goals, teams can move with greater agility.

- Happier customers

Because builds are always release-ready with CI/CD, customers experience fewer service interruptions, and their feedback can be integrated much more quickly.

Is agile the same as CI/CD?

An agile workflow and CI/CD are related, however, they are not the same! They describe completely different aspects of the software development pipeline. Agile development, refers to the process or methodologies for managing workflows, meeting cadences, and team organization in software development. An agile methodology embraces change while accelerating delivery by listening and responding to customer needs and involving them in each stage of the development process.

CI/CD relies on automation to remove the human elements that create bottlenecks in releasing and improving the software. In both CI and CD testing is automated throughout the pipeline and is done frequently to minimize the costs and time it takes to remediate defects.

How often should you be deploying to production with continuous deployment?

With CI/CD, releases should always be frequent to avoid future problems and assure your software is always in a releasable state - typically deploying multiple times a day. A common assumption with CI/CD teams should be implementing "constant" releases, however, this is not always the case. Your release cycle can vary widely depending on your product, your builds, and other factors you might want to take into consideration such as:

1. Is it a critical or minor fix?

2. Are you tracking regression counts from build to build?

3. Is there a QA team put in place?

4. Does the code base have unit tests?

5. Are there any code duplications?

These are just a few examples of aspects to consider when thinking about a release strategy and pipeline, but it differs drastically from team to team. Different products require different approaches.

Is continuous deployment worth it?

There is no one size fits all answer to this question. Before investing in continuous deployment a business must first assess what the biggest risks are of their product and then determine the tradeoffs in how you want to deploy software.

The success of your product is dependent on being able to quickly iterate, get feedback from your customers, and continue to make changes. Continuous deployment will be highly impactful and profitable if you are prioritizing shortening feedback loops and building a highly responsive business.

However, if your business does not have many customers then the benefits of implementing increments of deployment will add less value and more costs. The staging environment you choose to deploy ultimately depends on your business needs, workflow, and budget.

CI/CD và DevOps có mối liên hệ như thế nào?

DevOps là một văn hóa và quy trình nhằm mục đích làm cho quá trình phát triển phần mềm hiệu quả hơn, từ khâu lập kế hoạch đến khâu sản xuất. CI/CD là một giai đoạn trong vòng đời DevOps , yêu cầu các luồng cập nhật mã nhỏ, đều đặn để cải tiến liên tục và lặp đi lặp lại.

Hệ thống CI/CD là tập hợp các công cụ và quy trình tự động hóa cụ thể giúp cho việc phát hành sản phẩm thường xuyên và định kỳ trở nên khả thi. Mặc dù CI/CD là yếu tố cốt lõi của văn hóa DevOps , nhưng DevOps bao gồm nhiều hơn thế nữa, như sự hợp tác, cấu trúc nhóm, khả năng quan sát, kiểm soát phiên bản, và hơn thế nữa.

triển khai DevOps rất khác nhau giữa các tổ chức, nhưng CI/CD được coi là một trong những thực tiễn cốt lõi, nền tảng của nó. Nếu thiếu nó, hầu hết các mục tiêu thực tế của DevOps(phát hành nhanh chóng, đáng tin cậy và thường xuyên) sẽ trở nên rất khó đạt được.

Lợi ích của việc sử dụng CI/CD

• Lặp lại nhanh chóng: tự động hóa các công việc thủ công như xác thực và triển khai các thay đổi mã, giúp tăng tốc quá trình phát triển.
• Mã nguồn sạch hơn: việc thường xuyên kiểm tra và cập nhật nhỏ giúp giảm đáng kể nguy cơ xảy ra lỗi nghiêm trọng làm hỏng bản dựng.
• Khắc phục lỗi nhanh hơn: các bản cập nhật nhỏ hơn, thường xuyên hơn giúp dễ dàng xác định và sửa lỗi sớm hơn.
• Chu kỳ phản hồi ngắn hơn : một nguyên tắc cốt lõi DevOps , các thay đổi lặp đi lặp lại nhỏ hơn sẽ dễ tích hợp, kiểm thử và triển khai hơn.
• Hợp tác hiệu quả hơn: quy trình và thời gian biểu rõ ràng cho việc cam kết và phát hành giúp các nhóm hoạt động linh hoạt hơn.

Những thách thức khi sử dụng CI/CD

• Điều này đòi hỏi sự trưởng thành thực sự trong việc kiểm thử: triển khai liên tục phụ thuộc cụ thể vào một bộ kiểm thử tự động toàn diện và hoàn thiện; nếu không có nó, việc đưa sản phẩm trực tiếp lên môi trường sản xuất sẽ trở nên rủi ro hơn là an toàn.
• Chi phí thiết lập và trang bị ban đầu: việc xây dựng và duy trì một hệ thống xử lý dữ liệu đáng tin cậy đòi hỏi đầu tư thực sự trước khi lợi ích được thể hiện rõ ràng.
• Điều chỉnh văn hóa: các nhóm vốn quen với việc phát hành sản phẩm không thường xuyên nhưng với số lượng lớn cần thay đổi thói quen về tần suất commit, tốc độ xem xét mã và trách nhiệm đối với những gì được phát hành.