[HN Gopher] When deployments are easy, code becomes simpler
___________________________________________________________________
When deployments are easy, code becomes simpler
Author : recroad
Score : 38 points
Date : 2023-09-05 20:33 UTC (2 hours ago)
(HTM) web link (bitbytebit.substack.com)
(TXT) w3m dump (bitbytebit.substack.com)
| smokel wrote:
| I 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.
| digging wrote:
| > 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.
| kdmccormick wrote:
| Seems cynical. In my experience, junior devs are just more
| susceptible to cargo-culting and getting excited about cool
| ways to apply the things they learned in undergrad. I haven't
| actually seen a lot of "resume-driven development" in my
| (relatively limited) time in the industry... just well-
| intentioned eager people with more knowledge than wisdom.
| catchnear4321 wrote:
| junior devs are junior devs in part because they do not yet
| know that there is no guarantee that anyone else has been
| keeping track of their victories come review time.
|
| solutions are only invisible due to a lack of sufficient
| documentation and communication.
|
| boring solutions are part of the job. they can be fun if the
| goal is shifted from implementing to automating.
|
| none of this to say you are wrong, but a junior dev that
| succeeds at such peacocking efforts is signaling the poor
| health of their surrounding team as much as their eagerness
| to impress. where was the manager or senior dev to say
| "great! have you considered a boolean?"
| drekipus wrote:
| 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.
| huac wrote:
| I wanted a very simple feature flagging solution, so I wrote my
| own with Google Sheets as the backend:
| https://github.com/stillmatic/flagsheet
|
| It's slightly more complex than a code push but still very easy
| to use.
| dmoy wrote:
| > 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
| teeray wrote:
| Anyone 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.
| GrinningFool wrote:
| You're in a for a long tail of pain if you have significant
| uptake.
|
| To avoid this, you will need have a clear policy on what you're
| willing to support (eg versions up to 1 year old, or "major
| version - 1", etc.), and stick to it. Otherwise, people will
| expect you to support all of it, forever.
| perlgeek wrote:
| Feature 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.
| bsima wrote:
| > 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.
| [deleted]
| erik_seaberg wrote:
| "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).
___________________________________________________________________
(page generated 2023-09-05 23:00 UTC)