Everything that we’ve done to this point – Version Control, Deployment Automation, Continuous Integration, Trunk Based Development, Test Automation, Test Data Management, Shift Left on Security – has all been leading up to one thing: Continuous Delivery.
Continuous Delivery is all about having the application deployed continuously, whenever needed. But there is a key piece that really needs to be understood before you head down this path.
It’s not just about making sure that the application can be deployed at a moments notice, it is changing the mentality so that anything that impacts the ability of the system to be deployed is fixed.
… the team prioritizes keeping the software in a deployable state over working on new features.
This is a key, fundamental difference that people need to understand. Trunk based development helps with this, but you need to supplement with feature flags. You need to have a loosely couple architecture (tomorrow’s note). You need to design, build and implement in a fashion that promotes the well-being of the application over the implementation of new features.
Innovation is useless if the application is dead.
This may seem like common sense to some of you, maybe most of you, but then I would ask “What have you done to ensure this happens?” Each of us plays a part in this sort of philosophy.
Let’s take a look at funding. When the application breaks do you need to get funding to fix it? If the answer is “yes”, then you need to work on the funding model. You should not need to “get funding” to fix something that is currently broken. Fixing it should be a no-brainer. Fixing it should something that you do immediately without having to worry about who is going to pay for it.
If the application breaks does everyone know who needs to look at it and fix it? Is a person / team / owner assigned so that someone is aware of the issue and can work on resolving the issue?
Is the end-user the person telling you that something is wrong or is the detection of problems something that is automated? I’ll give you a hint, if it is the end-user that notifies the support team of issues you are not thinking along the lines of ensuring the application is up and running at all times. (More details on this on July 24th if my schedule holds true.)
Continuous Delivery is an idea, but more importantly, it is a promise. A promise to ensure that the application is in working condition and that changes can be implemented as soon as possible. And like all promises it holds a special meaning for those to whom the promise is made.
Don’t mess it up. Don’t promise something that you can’t deliver.