I need help with the workflow that is best suitable for our needs. We are a 3-4 person team and are working on 4 different projects.
We have three main branches:
- master – deployable production branch
- staging – features under QA on live data
- dev – features under QA on test data
Then for each feature, we create a feature branch
What we need:
- Sometimes we would like to create a release (for many features that have something in common) and would be deployed in the end of the month.
- Sometimes we would like to deploy a specific feature/change (without creating a release). This is what we do most of the time.
Now to the workflow:
- I start working on some feature. I create a feature branch off from dev.
- I finish my feature (with 30 commits).
- I squash merge my feature into dev – so it becomes just one commit.
- The feature is automatically deployed to a testing environment and QA tests out my feature on test data.
- The feature tested OK, so I cherry-pick my feature commit hash to a staging branch. The feature is automatically deployed to a staging environment and QA tests out my feature on live data.
- The feature passes QA (test and staging) and is either cherry-picked to master or to a release branch, which will be merged with master in the end of the month.
Here’s a picture explaining what I have in mind:
Does this all make sense? Is there a better way to achieve this goal? Thanks for your time.
1
Seems very reasonable. We are using something very similar. My advise is just to keep the feature branches small. Maybe one days work. Longer brances means lower productivity due to a large number of merge conflicts. Mostly one feature branch equals one post it note on our scrum board.
One note is you write “I start working on some feature. I create a feature branch off from dev.” This is a good approach 80% of the times. Remember you have the option to branch of a pending pull request. We have a rule on the team that we should get someone else from the team to review and merge pull requests. Sometimes PRs stay in the queue for a few hours. Since we are using quite small pull requests. Sometimes feature B depends on feature A, but feature A is not going to be merged for a few hours and thus not in dev. When you want to start working on feature B just merge off of A instead of dev. It is better to merge off dev if possible, but it is a good tool in your belt. You should in that case probably wait to create the PR for feature B before feature A is merged to dev because diffs will look like both A+B which is misleading.
5
Because we have to deploy specific features on testing and staging environments, I was thinking about something like:
Two main branches:
- master
-
dev
- Feature branches are branched from dev
- When a feature is ready for testing, we add a tag testing/ISSUE-1234
- TeamCity notices the tag and deployes to testing environment
- When the feature passes testing, we add a tag staging/ISSUE-1234
- TeamCity notices the tag and deployes to staging environment
- When the feature passes staging, we make a pull request to dev branch and someone reviews code and logic.
- If the code review went well, he merges the branch into dev.
- On a monthly basis we merge the dev branch into master
How does this sound?