This is following on from yesterday when I got a work item to review stage. Today I've found that you can ignore the pull request in git and work entirely within the DevOps interface to move that work item to the next stage in the pipeline.
I hit a problem with the deployment initially as there was an error in the XML for a report layout (duplicate column*). I had to abandon that work item, as I couldn't find a way to move it back through the process, to uncommit the changes and then commit all the files, apart from the troublesome one.
I also made a rookie error - you have to deploy profiles in order for newly created fields to be visible on the profiles you want.
Concepts
Here are the concepts I think you need to be comfortable with in order to be able to work through this process.
The stuff in setup is metadata, which underneath it all is a tree structure of XML files. Without really understanding the ins and outs of XML you need to be able to spot things like - this file defines a new custom field.
The tree structure follows familar concepts like objects, report layout and profiles, as well as more obscure things.
The deployment process is essentially updating those metadata files by copying them from one environment (i.e. Salesforce org) to another.
The pipeline defines the order of environgments that work items move through.
I think the word pull used in the work item and in the pull request doesn't need to be fully understand, but you do need to get this: for the first it's the things that might have changed that you want to include in your work item. For the second, it's the things that have changed that you want to move through the pipeline.
* Surely this must be a bug in Salesforce? If a valid report layout can't be deployed then there must be something wrong with the way the XML is created.
No comments:
Post a Comment