5 Recommendations on Implementing DevOps CI/CD Pipelines

CICD Illustrated
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.

2 comments:

  1. You said: "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."

    I hear: automation has no business value.

    I disagree with that very strongly. Automation done correctly has a tremendous business value, and to be done such way it requires a developer mindset: infrastructure as a code is a buzzword.

    ReplyDelete
    Replies
    1. Thanks for the comment. I think you may be misinterpreting my message.

      Automation has significant value.

      There's automation that replaces the delivery pipeline that enables more frequent delivery, robustness when integrated with continuous testing, and far more reliable than following procedures.

      Infrastructure as code is also a level of automation that can bring value to organizations that want to tear up or down environments frequently. In practice, what I've seen is that some parts of infrastructure is easier to automate versus others. So some team only implement parts of it and may leave other steps as manual, one time steps. This is a practical choice.

      What I am also suggesting is to engage operations/engineers/sys admins on doing much of this automation. Most of these are system level automations and I'd rather see developers partner with the system engineers to implement parts of the pipeline and certainly the infrastructure.

      Delete

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share