Salesforce DevOps - can you get away without knowing git? - part 2

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.

Salesforce DevOps - can you get away without knowing git? - part 1

Here at Wycliffe we've started looking into Salesforce DevOps Center [sic] and I've been doing some investigations. If you're a dab hand at DevOps in general then this isn't for you. If you've heard of it and want to know more then read on.

This step by step tutorial is a good start. My observation is that, for whatever reason, in the past Salesforce didn't give much attention to the deployment process with Change Requests that were a bit faffy to use. So third parties developed their own tooling, and now Salesforce with their own DevOps Center are trying to catch up with those third parties.

One question I had as I actually started using DevOps Center was whether you needed to understand git, or could you just get by with mostly ignoring it. When you set up DevOps Center you need to associate it with a git repository, so you have to at least interact with github.com. After that though, you can carry on, even though you don't really know what a branch is.

However, when I wanted to put my work item up for review, there was no more escaping:

The rest of my team haven't used git, though one has worked through a tutorial. My challenge is to try and lead them through the process and see if we can get by with understanding just the bare minimum of how git works. I'll write more posts about that as I explore.

Bonus link via Julia Evans, why Git is hard.