Software people, how do you do releases?

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?

dandi8,

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.

Ohi,

Over SFTP like a pro 🤙

intensely_human,

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.

Kbin_space_program,

If you have multiple branches you're mixing into one:

  1. Have a code repo. Shockingly a consulting firm I worked at didn't have a repo system.

  2. QA each branch.
    Merge all the code.
    Deploy to a testing server and QA that. Fix as needed
    Deploy to staging for final testing. Test and verify deployment procedure. Fix as needed
    Deploy to prod.

daddyjones,
@daddyjones@lemmy.world avatar

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.

scrubbles,
@scrubbles@poptalk.scrubbles.tech avatar

Git flow is the best way.

Lichtblitz, (edited )

The original author of git flow begs to differ. But hindsight is always 20/20 nvie.com/posts/a-successful-git-branching-model/

jjjalljs,

Use semver.

Don’t casually make breaking changes. I don’t care if it’s “easier”.

Write tests

Write good commit messages and release notes.

Every PR to main must be releasable to prod. If you don’t want customers to see it, use a feature flag.

Have a revert plan.

Do code reviews. Don’t just slap “lgtm” on it and approve. Check out the code and run it.

Release often

Have monitors in your environments for errors.

amio,

Versioning. "This version of SharedComponent has this and that functionality" and "this version of OtherComponent requires this specific version of SharedComponent".

If you're getting stuck with significant "this has to come with for that to go" problems - that aren't literal dependencies, but arise from code wonk or poor separation of concerns - you may have some "architecture smell" that could be addressed. Obvious "usual suspects" include things (whether at a single class, component, or entire service level) that have too many responsibilities/purposes/reasons to change, and mismanaged abstraction.

OneCardboardBox, (edited )

Small releases, on a regular cadence.

How do you ensure that you’re not releasing features before they’re ready? Kinda depends on the application, but you might use feature flags. A system for turning features on and off without deploying the application. It could be a Boolean in a redis cache that your app looks for, or a DB entry, or another API. The point is for you to be able to flick a switch to turn it on instantly, and then if if breaks things in prod you can just as easily turn it off again.

And just a word of advice: Consider the performance impact of your feature flag’s implementation. We had a team tank their service’s performance because it was checking hundreds of feature flags in different DBs on every API call. Some kind of in-app caching layer with a short refresh period might help.

eskimofry, (edited )

Nobody has suggested it by name, but semantic versioning.

  1. Software MUST have a public API
  2. Version of software must be defined like this:

X.Y.Z

X is major version number. Increment when introducing Breaking API changes (removal of deprecated API for example).

Y is minor version number, increment when introducing backwards compatible changes like new features.

Z is patch version number, increment when fixing bugs in backwards compatible manner.

Source: semver.org

astrsk,
astrsk avatar

There is also zero versioning which I consider a more practical modern branch of semver.

0ver.org

jeffhykin, (edited )

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.

NeoNachtwaechter,

5 different features onto it, all with different timelines

might be a case for API versioning.

drkt,
@drkt@lemmy.dbzer0.com avatar

heres the binary

heres the zip file with the source code

have fun. if you can make it work, hit me up

Toes,

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,

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.

slazer2au,

Step 9. Write documentation

NeoNachtwaechter,

Step 9. Write documentation

But real programmers never do that. That code was hard to write, so it should be hard to read!

:-)

slazer2au,

You don’t write self documenting code?

indepndnt,

I write self documenting code, as long as you are a Python interpreter.

NeoNachtwaechter, (edited )

You are trying to kill the fun :-)

(maybe you are too young to know the C one liner’s contests?)

JoeKrogan, (edited )
@JoeKrogan@lemmy.world avatar

We have rolling Dev and release branches. Dev is considered stable and is branched off for features they are tested and reviewed and merged back into Dev if they pass. Once all issues are done for the task we merge Dev into release to make a new release then tag it and ship it.

In your case I would do a branch per feature and merge them in only when they are finished and tested, fixing any conflicts and retest it post merge.

RagnarokOnline,

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,
@treechicken@lemmy.world avatar

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

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • asklemmy@lemmy.world
  • DreamBathrooms
  • ngwrru68w68
  • cubers
  • magazineikmin
  • thenastyranch
  • rosin
  • khanakhh
  • InstantRegret
  • Youngstown
  • slotface
  • Durango
  • kavyap
  • mdbf
  • tacticalgear
  • JUstTest
  • osvaldo12
  • normalnudes
  • tester
  • cisconetworking
  • everett
  • GTA5RPClips
  • ethstaker
  • anitta
  • Leos
  • provamag3
  • modclub
  • megavids
  • lostlight
  • All magazines
    •