In the setting up continuous integration and deployment document you have given, when would the changes flow across master branch of different repositories?

[Beth Starr]

Hi,

In the setting up continuous integration and deployment document, you had given that the changes in code would move from SharedDev/master repo to UAT/master repo and from UAT/master to Prod/master repo.

Also considering the same deployment workflow which you have stated in the document.

Say, when the user commits Issue-1 and Issue-2 to SharedDev/master and both moves to UAT/master for testing. Issue-1 has passed and it is ready to be moved to Prod whereas Issue-2 testing is still not yet completed. At this point, if the UAT/master branch is going to be merged with Prod/master branch commits of both Issue-1 and Issue-2 will go to Prod/master branch. But this should not happen because Issue-2 is not yet Prod ready. How do we solve this scenario?

[Adam]

There a couple strategies. First I'd make sure that you are testing your features/issues individually as much as possible so that the only thing stopping them from being prod-ready once integrated is if the integration itself causes problems. Second, you could either treat UAT as a step on the way to Prod, or as a separate path for early integration testing. In the former scenario you solve the problem by either fixing issue 2 to become prod-ready, or you revert the changes from issue 2 until they are ready to ship (there is a git command specifically to revert changes from certain commits). In the second scenario, UAT is a dead-end which can be deleted and recreated at any time. You merge everything there for testing early, then you separately merge your feature/issue branches to master once they check out on UAT. You probably still want to do some integration testing on master before shipping, but most of the problems would have been found already.

[Adam]

I looked for the document I think you're referring to. Is it https://developer.atlassian.com/plugins/servlet/mobile#content/view/30605731? I know less about Salesforce, but my suggestions should hold true for general Git development.

[Beth Starr]

Thanks Adam for your prompt reply.But our scenario is that we cannot wait for issue-1 to be moved to Prod until issue-2 is fixed. Anyways, I am thinking to do this way, by creating separate feature branches for each issue and merging them separately to UAT repo and Prod repo. In this case, I need not wait for other tickets to be fixed. Now my question is that is it a best practice to create separate feature branch for each ticket in JIRA?