What is Continuous Updating?
Continuous Updating means the regular update of your software projects. Mainly it focuses on libraries used. Like guava, Spring, Java.
But it also means in my opinion to regularly question your already made design decisions, architecture or in short everything. So ask yourself the question, if you would get the time and budget to rebuilt your current system.
What would you change if you would start from fresh?!
Keeping up2date with libraries
Sadly we all know how updating of libraries are handled. Usually you create your maven project and add the dependencies which are needed and then you never touch the library version again except if you need a new feature or need to update it because of another dependency.
Continuous Updating of libraries is very important for following reasons:
- You don’t come to a point when updating is getting really difficult and painful to update
- You get security fixes
- You get bug fixes you might not even know of
- You get performance improvements
- You get feature updates for free
- Syntax features. Like API extensions to support Lambdas
- Evolution of a feature, because we are no cave men anymore. For example. New date time API with Java 8.
- small or big new extensions of what a library already offers. For example guava added one more eviction strategy.
- Updating other depending libraries will be a smaller step
- You have a community which can help you if something goes wrong
But wait
Updates can also break your system. I mean it can introduce bugs, security holes or might not yet be ready for use in an productive environment.
In the end you need to update at some point. But is it directly at the release of Java 9? Do you wait until the first bugfix release?
Well the answer is like always. It depends how high is the risk it will break something?
You need to lower the risk with:
- good (>90%) test coverage with unit and integration tests. Otherwise you might not catch the one special usecase where it’s broken.
- Have a good as close to production test environment
- Small software project is updated at a time. If the project is small (e.g. micro service), then the risk and impact is simple to tell.
- For productive environment.
- Have multiple server running with different versions of the library in question.
- Use the feature toggle pattern to only effect a small amount of users, if the library change is like a major change in how it works. Like from apache http client 3 to 4.
Depending on the amount of risk involved you choose how much effort you are willing to invest to mitigate the risk.
Wait library updating – we forgot the bigger picture
Library updating means also to check if the library meets still our standards. Or are you still at log4j 1 instead of logback or log4j 2?
That means for me:
- Living community that maintains it and still produces regular releases
- Best suited for your usecase
- State of the art/current best practice for what it does. E.g. Guava caching should be replaced by caffeine.
- Software license is still usable in your usecase. E.g. library switched to GPL and you use it for commercially.
So throw away the log4j 1. Because frankly it’s ancient history. 🙂
The same also counts for your server software, OS, everything!
Like many people nowadays switched from their ancient JBoss 4 to micro services. Keep up2date with modern design patterns. But also don’t jump on the train just because it’s fancy looking or it seems to solve everything.