I work within a team of four developers, soon to be seven, and it feels like we are at the size where our release process doesn't feel like it's going to "scale".<p>Our current process is as follows:<p>1) Branch off staging to create a "feature branch"
2) Develop on the feature branch
3) Create a Pull Request (via GitHub) between staging and the "feature branch". This automatically creates a throw-away, staging-like environment just for this branch
4) Once the Pull Request has been accepted by another developer, and our Tester has tested the branch, squash and merge into staging.
5) Create a PR between master and staging - as we "squashed and merged" above, every commit on staging was an individual PR.
6) Each day, a developer starts the CI (and therefore deploys/releases) by merging the staging to master PR.<p>The issues we are having:
- We don't currently force the feature branch to be "kept up with staging", as this takes time and organisation. We feel that staging moves "too fast" (We squash and merge around four PRs per day)
- Often Developer A can "knock out" work by Developer B - Especially if the integration of the components has the issue, but unit tests and e2e tests pass.
- We are split into two teams, often Team A does not know what Team B is working on, which increases the potential for merge conflicts, or the issues above.<p>I'm interested in how other development teams deploy and what issues there are with your current process.<p>Thanks :)
We keep master to be the version of the code in production. So any pull request that has to be merged to production is code reviewed, automatically deployed to production via spinnaker in a canary, blue-greened across production, and with splunk and new relic monitoring we know if the code in the PR affects production, and if it fails after 15 minutes in production we rollback the code all the way (back in stg\dev too). One of the key things we leverage is feature flagging and ALL code is behind feature flags using launch darkly...so we do controlled exposure of the code (enabling the feature) for specific users\segments of our population until we enable it for all users.<p>Biggest issue is the delay between code being deployed and enabled in production and users actually using the feature which allows us to get meaningful metrics on the viability of the feature.<p>A DevOps Definition of Done is working software collecting telemetry against the intended business objectives.<p><a href="https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops" rel="nofollow">https://docs.microsoft.com/en-us/azure/devops/learn/what-is-...</a>