8 Configuration management and stable releases

 

This chapter covers

  • Creating configuration management to change application functions
  • Exploring different options for configuration management
  • Hiding new or incomplete features with configuration feature flags
  • Communicating software changes through release notes and versioning

“I just can’t see how we can safely roll this out while we are still testing or how we can easily cut over to the new system once we are comfortable,” the QA lead says during a kickoff meeting. “I mean, we’ve been happy with the automated testing, and it has caught a few bugs already, but we can’t sign off on releasing this into the wild yet.”

“We can’t just have this sitting around, though. We need to be able to show that this rewrite is worth it. We have shown that we can make changes quickly and release often, but we need some real traffic to see how this is going to hold up, and the only way we can do that is if we start letting our customers use it.” Your project manager is beyond exasperated at this point. You’ve just gone through an entire rollout plan meeting, and once again, it feels like QA is stopping any sort of progress.

But as you sit there, you have to feel that QA has a point. We aren’t sure how this will operate under different loads, and we aren’t sure how this will work in our entire ecosystem. You mention this, but when you get a sideways glare from your project manager, you start to propose a solution rather than point out a problem.

8.1 Configuration

8.2 Advanced configuration

8.2.1 Environmental variables

8.2.2 File

8.2.3 Flag

8.3 Hiding features

8.3.1 Updating the port

8.3.2 External client

8.4 Semantic versioning

8.5 Change log

8.6 Accountability and handling failure

Summary