forcedotcom / devops-center-feedback

61 stars 2 forks source link

Should and how do we seed GitHub? #205

Closed matthewpomar closed 1 year ago

matthewpomar commented 2 years ago

Hi,

We have implemented DevOps Center following the pipeline example in the setup guide.

One thing we immediately notice is all changes are new changes being pushed through to the different branches and ultimately the main branch in GitHub.

It would seem ideally that every branch, including main, would be fully populated with the current metadata found in their respective orgs. For example, when I'm looking at the main branch, it is essentially a blank SFDX project but I would expect to see all the metadata that exists in our production org.

So my questions are:

  1. Should we seed/back-fill all of the branches, including main in GitHub with the current metadata from their respective orgs?
  2. If the answer to the first question is yes, then how should we go about doing this?
  3. What is the recommended list of metadata types that would should back-fill into GitHub?

Bonus Question: When we promote items from one pipeline stage to the next, it keeps asking if we should include only items that changed in the target org or all items in the target. For example, if we are going from Integration to UAT, then it is asking if we should deploy all items changed in UAT (not Integration) vs All items in UAT. Maybe my memory is not right, but I believe this is what it's asking. Also, what is the difference between those two options?

Thank you.

kfidelak94 commented 2 years ago

Hi @matthewpomar

We currently are not seeding the repository with all the metadata from your production org. We're considering adding this capability in the future, but for now we're only adding changed components to the repository. If you do want to have all the metadata in the repo, you could retrieve the metadata out of the org yourself outside of DevOps Center (ie using the Metadata API or VS Code) to populate the main branch before the pipeline is set up in DevOps Center, and then if you let DevOps Center create the other branches it will clone from that populated branch. Alternatively you can populate all the branches yourself.

For the bonus question: When we do a promotion, we know which work items are in the promotion, and we know the metadata that is part of each work item. Also when we do a promotion, we first merge the branch from the source stage (ie Integration) into the target stage's (ie UAT) branch. Then we deploy from the target/UAT branch into the target/UAT org. In the case of the "Changes not in UAT" option, we will only deploy the metadata components that are part of the work items being promoted. In the case of the "All metadata in the UAT stage's branch", we will do just that - we will deploy everything in the UAT branch. In general, the "Changes not in UAT" option (default) should be sufficient for work items and metadata being managed by DevOps Center, and the deploy will be faster. If on the other hand, for example, you have cases where metadata is coming into the branch from processes that DevOps Center doesn't know about and you need that deployed you could use the "All metadata..." option to ensure that was deployed. Or, if you need some metadata redeployed that is not part of the work items being promoted, you could use this option.

Hope this helps. Let us know if you need more clarification.

GilsonCanario commented 1 year ago

Related to #36