Skip to content

CICD#

CICD is an acronym for Continuous Integration & Continuous Deployment two concepts that describe an often desirable state of change management for software or software controlled systems.

Continuous Integration#

Continuous Integration is the concept that changes to a code base are continuously fed into a main definition of the code base. Changes are then tested through suites of automated testing to confirm that the changes don't introduce defects and meet the desired outcomes.

Continuous Deployment#

Continuous deployment is the concept whereby changes that have been integrated into the main code base are then deployed into the systems environments, often starting at the lower end such as development (dev) before migrating into test before eventually being promoted into production.

Along each stage more automated tests should be ran against the latest version of the system probing and confirming that the changes don't bring about negative defects or bugs but also confirm that the changes a suitable to be added into the production version of the system.

Continous Delivery#

In some instances CD can also refer to the concept of Continuous Delivery, whereby a software development team is capable of creating changes to the system at will. In this respect continuous delivery can be thought of as the combination of CICD that allows software teams to take changes on a product backlog and deliver them to the users as fast as their ability to code, integrate, test, deploy and verify will allow.

Automated Testing#

Automating the tests suite is the best way to ensure that changes introduced by a developer don't negatively impact the operability of a system. Many types of software test can be automated and included into the definition of a system. Using test automation is an important part of the DevOps concept and feeds into CICD as a way of feeding back change readiness to the developer. For full details on Automated Testing see the section on automated testing

Releases#

Releases in any system a a critical piece where changes are deemed stable and sutiable enough to be included into the working definition of a system.

Semantic Versioning#

Semantic Versioning is a versioning reference that aims to indicate types of changes and therefore risk of adoption. Versions are labelled major, minor & patch and denoted by a numeric value. For example 1.0.0 is the first major version of a system, 1.1.0 indicated the same stable offering in version 1 but with a new feature, 1.0.1 indicates a patch fix and indicates a small change made to improve something like a security bug or styling defect.

Metrics for Success#

A good place to start when thinking about your capability to manage change is to consider the DORA Metrics, specifically change frequency rate and change error rate as this indicates how capable (how often) you can change the system and whether or not those changes bring about a positive or negative outcome.

In addition to these key metrics Mean Time to Recovery (MTTR) is also critical as this measures the teams capability to recover a system to a functioning state in the event of an incident.