FASTER SOFTWARE DELIVERY WITH AGILE AND AUTOMATION
“How long would it take your organization to deploy a change that involves just one single line of code?” (Mary Poppendiecks)
In the world of Continuous Delivery, the automated testing is not only important, but essential. Let us see how essential it is to shorten the deployment pipeline with the automated tests.
Now, let us consider these questions:
How long does it take from idea to production ?
How long does it take from idea until users start using the solution?
Do we provide the right answer to the problem?
From the time developers write the first line of code until users use the code in software, money is being spent. How long does it take to get the money back?
Continuous Integration can help you shorten the development cycle: from the first line of code unto providing useful features to the users.
If you develop a feature, but it is not the right solution to the problem, how long does it take for your organization to get the feedbacks that is needed, in order to react and change the feature?
Days? or even Months?
Let us say that we use three environments to run automated tests:
DEV: build on every commit, compile the code, run the unit and component tests
AUAT: run every 2 hours, get the production data, run the AUAT (automated functional tests)
LOAD: run every 5 hours, get the production data, load and stress the system
AUTOMATED FUNCTIONAL TESTING (AT)
LOAD TESTING PIPELINE
let us see this illustration: one developer changed a single line of code and committed it. We want to pass all the tests before pushing the binaries to production.
The process is sequential: Dev: 36 min AUAT: 1.5 hour Load testing: 1.5 hour
TOTAL: 36min + 1.5 hour + 1.5 hour = 3.5 hours
After 3.5 hours (manual testing is excluded without pause), considering all automated tests passed: the build is ready for production!
This is not too bad, but it is not optimized. We need faster feedback. Another point to consider is that many developers might be working on the project and committing code. It's going to get harder to spot which commit broke the tests.
Here are some possible improvements:
Each environment run the whole deployment pipeline
Parallelize automated tests
Fire-up environments on demand
Stage the deployment pipeline
Combine all of the above
We will go through the details in future posts on this blog.