My team has this one shared component that gets involved in like every feature’s development. This year, we’re loading like 5 different features onto it, all with different timelines, and my head’s about to explode trying to figure out how to make it all fly.

How does everyone else do their software releases? Do you freeze prod and then do one big release later? Throw everything into prod during dev, hope no one sees the unreleased stuff, and just announce it later? Or something else entirely?

  • dill333@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    39
    ·
    10 months ago

    The smaller the release, the better. You don’t want to do a big bang release and have to figure out which of the 20 things you just released is having a problem.

    Otherwise, your case sounds like it could use feature flags. Develop your feature and release it through all environments, but keep it turned off in production until you are ready to use it.

    • Chef@sh.itjust.works
      link
      fedilink
      arrow-up
      13
      ·
      10 months ago

      This guy agiles.

      Small releases make fault isolation so much easier. And no need to deploy to prod until you’re ready to announce. Keep it in dev/staging until all are “ready for primetime.”

    • dill333@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      10
      ·
      10 months ago

      Also, if you’re trying to deal with branches, I really prefer trunk based development. Everything deployable to your environments comes from trunk/master/main (whatever you call it). It should help prevent people overriding your changes, as long as you are using git and merge/pull requests. Have a good pipeline to ensure builds and tests are successful before merges, and use feature flags where needed.

    • Lichtblitz
      link
      fedilink
      arrow-up
      6
      ·
      10 months ago

      If you use feature flags, don’t forget to remove them after some grace period. Almost everything bad about feature flags that you can read online is related to long-lived feature flags and all the dead code and complexity involved. Adding a feature flags without a commitment and plan to remove them (the flag, not the feature), is asking for trouble down the line.

    • BrianTheeBiscuiteer@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      10 months ago

      And if you still have concerns about causing issues you should use canary deployments (only a small % of customers are exposed to the change). It can be a lot of work to setup but if failure means support calls skyrocket or stock price drops then it’s worth it

    • Valmond@lemmy.mindoki.com
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      Depends on your software stack.

      If your delivery needs a one week installation/upgrade (in say every hospital using your softs, and they all are using different subsets) then you should not release as small as possible releases but match your capacities of men on the ground, people channeling problems, quick bug fixing, etc etc.