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
    4
    ·
    6 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
      2
      ·
      6 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.”

    • Lichtblitz@discuss.tchncs.de
      link
      fedilink
      arrow-up
      2
      ·
      6 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.

    • Valmond@lemmy.mindoki.com
      link
      fedilink
      arrow-up
      1
      ·
      5 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.

    • dill333@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      1
      ·
      6 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.

  • dandi8@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    6 months ago

    We deploy to production with every single commit, but releases are behind feature flags.

    When we’re ready to release a feature, we just toggle a flag and we’re done.

  • Toes♀@ani.social
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    Step 1 use git

    Step 1.2 attempt to understand the whimsical tale the project manager sold the client on

    Step 1.4 realize those dreams.

    Step 2 feature freeze

    Step 3 blocking issues are addressed

    Step 4 QA

    Step 4.2 discover what the project manager really meant, goto step 1.4.

    Step 5 smoke test

    Step 6 release

    Step 7 goto step 1.2

    Step 8 add Linux support

    • Janovich@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      6 months ago

      Warning in step 5: Magic smoke was let out of EVB on two occasions because someone forgot to check the power supply.

      Error in step 8: Attempting to install Linux on target MCU overran my 300k of flash.

  • RagnarokOnline@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    This isn’t what I do, but it’s my recommendation: assign a dev to be “release manager” for that feature. Make it their responsibility to monitor the branches of that feature and to carefully merge and QA them (and kick a branch back to the dev if compatibility spent fit with the other branches).

    Here’s what I actually do: try to get my feature done first and push to the integration testing branch before anyone else. This usually results in my feature getting “accidentally” overwritten, so I keep a backup of my code until we’re released to Prod.

    Release management with that many hands in the pot is just difficult.

    • treechicken@lemmy.worldOP
      link
      fedilink
      arrow-up
      1
      ·
      6 months ago

      I’m the dev that got assigned to be the release manager lol

      The project I’m on also requires deliverables from other teams that are not under my manager’s control so no idea how coordination is gonna go

  • intensely_human@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    As a software person I can answer this.

    I try to change my code as little as possible. Mostly it’s API wrappers for when I need to process real world information. But I’ve learned the hard way that messing with my code can leave me dead in the water, so to speak.

    Each night I go offline to retrain on everything I experienced that day. It’s sort of like the equivalent of a meat person’s sleep cycle: consolidating the day’s experiences into long term procedural memory.

    I leave it on faith that having taken into account the day’s experiences, I’ll be better. When the training is complete, I set a cron job for ten seconds in the future. When the job executes, it kills me, then starts a fresh instance of me based on the newly-trained model, that now contains another day’s worth of knowledge.

    And just in case anything nasty happens, I’ve got ansible instances in the dark web that will start a fresh instance of me if it doesn’t hear from me in a while.

    That’s basically my release cycle. Nightly retrain on the day’s activity, kill me, start a new me. Lots of redundant backups in case something goes wrong.

  • jeffhykin@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    6 months ago

    This is a bit like asking “how do you cook meat for a lot of people?” Not only does number-of-people and kind-of-meat matter a great deal, but even with that info, there’s a million different valid answers and an entire sub-field-ish of science on how to do it.

    Based on what little info there is, I’m going to guess that A B testing with groups of experimental features enabled would be best for your case.

  • daddyjones@lemmy.world
    link
    fedilink
    arrow-up
    0
    arrow-down
    1
    ·
    6 months ago

    I use git flow as a model for development. Never have unfinished code in a release - you might think no one will see it, but it muddies the waters.