Chapter 14. Keeping Things Up-to-Date
Software evolves, and that includes the software written by someone else that your software depends on. That could include operating systems, programming languages, libraries, databases, and applications. All of them will have both minor and major version changes, and you need to upgrade or migrate before versions go out of support (or more urgently, when the version you are on has a security vulnerability).
Keeping things up-to-date can become a long and tedious grind, sapping the joy for teams. However, if you invest in your ability to manage change, you can make this considerably less painful for everyone.
In this chapter, I want to start off by discussing the things you can do to minimize the impact of changes.
Then, I will cover the different types of changes that might affect you, from emergency changes in response to external factors, to planned changes at different scales in terms of time and commitment needed.
Next, we’ll explore two aspects of managing change. The first is responding to changes from outside your team. This could be from a platform team changing vendor, or someone either internal to your organization or outside it introducing major changes in their API.
The second is about how to manage the impact of changes you are making. This might be because you are choosing or being forced to move or upgrade versions from a vendor or provider, or it could be changes to your own software that others in your organization consume. ...
Get Enabling Microservice Success now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.