Answers: <p>Assuming there are no changes in Master that are not in your release branch and you don't rebuild after you merge the code then you could deploy first and then merge to master.  If either of those are not true, then merging first would be more common.  </p>
  
  <p>The process depends on how you handle your branching strategy.  If other things could be merged into master that are not part of the release branch then you need to merge first and rerun the pipeline of tests.  If master represents production and all new work is now in the release branch then yes, you can deploy then push, or do them as a step in the pipeline assuming the deploy is successful then do the merge.  </p>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-18T13:42:47.360Z
Answers: 2018-07-18T13:42:47.360Z
Answers: Rosalind Radcliffe
Body: <p>I am not sure about the best way to deploy my program.<br>
  Lets assume i have two relevant branches release(tested and ready to deploy code) and master.<br>
  I have two options</p>
  
  <p>1.Merge the release to master and deploy master to production.<br>
  2.Deploy release to production and then merge to master.</p>
  
  <p>Which strategy you use and why.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-05-13T17:34:33.050Z
Comments: What does `master` represents (or *should* represent) for you? Why do you merge the `release` branch back into `master`?
Comments: Dan Cornilescu
Comments: CC BY-SA 4.0
Comments: 2018-05-13T18:41:09.937Z
Comments: @AlexanderGorelik Could you add the pros and cons for both options? What are the advantages and disadvantages of both options according to you?
Comments: 030
Comments: CC BY-SA 4.0
Comments: 2018-05-14T07:31:54.797Z
Comments: We are working with git flow. My question is for opinionated pros and cons of the usage in other people systems.
Comments: Alexander Gorelik
Tags: <continuous-integration><deployment><git><continuous-deployment><workflow>
Title: Pros and cons of different deploy strategies
UserDisplayName: Alexander Gorelik
ThreadText: # Pros and cons of different deploy strategies
  
  (Asked by: username_0 on 2018-05-13)
  
  I am not sure about the best way to deploy my program.  
  Lets assume i have two relevant branches release(tested and ready to deploy code) and master.  
  I have two options
  
  1.Merge the release to master and deploy master to production.  
  2.Deploy release to production and then merge to master.
  
  Which strategy you use and why.
  
  **Tags:** continuous-integration, deployment, git, continuous-deployment, workflow
  
  > **Comments:**
  > **username_1**: What does `master` represents (or *should* represent) for you? Why do you merge the `release` branch back into `master`?  
  > **username_2**: @username_0 Could you add the pros and cons for both options? What are the advantages and disadvantages of both options according to you?  
  > **username_0**: We are working with git flow. My question is for opinionated pros and cons of the usage in other people systems.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2018-07-18. Score: 4
  
  Assuming there are no changes in Master that are not in your release branch and you don't rebuild after you merge the code then you could deploy first and then merge to master. If either of those are not true, then merging first would be more common.
  
  The process depends on how you handle your branching strategy. If other things could be merged into master that are not part of the release branch then you need to merge first and rerun the pipeline of tests. If master represents production and all new work is now in the release branch then yes, you can deploy then push, or do them as a step in the pipeline assuming the deploy is successful then do the merge.
  
  
  ---
  
  