2

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.

  • What does master represents (or should represent) for you? Why do you merge the release branch back into master? – Dan Cornilescu May 13 '18 at 17:34
  • @AlexanderGorelik Could you add the pros and cons for both options? What are the advantages and disadvantages of both options according to you? – 030 May 13 '18 at 18:41
  • We are working with git flow. My question is for opinionated pros and cons of the usage in other people systems. – Alexander Gorelik May 14 '18 at 7:31
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.

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.