<p>The simplest/cleanest branch strategy is IMHO the one used in <strong>continuous deployment</strong>: a single/main integration branch which is also your release branch. From <a href="http://paulhammant.com/2013/12/04/what_is_your_branching_model/" rel="noreferrer">What is Your Branching Model?</a>:</p>

<blockquote>
  <p><a href="https://i.sstatic.net/YKaMq.png" rel="noreferrer"><img src="https://i.sstatic.net/YKaMq.png" alt="enter image description here"></a></p>
  
  <p>Commits can go all the way to production from one trunk/master, if the
  automated build says the commit was good. It’s the turbo-switch for
  TBD, where no humans can hold up a release by taking their sweet time
  testing it and giving a belated seal of approval. Github, Etsy,
  Netflix (and many more startups) are all here.</p>
</blockquote>

<p>You'll effectively use the CI build artifacts from that main branch across all environments. Well, as long they build and pass the respective QA verifications, obviously.</p>

<p><strong>Note:</strong> there are no feature branches in this strategy, at least not long-lived ones - in order to eliminate/minimize the integration delays and costs. Practically you can eliminate branch merges from your development.</p>

CC BY-SA 3.0
2017-03-09T03:57:13.753Z
potentially of interest: http://devops.stackexchange.com/questions/268/is-there-a-ci-tool-that-guarantees-no-regressions-in-the-branch-quality-level
Dan Cornilescu
CC BY-SA 3.0
2017-03-09T03:55:35.387Z
2017-03-09T03:55:35.387Z
Dan Cornilescu
<p>If I have 3 environments : integration, staging, and production, what is the cleanest branching strategy to use, assuming I want to reuse my deployed artifact?</p>

<p>For example, should feature branches be merged into master and then built to be deployed to integration? Or is there another strategy that allows you to have 1-to-1 mapping between your releases and SCM?</p>

<p>Some more details ... Say I merge into master, and that kicks off a build, which produces an artifact. That same artifact should be deployed to all environments to ensure consistency. Is it best to start that process with integration? In that case, there is a rather large potential window where untested code is in master before verification can occur. Is it better to use an integration branch, deploy that to integration, then merge to master and use that artifact for staging and production? Or does that just increase the need for duplicate testing?</p>

CC BY-SA 3.0
2017-03-09T03:27:14.417Z
In what sense do you want to re-use the artifacts?
Dan Cornilescu
<branch><scm><workflow>
What is the cleanest branching strategy to use when creating reusable artifacts?
tayworm
# What is the cleanest branching strategy to use when creating reusable artifacts?

(Asked by: username_0 on 2017-03-09)

If I have 3 environments : integration, staging, and production, what is the cleanest branching strategy to use, assuming I want to reuse my deployed artifact?

For example, should feature branches be merged into master and then built to be deployed to integration? Or is there another strategy that allows you to have 1-to-1 mapping between your releases and SCM?

Some more details ... Say I merge into master, and that kicks off a build, which produces an artifact. That same artifact should be deployed to all environments to ensure consistency. Is it best to start that process with integration? In that case, there is a rather large potential window where untested code is in master before verification can occur. Is it better to use an integration branch, deploy that to integration, then merge to master and use that artifact for staging and production? Or does that just increase the need for duplicate testing?

**Tags:** branch, scm, workflow

> **Comments:**
> **username_1**: In what sense do you want to re-use the artifacts?  

---

## 1 answers

### Answer by username_1 on 2017-03-09. Score: 6 | Accepted answer

The simplest/cleanest branch strategy is IMHO the one used in **continuous deployment**: a single/main integration branch which is also your release branch. From [What is Your Branching Model?](http://paulhammant.com/2013/12/04/what_is_your_branching_model/):

> [![enter image description here](https://i.sstatic.net/YKaMq.png)](https://i.sstatic.net/YKaMq.png)
>
> Commits can go all the way to production from one trunk/master, if the
> automated build says the commit was good. It’s the turbo-switch for
> TBD, where no humans can hold up a release by taking their sweet time
> testing it and giving a belated seal of approval. Github, Etsy,
> Netflix (and many more startups) are all here.

You'll effectively use the CI build artifacts from that main branch across all environments. Well, as long they build and pass the respective QA verifications, obviously.

**Note:** there are no feature branches in this strategy, at least not long-lived ones - in order to eliminate/minimize the integration delays and costs. Practically you can eliminate branch merges from your development.

> **Comments:**
> **username_1**: potentially of interest: http://devops.stackexchange.com/questions/268/is-there-a-ci-tool-that-guarantees-no-regressions-in-the-branch-quality-level  

---

