Why are fast release cycles so important for software development – and what strategies can help to avoid accidents although the team is producing at high speed.
Fast release cycles create customer value
The goal of every software development team should be to deliver new functionality to the users as soon as possible. Why? Finished software that sits in the shelf waiting for the next release is not usable. It is incomplete work, wasted effort and money. To add value you need to put that shiny new feature in the hands of the customer. Only then the new features make a difference in the real world. This means your software is only complete after the release and deployment. The entire process from development and testing to deployment needs to be optimized for speed.
Fast release cycles enable flexibility
Or think about a situation were your tests have discovered a security problem in your software. Now you need to be able to fix it quickly. Or you may need to adapt to a breaking change in some other consumed service that is not even in your own hands. Things happen, and in Cloud World you need to be flexible and able to adapt quickly. Once again – you need to be able to fix fast, but this only helps if you are also fast at testing and deployment. However nobody wants to be reckless. Jump and see how it goes? You want to be sure that your fix works.
Why incremental changes are your friend
The good news is that you won’t change the entire product from one day to another. If planned accordingly the team can break down the work into small steps. Ideally these can be tested individually to get immediate feedback. It works? Great. There’s a new problem? Ok, we should know pretty well where it comes from since only a small number of changes occurred since the last good version. And the developers will have these changes fresh in their minds. Fixing the problem should be much easier compared to yesterday’s approach were many changes came to test a long timer after implementation -and all at the same time. So let’s assume the new small change is implemented and tested separately.
The next and final step is to deploy this incremental change and we’re done? Sounds too good to be true and indeed… How can you assure that the small change didn’t cause any side effects and broke something within the existing overall system? This is called a regression.
The new bottleneck: regression testing
So you need to test for regressions. And this basically means that you need an overall test of the entire system, which often is a huge effort. If you want to be on the safe side you will have to repeat this exercise over and over again for each small incremental change. Now if such an overall tests would take days or weeks it kills the nice-and-small incremental approach. It would just be too slow and too expensive.
The only way out of this dilemma is…
Test automation – the enabler for high speed releases
Imagine a setup where you could prove with a click on a button that your software is doing what it is supposed to do. That today’s changes did not introduce any regression. Test automation aims at achieving this. Manually clicking through an application may still have its place within an overall testing concept. But in no way this should be your normal approach. Put the test procedures in code and execute them automatically. This is what enables quick feedback to code changes – and therefore fast release cycles. This automated approach has the added benefit of repeatability – and test status reports that your the test framework will create automatically if set up accordingly.
Does this mean that testers are not required any more? Not at all, rather the opposite is true. Test automation won’t save cost – this is about saving time and improving quality. Or in other words: about avoiding regressions although the team is going at high speed. This is where testers play a key role. However with test automation the tester’s focus and know-how profile changes completely. Yesterday testing meant manually executing test procedures over and over again. Today it means development and coding of tests. Testers are becoming developers – or developers take more and more responsibility for testing. Welcome once more to DevOps world. (more here).
Fast software release – mission accomplished?
So let’s assume you the team works with incremental changes. You have automation in place to quickly test the changes for functionality and regressions. We are good to go – now what needs to happen to put the new version to production – into the hands of the users? This will be covered in the next article about Deployment automation. Stay tuned.