3 ms·
Not that I know: if you needed a "staging" for each of the feature branches, the complexity and cost grew, but problems remained (i.e. merging trunk and a branc
by necovek 6y ago
Not that I know: if you needed a "staging" for each of the feature branches, the complexity and cost grew, but problems remained (i.e. merging trunk and a branch back and forth).
For the last 15 years I've been at teams using a "staging", it was simply a single production-like environment (well, my first project was exactly like production on slightly less beefy hardware with sanitized production DB import nightly) that gets the "trunk" (or "main") deployed to automatically (on my current team, it can be used to run non-production code as part of the deployment process which you bail out of).
I am pretty sure there is no one true definition of staging, so it's a spectrum rather than an exact way to do things.
- mnsc 6y agoI'm talking about the prehistoric time before git and feature branches. Where all the developers hacked away for months on That New Feature and all code just went into trunk, cause that's where the development is. Back then staging was invaluable to get the confidence to do that (bi?)annual major release.
- necovek 6y agoSure, that's the time we learned why feature branches and not releasing often sucks :) And yes, you sometimes had "staging" track your trunk, when you would be missing a staging environment for production where you'd want to test critical fixes, so ultimately, you needed both then.