Edited by Christopher Douce, Monday 29 September 2025 at 18:12
This one of a series of posts that draw on Software Engineering Radio. This post is one of a group that relate to software engineering processes. On one extreme there is a waterfall approach, where everything is planned in advance. On the other extreme, there is ‘agile’ in all its different forms. Agile isn’t about not planning. Agile is about understanding that not everything is known, and about sharing technical and process information between developers.
Within each approach, there is the need to build software, and put what ha been built into production. This is where Continuous Integration/Continuous Delivery (CI/CD) comes in. CI/CD can be considered in terms of a pipeline of ‘stuff’ that happens from the point where changes are made to source code, to the point where changes to your software are used by customers or employees.
Two important points I’ve taken away from the Scrum podcast is that the team makes decisions about how to manage their own work, and they might apply CI/CD.
In SE Radio 498 James Socol discusses Continuous Integration and Continuous Delivery (CI/CD). An important question is, of course, what is Continuous Integration (CI)? (1:40) CI is ability to make small changes that are integrated into the main codebase of a product. A codebase is typically stored within a source code version management system, such as GitHub. CI also solves the problem of how to combine the work of different developers together (2:40), which can sometimes be tricky, especially if there are multiple developers working on the same bits of software at the same time.
The next question is: what is Continuous Delivery? (4:40) CD means taking the changes that have been integrated together and creating a version of a product that can be used. The decision about whether to use that version may be decided by software engineering team. Continuous Deployment (another version of CD) means that the updates (which are integrated together) are ‘going into production right now’.
A practical question is: what type of tools are needed? (8:50). Engineering teams need a way to create an automated build process (perhaps using products such as Jenkins or GitHub actions). Build tools gather bits of code that are to be combined (perhaps compiled) together, run a variety of tests (unit tests, integration tests or security tests) and then create a built artefact. The artefact that is created could be a ‘container’ which could then be deployed to cloud servers. A further point was: if things go wrong – if deployed software doesn’t work as expected, it should be possible to ‘roll back’ to a known version that does work.
The closing section of this podcast is interesting (48:00). It is important to monitor how a deployed system is running. This point relates to a fundamental of engineering. It is important and necessary to take measurements since it enable you to gain an understanding of how effective everything is running. This is reflected in the following passage within the SWEBOK: “In continuous development paradigms (such as DevOps), other metrics have evolved that focus not on the architecture directly but on the responsiveness of the process, such as metrics for lead time for changes, deployment frequency, mean time to restore service, and change failure rate - as indicative of the state of the architecture.” (SWEBOK, 2-11). There is a lot to unpack here: software can be deployed on, or across an architecture, and architectural choices relate to important requirements.
Another podcast on the same topic is SE Radio 585: Adam Frank on Continuous Delivery vs Continuous Deployment. Similar concepts are discussed in this podcast, but there are further discussions about the relationship between Ci/CD and how the principles relate to differences between monolithic applications and microservices (which we will get into when we get to the post on architecture).
There are also further comments about the different types of tests that could be integrated into the CI/CD pipeline (21:50). There is also a hint about further complexities which might emerge, such as the deployment to ‘staging environments’ before a product is moved towards production with real users. This links to the importance of managing risk.
Reflections
When I worked a professional software engineer at the start of the century, CI/CD wasn’t a thing, but it was something that I desperately needed.
I was forever switching between different programming environments to create different bits of software. Code, in the form of stored procedures had to be added to databases. Databases had to be saved into specific directories. Server side software written in C# has to be built into what were called assemblies. Everything had to be combined together into installation packages. If you forgot one bit, you had to do it all again. I’m pretty sure that I had a manual checklist. This checklist would now take the form of code. Of course, everything would all be done on the cloud.
This neatly take us to the next podcast, which is all about Infrastructure as Code (or, IaS).
Software Engineering Radio: CI/CD
This one of a series of posts that draw on Software Engineering Radio. This post is one of a group that relate to software engineering processes. On one extreme there is a waterfall approach, where everything is planned in advance. On the other extreme, there is ‘agile’ in all its different forms. Agile isn’t about not planning. Agile is about understanding that not everything is known, and about sharing technical and process information between developers.
Within each approach, there is the need to build software, and put what ha been built into production. This is where Continuous Integration/Continuous Delivery (CI/CD) comes in. CI/CD can be considered in terms of a pipeline of ‘stuff’ that happens from the point where changes are made to source code, to the point where changes to your software are used by customers or employees.
Continuous Integration/Continuous Delivery (CI/CD)
Two important points I’ve taken away from the Scrum podcast is that the team makes decisions about how to manage their own work, and they might apply CI/CD.
In SE Radio 498 James Socol discusses Continuous Integration and Continuous Delivery (CI/CD). An important question is, of course, what is Continuous Integration (CI)? (1:40) CI is ability to make small changes that are integrated into the main codebase of a product. A codebase is typically stored within a source code version management system, such as GitHub. CI also solves the problem of how to combine the work of different developers together (2:40), which can sometimes be tricky, especially if there are multiple developers working on the same bits of software at the same time.
The next question is: what is Continuous Delivery? (4:40) CD means taking the changes that have been integrated together and creating a version of a product that can be used. The decision about whether to use that version may be decided by software engineering team. Continuous Deployment (another version of CD) means that the updates (which are integrated together) are ‘going into production right now’.
A practical question is: what type of tools are needed? (8:50). Engineering teams need a way to create an automated build process (perhaps using products such as Jenkins or GitHub actions). Build tools gather bits of code that are to be combined (perhaps compiled) together, run a variety of tests (unit tests, integration tests or security tests) and then create a built artefact. The artefact that is created could be a ‘container’ which could then be deployed to cloud servers. A further point was: if things go wrong – if deployed software doesn’t work as expected, it should be possible to ‘roll back’ to a known version that does work.
The closing section of this podcast is interesting (48:00). It is important to monitor how a deployed system is running. This point relates to a fundamental of engineering. It is important and necessary to take measurements since it enable you to gain an understanding of how effective everything is running. This is reflected in the following passage within the SWEBOK: “In continuous development paradigms (such as DevOps), other metrics have evolved that focus not on the architecture directly but on the responsiveness of the process, such as metrics for lead time for changes, deployment frequency, mean time to restore service, and change failure rate - as indicative of the state of the architecture.” (SWEBOK, 2-11). There is a lot to unpack here: software can be deployed on, or across an architecture, and architectural choices relate to important requirements.
Another podcast on the same topic is SE Radio 585: Adam Frank on Continuous Delivery vs Continuous Deployment. Similar concepts are discussed in this podcast, but there are further discussions about the relationship between Ci/CD and how the principles relate to differences between monolithic applications and microservices (which we will get into when we get to the post on architecture).
There are also further comments about the different types of tests that could be integrated into the CI/CD pipeline (21:50). There is also a hint about further complexities which might emerge, such as the deployment to ‘staging environments’ before a product is moved towards production with real users. This links to the importance of managing risk.
Reflections
When I worked a professional software engineer at the start of the century, CI/CD wasn’t a thing, but it was something that I desperately needed.
I was forever switching between different programming environments to create different bits of software. Code, in the form of stored procedures had to be added to databases. Databases had to be saved into specific directories. Server side software written in C# has to be built into what were called assemblies. Everything had to be combined together into installation packages. If you forgot one bit, you had to do it all again. I’m pretty sure that I had a manual checklist. This checklist would now take the form of code. Of course, everything would all be done on the cloud.
This neatly take us to the next podcast, which is all about Infrastructure as Code (or, IaS).