When deployments are easy, code becomes simpler
bitbytebit.substack.com
When deployments are easy, code becomes simpler
1–10 of 124 posts
Re: When deployments are easy, code becomes simpler
#2> Is this bad because I now have to do a deployment to enable the feature? ... I would argue as long as your deployments are easy, this is the better way to do things because it reduces the complexity of integrating with a third-party tool.
Shoot, even when it's all first party tooling, I prefer a release-flags-and-binary as an atomic unit. If the flags and binary are going out as a single push, it simplifies a lot of things:
* reproducible state for given time with only one thing to track (running version), instead of two or more things (binary version, flag configs version)
* corollary: rollbacks are much more simple, because it's just one thing to rollback - the code+config+everything as an atomic unit, not "did we need to roll back the flags, or the binary, or both?" (Corollary to corollary: removes the awful problem of "oh shit the code and/or flags/configs wasn't backwards/forwards compatible" where you shoot yourself in the foot while doing a rollback
* removals and cleanups are easier: can remove flags, config bits, and code all at once, instead of having to do a careful dance of "set code behavior to default-on and remove dependency on flag, the wait for full deployment, then make sure everyone is okay with not rolling back after a given point, then remove flags and config logic"
* depending on your tooling, diffs vs prod during code review get cleaner
Re: When deployments are easy, code becomes simpler
#3Anyone have advice for teams without control over when their software is deployed by the people actually running it? Say you have a product released to a third party and they may or may not take releases and may be arbitrarily delayed in deploying those they choose to take.
Re: When deployments are easy, code becomes simpler
#4> I did an inventory of my recent feature flags and realized that about 80% of them aren’t there to roll things out to specific populations, or do any sort of A/B testing, but to hide unfinished code.
Maybe it’s just me but having unfinished, dead, or scratch code in a production codebase really annoys me. Either finish your work or delete the unneeded code. More than a few times I’ve sunk time out of my day into investigating some code path only to realize it’s completely unused.
Re: When deployments are easy, code becomes simpler
#5> I did an inventory of my recent feature flags and realized that about 80% of them aren’t there to roll things out to specific populations, or do any sort of A/B testing, but to hide unfinished code. Maybe it’s just me but having unfinished, dead, or scratch code in a production codebase really annoys me. Either finish your work or delete the unneeded code. More than a few times I’ve sunk time out of my day into inv…
[deleted]
Re: When deployments are easy, code becomes simpler
#6> I did an inventory of my recent feature flags and realized that about 80% of them aren’t there to roll things out to specific populations, or do any sort of A/B testing, but to hide unfinished code. Maybe it’s just me but having unfinished, dead, or scratch code in a production codebase really annoys me. Either finish your work or delete the unneeded code. More than a few times I’ve sunk time out of my day into inv…
“Unfinished” can mean abandoned, but it can also mean half-baked code that has been pushed to master even though it’s still actively being developed and is nowhere near ready to run. Personally I prefer long-lived feature branches; this is a risk with no payoff.
As for experimentation, I like percentage rollouts with segregated control/treatment group metrics. I agree that trivial on/off flags should be replaced by code deployments where possible (at my day job, code deployments happen to be a lot slower).
Re: When deployments are easy, code becomes simpler
#7Feature flags give you orthogonality.
When you have an `if False:` or equivalent in code, you have to deploy to enable a new feature, so if the current state in the test environment isn't good, you either have to wait for it to be fixed, or to roll back all possibly bad new commits before you can enable the feature.
Another feature of feature flags is that a non-coder can toggle them.
If you need neither of these, sure, go ahead with commits and deployments instead.
Re: When deployments are easy, code becomes simpler
#8I have recently seen someone wrap a single function in about 10 classes of Java to turn it into a standalone application, slap on some Docker Compose magic, add some build scripts, and then continue to look proud at the feature being wholly configurable at deployment time.
Of course, the deployment team would have to be informed about this change, so some documentation was required as well, but that was exactly the part of the process where most effort was saved.
Note that all this was used for a system that would be deployed only at one customer, and the feature would always be on. Yes, a boolean flag would have been a better solution for this.
My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated.
Re: When deployments are easy, code becomes simpler
#9I have recently seen someone wrap a single function in about 10 classes of Java to turn it into a standalone application, slap on some Docker Compose magic, add some build scripts, and then continue to look proud at the feature being wholly configurable at deployment time. Of course, the deployment team would have to be informed about this change, so some documentation was required as well, but that was exactly the p…
> My cynicism is probably not the best approach to change the world for the better, so any hint on how to teach younger colleagues to stop snacking micro service candy is much appreciated.
I could be way off base here, but I'd bet a lot of junior devs are just trying to stand out. They want respect, raises, promotions, and new job offers. Invisible good solutions don't bring those.
Re: When deployments are easy, code becomes simpler
#10I have recently seen someone wrap a single function in about 10 classes of Java to turn it into a standalone application, slap on some Docker Compose magic, add some build scripts, and then continue to look proud at the feature being wholly configurable at deployment time. Of course, the deployment team would have to be informed about this change, so some documentation was required as well, but that was exactly the p…
Just raise it up early, often, and simply.
"Isn't this just a Boolean flag? If X else y?"
I've saved a great many man months by doing just this. Sometimes work just vanishes. And it's not just the juniors that do it, sometimes the senior / tech lead types just miss a crucial point to make the solution trivial.
But juniors are often used to wanting to make work, rather than solve a problem.