The DevOps movement has taken the software development industry by storm. With the DevOps approach, organizations can more quickly and efficiently respond to market opportunities by accelerating software deployment, streamlining operations and increasing collaboration between software developers and operations people. With that in mind, continuous integration (CI) and continuous delivery (CD) are regarded as the two key components of DevOps practice. These practices have existed for some time but have become even more critical now that we live in a world where software is really eating the world.
From a broad perspective, these two (CI/CD) are crucial to deploying software to production, but there goes more between these two long processes. Today, we will see some notable steps in the CI/CD pipeline and try to understand them properly.
What is Continuous Integration?
CI is the process of automating the integration of code changes into a shared codebase, focusing on finding and fixing potential issues early on in the development phase. It can be achieved by integrating the code base automatically after each commit and triggering a set of tests. The outcome of the process is either a green build if the code is error-free or a red status if there’s an issue with the code, together with information on what went wrong. Integration usually refers to the process of combining parts of code (e.g. functions, modules) that have been created separately by different people/teams and are not yet fully integrated. This happens when a team is finished with a piece of work and moves it to the next stage of the process so that other teams can work with it.
What is Continuous Delivery?
CD is the process of automating the movement of code from a shared codebase through a testing environment to get to a production-like environment and, finally, to a live environment. The goal is to reduce the risk of human errors and increase the release process's predictability. It’s important to mention that CD is not just the final stage of the CI process. Instead, it’s a combination of all three major stages of the pipeline.
Typical Stages of the CI/CD Pipeline
Source:
The source stage is where the organization maintains its source code in a centralized repository system. You can call it a version control system like GitHub, Bitbucket, GitLab or AWS CodeCommit. This stage and tools are essential to help developers coordinate and track who is doing what. This stage also acts as a collaboration booster as different development teams check in their code, do code reviews, and approve the code for further steps. Automation of version control can be done via IDEs like visual code.
- Code Quality Analysis with Static Analysis Tools Early on in the process, automated tools (e.g. SonarQube, VCS analysis tools) can check if the code follows a specific set of rules (e.g. if code is written in a certain language, if it’s well-documented, if it’s covered by tests). These rules are usually defined by a team or a workflow manager and help identify potential issues in the code early on. This is important because fixing them later would mean changing existing code, which may be problematic. Thus, using static code analysis tools can save you a lot of time and trouble in the future.
Test and Build:
Test and Build is the stage after developers push their code to a version control system. When a developer pushes the code to the organisation's version control system, it triggers the continuous integration system/tool (something like Drone CI). Then the code goes through tests prescribed by the developer. Then finally, the compilation and building steps get completed.
Unit Testing with Automated Tests: Automated tests are crucial because they allow you to identify issues with the application’s functionality as soon as they occur. They are usually written as part of automated build processes and aim to check if the application is working correctly. Depending on the type of software you build and the programming language you use, you can choose from a wide array of automated testing tools.
Integration Testing and Manual QA: with Humans Integration testing ensures that components or services work well together. It is performed by a human tester responsible for testing the functionality expected to be delivered by a certain feature. Integration testing is crucial because it allows a tester to identify issues with different components of the system that were tested separately by development teams. This is when a tester executes the feature and checks if the application is working as it should. If there are issues with the functionality, it is up to the person responsible for the feature to fix them.
Deploy:
Finally, the deploy stage is where the code is ready to be deployed to a QA, pre-production or production environment per the organisation's plan. Deploying of the software can be automated through continuous deployment. This is the stage where the organisations prefer the deployment strategies such as the canary, rolling, blue/green, etc.
- Package and Deploy Automated Builds Using a CM tool: The moment the code passes all tests and a tester gives the go-ahead, this should trigger a process that automatically packages the application and deploys it to a testing environment. This is usually done by a Continuous Deployment tool that integrates with your CI server and allows you to define a certain deployment process. Depending on your needs, you can choose either a hosted solution or a self-hosted solution.
CI/CD with Harness
With the Harness software delivery platform, automating your CI/CD pipelines can be very easy. Setting up CI/CD can be a daunting task for many organozations but Harness helps tackle these most complex CI/CD challenges, such as onboarding new developers, new technologies, validating/promoting your deployments, and actions in failure scenarios. All the orchestration needed in the form of tests, approvals, and validation can be easily connected in the Harness platform. Automate the build, test, and packaging of code to artifacts with Harness Continuous Integration, and build deployment pipelines in minutes while safely deploying artifacts to production with Harness Continuous Delivery.
Let us take a look at how CI/CD works with Harness taking an example of a MERN Stack application.
Continuous Integration [CI]:
The CI phase involves the initialization, cloning of the code and running the specified tests.
Continuous Delivery [CD]:
CD involves specifying the service, setting up the infrastructure, passing the resource constraint and finally deploying the code with the preferred strategy. Make use of the MERN Stack application example created by the Harness community team and try using both CI and CD modules to do continuous integration and deployment of the application. The code for the MERN Stack application is in the harness-apps/MERN-Stack-Example repository, the Kubernetes configuration is in the harness-apps/MERN-Stack-Example-DevOps repository.
Latest comments (0)