The main leg work is still being done by Matt Drinkwater and Anthony Speed, they are doing a great job scheduling and hosting the weekly QA focused webinars. I will be hosting weekly lean coffee sessions, designed to encourage further discussion about the weeks QA Babble talk.
The main talk will take place at 12pm every Wednesday (UK time – currently GMT + 1), and the lean coffee session will take place at 8am on Thursday mornings (also UK time).
Assuring Quality in CD with Tom McCawley
Tom’s talk was about his work setting up a real-world CI/CD process for a publishing company. With all the work that goes into the CI/CD process, its quite incredible that Tom managed to fit it into just 30 minutes. I’m more amazed I managed to fit so much information onto a single sheet of A4 paper. This was an incredibly detailed talk. A single 1 of these points could be a talk on its own.
A key point was explaining exactly what CD stands for. Some say Continuous Delivery, others say Continuous Deployment. There is a difference. Both involve merging changes in, validating using test automation and then deploying. But the different between the 2 is:
- For Continuous Delivery, the deployment is done manually.
- For Continuous Deployment, the deployment is automated.
Automatic deployment carries a lot of risk. There is a risk of insufficient tests, and a risk of no tests.
The risk of insufficient tests is mitigated by increasing coverage using automation, and introducing tests from all levels of the test pyramid (Unit, API, UI…). These checks are small and focused, and logging is introduced to make it easier to identify the reason for failure. Any gaps are identified and filled in using mocks, test spies and possibly introducing validation elsewhere.
The risk of no testing is mitigated using a strict policy where all tickets must have tests. If there are no tests, then the build will fail. Each branch and test case is tagged with the ticket number so its clear which tests belong to which ticket.
The introduction of CI/CD, and other changes to the deployment process dramatically increased confidence and trust in the pipeline. The fear of failure was reduced so much that the team were willing to just push the changes and see if it builds.
A full recording of the talk can be viewed here.