Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-09T03:57:13.753Z
Answers: potentially of interest: http://devops.stackexchange.com/questions/268/is-there-a-ci-tool-that-guarantees-no-regressions-in-the-branch-quality-level
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-03-09T03:55:35.387Z
Answers: 2017-03-09T03:55:35.387Z
Answers: Dan Cornilescu
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-09T03:27:14.417Z
Comments: In what sense do you want to re-use the artifacts?
Comments: Dan Cornilescu
Tags: <branch><scm><workflow>
Title: What is the cleanest branching strategy to use when creating reusable artifacts?
UserDisplayName: tayworm
ThreadText: # 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  
  
  ---
  
  