4 steps to implement a CI/CD pipeline

Source:-jaxenter.com

The software industry is headed in a new direction that emphasizes rapid iteration. Longer release cycles are well-tested and stable processes, but they come at a cost. Reacting to customer feedback is slow and implementing patch releases can be complex. By shortening the release cycle, small teams with limited resources can use production releases to quickly gather a lot of data. And large companies can capitalize on market responsiveness, shorten issue resolution cycles, and more quickly innovate to improve user experiences.

Continuous integration and continuous delivery (CI/CD) is a shortened feedback cycle that helps companies ship more software while minimizing mistakes, increasing developer productivity, and improving customer sentiment. Automation and testing are crucial to this process. Let’s examine what the workflow for a CI/CD process looks like. Changes to code go through a testing phase and are then deployed to 10 percent of customers. The code goes through another automated period to check if it’s safe to send to the remaining customers. After that, the code goes through an automation/QA phase where uptime monitoring comes into play. Finally, a triage phase allows developers to integrate feedback and fix issues.

CI/CD can be a rigorous process, but it’s a worthwhile venture for development teams of all sizes. However, it’s a concept many companies talk about but struggle to execute. Here are four steps companies need to implement as part of a CI/CD pipeline:

The Conference for Continuous Delivery, Microservices, Containers, Cloud & Lean Business
Arun Kumar Singh
Workflow Engines: Our Journey towards a self-healing Infrastructure
Arun Kumar Singh (Adobe Systems)

Elizabeth Carretto
Stop playing Detective – use Observability to tell a better Story
Elizabeth Carretto (Netflix)

Shen Brisals
Serverless Patterns made simple with real-world Use Cases
Shen Brisals (Lego)

DevOpsCon Program »
Integration: Merge changes frequently and verify through automation
One challenge teams face is accepting the integration process will be demanding and time-consuming. A lot of what developers build at this stage is meant to future-proof code against downstream issues. Developers rarely write tests to confirm the code they’re developing is correct. Instead, they write tests for when someone changes the code in the future. When that change does occur, the test will fail at the right time and prevent someone from causing more problems.

A successful integration phase comes down to a change control process—a process that allows developers to do their best work while making minimal interruptions to everything else. A proper control process includes these steps:

Propose a change and outline the issue.
Peer-review the change, which can take the form of design feedback, or use case suggestions.
Verify the change via automated testing.
Determine whether the change can be merged.
Deployment: Ship code as soon as it’s ready
Continuous development eliminates the need for a designated release manager to press the deploy button or sign off on changes to be rolled out each day. Instead, teams control their projects and contributors are responsible for deploying their changes.

The deployment phase of continuous shipping fosters builds that are repeatable. When building software, there’s a reliance on a combination of dependencies that aren’t controlled well. Unfortunately, if a version or dependency changes, the app built with that software might not work.

SEE ALSO: Extending CI/CD: Kubernetes Continuous Deployment for Microservices

In the deployment phase, minimizing risk depends on the rollout strategy. While this process can be challenging, the effort pays dividends. The simplest way is to deploy to a staging environment and verify code is working. While this method works, it doesn’t scale. Instead, a better approach is to roll out the change to small percentages of customers and stop the change if something breaks.

Another contribution to risk minimization is blocking deployments that haven’t passed verification. Do not allow anyone to circumvent the required tests. Many companies have compliance regulations that prevent changes from deploying if they bypass the change control process. While this is an easy rule to set, it requires diligence from QA. The process is time-consuming, but the result is happy development teams and customers that get to use an app how they expect to.

Monitoring and tracing: Know where things go
There are a few ground rules for the monitoring phase:

Construct monitoring from the ground up.
Build instrumentation into applications rather than bolt on top.
Execute observability in real-time.
With this structure in place, developers have the necessary foundation to implement two important QA best practices: high-level tracing and root cause analysis. These expose problems with the code not only at the application level but also at the system level to gain deep insight.

While graphs and logs may illustrate symptoms, they don’t identify a root cause. For example, a customer loads an app, clicks a button, and that call hits an API service that errors. The developer sees an error in the app and the API service sees an error, but is that enough context on its own? Sometimes. But it is better to know the details and context of what happened in the app. This type of high-level tracing is necessary.

In complex applications, many things could be communicating to cause this error. The cause could be tied to clicking the button in the app, or it could be deep within the app or even the server-side, which is why it’s so important to uncover the root cause and fix it. To solve the problem, a developer needs to know when and where the bug started, as well as when the code change was introduced. If a developer knows the root cause of a problem within seconds, they can automate the triage workflow. They can deploy a change to production and a tool can tell them if there’s an increase in errors. They can decide whether that change is safe or needs to be rolled back.

Feedback: Identify users’ needs and issues
Customer support is a useful element in a CI/CD pipeline. It’s important to be active with automation and alerts. Why should developers be asked to reproduce a problem when there are monitoring tools that can tell them that automatically? Nine out of 10 customers won’t complain, so waiting for customers to flag errors isn’t a reliable strategy. Businesses should know about issues before their customers tell them. Errors are the first sign of a customer-related issue.

SEE ALSO: GitHub joins the CI/CD fray: GitHub Actions automates workflow

It’s also important to be reactive with feedback requests. What is the customer’s intent? How committed is the customer to a project’s success? Context is critical, as it expedites the resolution and reduces the friction developers and customers experience. There is technology to collect data without adding steps for customers. The goal of this phase is to optimize resolution cycles. If businesses can identify errors and connect them to customers, then they can communicate with customers who have been affected by a problem. A lot of problems aren’t difficult. It’s about iterating quickly and efficiently.

Transitioning from a long to shortened release cycle using CI/CD may challenge development teams. But the results — quick, efficient iteration and improved customer sentiment — are worth the effort to modernize.