<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>

CC BY-SA 4.0
2018-07-18T13:42:47.360Z
2018-07-18T13:42:47.360Z
Rosalind Radcliffe
<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>

CC BY-SA 4.0
2018-05-13T17:34:33.050Z
What does `master` represents (or *should* represent) for you? Why do you merge the `release` branch back into `master`?
Dan Cornilescu
CC BY-SA 4.0
2018-05-13T18:41:09.937Z
@AlexanderGorelik Could you add the pros and cons for both options? What are the advantages and disadvantages of both options according to you?
030
CC BY-SA 4.0
2018-05-14T07:31:54.797Z
We are working with git flow. My question is for opinionated pros and cons of the usage in other people systems.
Alexander Gorelik
<continuous-integration><deployment><git><continuous-deployment><workflow>
Pros and cons of different deploy strategies
Alexander Gorelik
# 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**: @AlexanderGorelik 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.


---

