Continuous Delivery and Continuous Testing are essential elements in understanding how to build out capabilities for continuous development and deployment of software.
We talked about Release Planning (RP) and Continuous Integration (CI) in part one of this series. Those two capabilities aid in story creation and agile software development.
Now, I want to talk about Continuous Delivery (CD) and Continuous Testing (CT). This part is where we get into more automation.
Continuous Delivery
Continuous Delivery (CD) is a bit complex these days. In the past, as companies requisitioned “static” servers from the IT team, potentially delaying completing provisioning step for weeks.
For example, you might write a “Deployment” with Chef recipes to deploy packages to the provisioned server. However, due to the proliferation of cloud computing, the provisioning of environments takes on a new meaning.
Infrastructure as Code (IaC) is now more commonplace in organizations. Having stories around configuration management as well as IaC is critical for the Configuration or Provision Epic. If you modernize your infrastructure architecture, using containerization is the next step for the Package or Deploy Epic. It’s important to have stories around docker or serverless technology, like Lambda.
Automatic recognition of the completion of a step that immediately triggers the next step speeds up your pipeline. The CI Engine controls this process.
The chart below explains:
If a step fails, feedback goes to the team responsible for fixing the problem. Whatever the problem, whether it’s with the code, test data, or another issue, the team needs someone available to address the issue quickly, to restart the processing of the pipeline again.
Continuous Testing
When it comes to the Continuous Testing capability, Functional Testing (FT) and Performance Testing (PT) are the center point for your Epics.
For FT, you need to create a test automation framework that suits your application profile needs. A Selenium-based framework might work for testing web applications, or you may want to choose a Cucumber-for-Ruby framework for functional test automation.
When broken down, these stories need several sprints worth of work. Place all stories in the Product Backlog. Also, pull only those stories you can work on during a sprint into the Sprint Backlog. FT frameworks take months to set up, and we’re not even talking about automating test cases yet.
Remember, test automation makes the most sense to management. They know you must test. The challenge is implementation, because implementing test frameworks is the hardest of all the DevOps capabilities.
For those applications with performance requirements associated with them, having a Performance Test (PT) suite makes the difference between a 10 second versus a one second response time on your website. Base your stories on the type of performance tests needed.
Why is Continuous Testing after Continuous Delivery? Well, Continuous Delivery, as I define it, means “having code in a deployable state.” I don’t focus on “where to deploy” that code. I need code deployable at any time, to any environment. You can’t test anything until you deploy code to an environment.
Finally
In this section of our three-part series, we focused on Continuous Delivery and Continuous Testing. You now understand how to build out capabilities for continuous development and continuous deployment of software.
Next time, we’ll wrap up with Continuous Monitoring & Observability (CM) and a few other concepts around the security of your applications.