Features are developed in branches and merged into develop. Once we're happy with things, we tag & merge into master. (Junior dev so my approach may not be the best.)
- https://westurner.org/tools/#hubflow
- Src: https://github.com/datasift/gitflow
- Docs: https://datasift.github.io/gitflow/
-- The git branch diagrams (originally from GitFlow) are extremely helpful: https://datasift.github.io/gitflow/IntroducingGitFlow.html
Is that functionality available within Bitbucket + an external CI somehow?
Our workflow involves branching off of master at all time. Staging server can be wiped at any time, we have multiple staging servers. Production code can only rebase with master (or release branch); depending on the client we also have a release server as well which rebases with master and then into production.
Works well so far with team up to 5 developers....haven't tested it out further but wouldn't anticipate too many issues.
[1]: https://bitbucket.org/product/pricing?tab=host-in-the-cloud
But yes, master should always be deployable, and can only be merged once all tests have past (we use Jenkins).. And you are never, ever allowed to merge your own code (no matter how small it is)
- Make a rule that anything that's in master can be deployed by anyone at any time. This will enforce discipline for code review, but also for introducing changes that f.e. require migrations. You'll use feature flags more, split db schema changes into several deployments, make code work with both schema version, etc. All good practices that you'll need anyway when you reach larger scale and run into issues with different versions of code running concurrently during deployments.
- If you're using Github, check out the recently added options for controlling merging. Enable branch protection for master, so that only pull request that are green on CI and have been reviewed can be merged. Enable different dropdown options for the merge button (eg rebase and merge), these are useful for small changes.
- It takes some time to get used to those constraints. Make sure that everyone is on board, and do a regular review of the workflow just as you would review your code. It takes some time to get used to, but I think it's worth it in the long run.