CI/CD is one of the key devops practices because it enables teams to align on development practices and ensure there is a consistent, reliable, and automated way to deliver applications to multiple compute environment.

If you’re new to CI/CD, consider reading my InfoWorld posts on What is CI/CD and on getting started with CI/CD. What you’ll see is that there are many steps to mature this practice with some steps that need alignment of team practices and others that require engineering work. There isn’t one way to implement CI/CD and it’s easy to get lost on where to start and how much to implement. So with that in mind, here are five of my recommendations on implementing continuous integration and continuous delivery:

1. Identify business and technical objectives

For most organizations, CI/CD pipelines aren’t implemented overnight and are more often implemented incrementally. That means most devops teams have to prioritize what practices to develop, what processes to automate, and what platform stacks to focus on.

The best way to do this is to look at short term business priorities and align both devops and CI/CD objectives to them. If there are new applications being developed then that’s an optimal time to focus on the CI/CD pipeline for them. If you are undergoing a cloud migration, then standardizing architectures and developing CD pipelines for applications that undergo the most frequent changes is a good starting point.

2. Start CI/CD with Continuous Testing

My friend an colleague said it best

“Organizations needs to focus on the fundamentals first, meaning ensure the source code has programmatic unit tests, passes static code analysis and security scans.” — Thomas J. Sweet

Increasing the speed of delivery only works if you’re able to deploy quality code and near defect-free applications. That means implementing automated tests and plugging them into CI/CD to support continuous testing. And not just unit tests. Add in code analysis, security, and performance testing that should all be triggered from CI/CD with every major push to staging and production environments.

3. Standardize the architecture before implementing CD

Automation provides value when it can be repeated reliably. For development teams, that means deployment to multiple types of development and testing environments and one or more production environments. If the architecture of these environments are not standardized, it’s hard to get the benefits of automation.

If you have to clean up the architecture, consider automating the infrastructure as code using chef, puppet or ansible and leveraging either docker or kubernetes containers.

4. Align short term business objectives with CI

Some teams get carried away and drive CI/CD toward continuous delivery, but, continuous delivery may not be appropriate for every business or application.

In addition, teams need to think through how they will implement longer running feature development. If the business objective is to launch just a handful of features that are not tightly coupled, then using feature branches may be a good enough solution to separate out feature tracks and merge when ready. However, if there are many features being developed over an extended period of time, then development teams might want to look at feature branches for some and feature flagging for others.

5. Let the system engineers implement CD

CD requires a lot of scripting, knowledge of the computing (cloud) architecture, and knowledge of the application’s requirements. Teams might be tempted to let the developers on the team to take on the challenge of learning CI/CD tools and implementing the automation, but I believe the strongest teams will engage the engineers to take on this work.

Why? Because I’d rather see developers implementing business solutions and coding applications. It’s better use of their skills. And, I’d rather see the engineers more versed in systems programming including IaC and CI/CD.

CI/CD should also drive platform rationalization

Some final thoughts…

There is an expense to standardize computing architectures and develop CI/CD pipelines for them. So larger organizations with multiple development stacks should consider consolidating to a handful of approaches. It’s not easy or cheap to have lots of ways to code applications and automate software delivery.