4 ms·
The driver here is needing to make changes to the behavior of the app in specified ways, faster than the release cycle. My advice is to go no further than key-v
by vinceguidry 7y ago
The driver here is needing to make changes to the behavior of the app in specified ways, faster than the release cycle. My advice is to go no further than key-value configuration settings, and keep a documented set of Postman requests in the repo to serve as your UI for developers to invoke.
This way you get the immediacy of being able to change prod behavior outside of the release cycle, the safety of knowing only your devs can make those changes, and the ability to easily build a real UI later if the hidden features become features you want visible to non-technical users or your customers.
A rules engine is where the descent into madness begins. Every single thing the rules engine tweaks needs to be an actual feature with actual RESTful routes dedicated. Overloading a configuration regime, which is only supposed to handle keys and values, into the key instrumentation for the entire application, bolts inevitably poorly-documented semantics onto the application.
Different devs or departments will see the two competing regimes and pick whichever one they like the most to add on to. You'll end up with two kingdoms at war. You want peace reigning throughout your empire.
Configuration is part of your application infrastructure. Rules engines generate competing semantics. Semantics are how the brain understands systems. You want one overarching paradigm, one source of truth for how things get done in your application.
- hinkley 7y agoBack pressure is an important concept in distributed computing. It's also an important concept in project management. By and large, "We need changes faster than our release cycle" is a condemnation of your release cycle, your definition of "need", or both. I've 'forced' a fast, low-stress build pipeline on several teams and nobody wants to go back to before. And much to management's surprise, people will defend it after I'm gone (I think they see it as me being control freak bossy, rather than personal trainer bossy). They also participate in pushing back to a degree on these "emergencies" because we have a "fast enough" that is reliable enough that half the team is willing to be responsible for pushing the buttons. No, you can't have that before lunch. You can have it tomorrow morning, like we always do. Maybe you should think things through a bit more in the future? My current project was so big and Balkanized that I haven't found enough cracks to operate this way. So things are better, but feel worse in some ways because it's gone from nonspecific pain to specific pain. This is going to be the first time in 15 years I haven't left a team with a good CI/CD pipeline. But at least all the things you can change in between releases will be under version control.