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".
Our current process is as follows:
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.
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.
I'm interested in how other development teams deploy and what issues there are with your current process.
Thanks :)
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.
A DevOps Definition of Done is working software collecting telemetry against the intended business objectives.
https://docs.microsoft.com/en-us/azure/devops/learn/what-is-...