We've been using the Github flow (or some variation of it) in teams of 2-10 people for a few years now. We work on feature branches, merge after code review using the github web UI. Here's a few things that help us:
- 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.
+1 for master always deployable. In teams I've led, I've made it a rule to never commit to master, and sparingly commit to develop.
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.)
To prevent confusion I think it is better to merge feature branches into master and not have a development branch. Master should always be deployable but if you're not practising continuous deployment you can merge into the production branch to do so. This is further detailed in GitLab Flow http://doc.gitlab.com/ee/workflow/gitlab_flow.html
> Enable branch protection for master, so that only pull request that are green on CI and have been reviewed can be merged.
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.
Since recently, yes... But for some reason they decided to make it part of "BitBucket Premium"[1] which is garbage. These are absolutely essential features, and their pricing overhaul hides this behind $3/month/per user. And it also seems that the unlimited users for $200/mo plan is also gone now. So their pricing overhaul has made things more expensive for anyone over 100 users, and more than doubled the price if you want these essential features (merge checks, I understand charging extra for cloud mirroring).
Yeah we have the same approach, but with one difference. Everyone has their own fork of the repo (The reason for this is we had a few avoidable conflict issues).
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.