2

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:

  1. I start working on some feature. I create a feature branch off from dev.
  2. I finish my feature (with 30 commits).
  3. I squash merge my feature into dev - so it becomes just one commit.
  4. The feature is automatically deployed to a testing environment and QA tests out my feature on test data.
  5. 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.
  6. 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: Workflow

Does this all make sense? Is there a better way to achieve this goal? Thanks for your time.

  • 1
    I have added a section about branching strategy. – Esben Skov Pedersen Sep 22 '14 at 11:31
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.

  • I just tried this out today and it went horribly. Cheery picking the features from dev to staging and master went well. But when it came to reverting and merge'ing master into staging and dev, it began to conflict. We have to find another strategy where we'll merge. – Gaui Sep 23 '14 at 18:13
  • Reverting? Why are you reverting? – Esben Skov Pedersen Sep 23 '14 at 20:01
  • Some features don't pass through testing/staging – Gaui Sep 23 '14 at 21:05
  • I'm trying out tagging a feature when it's ready for testing/staging. Gonna see how that works out. – Gaui Sep 23 '14 at 23:36
  • I dont think you can expect to just cherry pick features to deploy except for very simple things. If a feature dont pass testing you just add more commits to dev until it is fixed. – Esben Skov Pedersen Sep 24 '14 at 7:45
0

Because we have to deploy specific features on testing and staging environments, I was thinking about something like:

Two main branches:

  • master
  • dev

    1. Feature branches are branched from dev
    2. When a feature is ready for testing, we add a tag testing/ISSUE-1234
    3. TeamCity notices the tag and deployes to testing environment
    4. When the feature passes testing, we add a tag staging/ISSUE-1234
    5. TeamCity notices the tag and deployes to staging environment
    6. When the feature passes staging, we make a pull request to dev branch and someone reviews code and logic.
    7. If the code review went well, he merges the branch into dev.
    8. On a monthly basis we merge the dev branch into master

How does this sound?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.