Praise where I can - Google docs sensible toolbar hiding

I've recently come across Marcin Wichary's Unsung blog, and I'm enjoying it a lot. It's about "software craft and quality", and I find pretty much everything he posts really interesting. Some of it is about retrocomputing, which often piques my interest. I plan to blog about some of those things at some point. I thought I'd take inspiration from the blog and post about some good UI work rather than just moaning about ^h^h^h^h^h^h^h^h^h^h^h^h^h highlighting failures^h^h^h^h^h^h^h^h areas for improvement. (Of which, there will be several I suspect, once I get started.)

I use Chrome's vertical tab feature, and it's very useful. However, at the width my screen is the full Google docs toolbar can't be seen. Rather than just show as much as it can, and hide the rest behind a "3 dots" menu, it hides all the related icons and displays them all in one go. This means that I don't have to hunt along the toolbar to see if the one I want to use is visible or not - I know that everything to do with paragraph formatting is behind the three dots. 

Salesforce DevOps - knowing a bit of git helps

Nearly two and a half years ago I wrote Salesforce DevOps - can you get away without knowing git? I could give you the answer to the question without you reading it, but that's a bit boring.

After having used it for all that time I've found out that knowing a bit of git helps.

Here's what I've found by digging around behind the scenes about how DevOps uses git.

DevOps/git doesn't store all your metadata

I'm assuming you know what metadata is. If you don't, roughly it's the way that all that stuff in setup - (custom objects, fields, flows etc.) is stored - in text files, in XML format. However when you hook up an org to your DevOps project it doesn't suck all that out. Instead, when you make a change in a WorkItem, for something that isn't in Git then at that point it takes the whole file for the change you made and puts it in git.

So for example, each field has it's own file. Say you created an imaginary field on contact called Unicorn. The metadata for that will live in a file in the code tree: force-app/main/default/objects/Contact/fields/Unicorn__c.field-meta.xml

It looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<CustomField xmlns="http://soap.sforce.com/2006/04/metadata">

    <fullName>Unicorn__c</fullName>

    <description>How many unicorns this contact owns</description>

    <externalId>false</externalId>

    <label>No. of unicorns</label>

    <precision>3</precision>

    <required>false</required>

    <scale>0</scale>

    <trackFeedHistory>false</trackFeedHistory>

    <trackHistory>false</trackHistory>

    <type>Number</type>

    <unique>false</unique>

</CustomField>

As the Work Item (WI) moves through the lifecycle, say, being promoted from a dev sandbox to a testing one, and then to production, that file will move through git - more on that later.

If you make a change to that field, say you wanted to change the label from "No. of unicorns" to "Number of unicorns", then that change will move through git as a single line change to that file:

- <label>No. of unicorns</label>
+ <label>Number of unicorns</label>

When git gets out of step with the metadata

If you don't do everything through DevOps then all this stuff behind the scenes is worth knowing, as it explains the errors you get. Say you edit a picklist in production, and then refresh a dev sandbox from production. If you then edit the picklist in the dev Sandbox and try and promote it to a testing sandbox you may get an error. Here's what's going on:

Say the picklist had 3 values

1

2

3

Then in production you add 4 to the bottom. When you refresh the dev sandbox to production, the metadata in the sandbox has this

1

2

3

4

However git only has

1

2

3

Say in the sandbox you added 5 to the list. When taking the change and putting it in a commit it compares the metadata in the sandbox to git and concludes there are two new lines: 4 and 5.

Then when you promote the WI to a testing sandbox git wants to add two lines to the picklist in the sandbox, 4 and 5, but the testing sandbox already has 5 in the list, so it looks like a duplicate, and fails to deploy.

Branches and work items

The way that Work Items move through git is fairly straightforward.

Each Work Item is a branch. Each sandbox to the right of the dev sandboxes is a branch, for example, Integration or UAT sandboxes. Production is the branch main.

Promoting a WI from a dev sandbox to a testing sandbox is a pull request, e.g. Merge WI-000344 to UAT. The final promotion to production is just a merge to main.

Combining Work Items

Sometimes DevOps will want to combine two or more work items which involve the same areas (e.g. the Contact layout). I find that this generally works OK, and the combined work item deploys without any problems. Knowing about git though helps you understand what's going on. If two WIs which are ready to promote to production involve the same file then DevOps will want to combine them at this point into a single WI. Behind the scenes it puts the commits from the WI that's being merged from into the WI that's being combined to. Then you can promote the combined WI to production.

Questions?

Do you have any questions about how git and DevOps are working together? I can answer in future posts.