What is automation?

Simply put, automation is having technology do things for you so that you don’t have to. This text focus on software deployment automation.

It may surprise you the first IEEE paper about continuous automating deployment is a 2005 paper the term DevOps didn’t appear until 2011.

What is CI/CD?

Continuous integration focuses on blending the work of individuals and teams together in a repository.

Continuous delivery aims to minimize the friction points that are inherent in the deployment or release processes. Typically, the implementation involves automating each of the steps for build deployments so a safe code release can be done, ideally, at any moment in time.

Continuous deployment is a higher degree of automation, in which a build/deployment occurs automatically whenever a change is made to the code.

Continuous deployment is desirable to all kinds of environments but may be limited in production when Product Owners want to release a certain feature or groups of features based, for instance, on market conditions. That does not invalidate the need to have it, on the contrary, it just emphasizes it.

What are the benefits of Continuous Deployment?

The benefits most often cited are cost reduction, productivity, availability, reliability, and performance.

I add always consistency shortening feedback loops to the list.

All these reasons also apply to testing automation.

Even if you could manually achieve the other benefits, doing things manually will never be consistent. If you doubt, I can tell you how many times I closed a bug report with “cannot reproduce” until I got the same report days or weeks later. That was because testing was manual and testers would forget something in the steps they took. The same applies to manual deployments.

What about metrics?

For Lean + Agile processes, the basic metrics are lead time, cycle time, team velocity, and open/close rates. These metrics aid planning and inform decisions about process improvement.

Automation helps reduce lead time and cycle time and increases team velocity.

Lead time. How long it takes you to go from idea to delivered software. If you want to be more responsive to your customers, work to reduce your lead time, typically by simplifying decision-making and reducing wait time. Leadtime includes cycle time.

Cycle time. How long it takes you to make a change to your software system and deliver that change into production. Teams using continuous delivery can have cycle times measured in minutes or even seconds instead of weeks or months.

Team velocity. How many “units” of software the team typically completes a Sprint. This number should only be used to plan. Comparing team velocities is nonsense, because the metric is based on non-objective estimates. Treating velocity as a success measure is inappropriate, and making a specific velocity into a goal distorts its value for estimation and planning.

The metrics above are standard metrics for multiple industries and are not IT-only. Other metrics may be used in some industries or corporations, for instance, LTTV measures the time we commit to the work until it goes “live.”

What is a CI/CD pipeline?

Product development cab be represented by:

From phase to phase there are “gates” such as conditons of acceptance, definition of done and others.

Pipeline is not an accurate term because things don’t flow unimpeded. They may fail the “gate” condition and be sent back to one of the previous phases. So it is more like a “Christmas Tree.” That term is used by Chemical Engineers when you have a line with lots of valves and bypasses as it is represented above.

That system shows the need for not only validation, “the gate,” before moving to another phase but also to monitor the application for any possible exceptions and degradation once it reaches an environment such as production.

That also highlights the need to have roll back procedures because even with the “gate” conditions met, you still learn things after something is deployed and in use.

The following figure shows a “real world” pipeline.

A development team work and responsibility does not end with deployment!

Teams must never forget to include the following (Measure/Monitor):

  • Monitoring of an app or web site for things such as performance, exception logging, degradation. These impact the outcome, happy customers.

  • Easy roll back of anything in an environment to a previous state. Again, this goes to outcome.

  • Track usage of a feature. Without tracking usage, we can’t validate that a feature is serving the majority of the customers.

Monitoring and measuring also ensure that we can assess return on investment (ROI) so Product Owners can understand usage patterns and the actual business value delivered, if any.

Recent Posts

See All

Prior to the Scrum Guide 2020, the backlog refinement used to be regarded as a “quasi event” and a lot more was mentioned about it. So, what happened? As we know the Scrum Guide 2020 was “leaned” and

The Scrum Guide states that the Scrum Master is accountable for the Scrum Team’s effectiveness. Improvement is key to effectiveness. Previously, we discussed Scrumming the Scrum. That was all about co