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.

What gardening and IT projects have in common

I reckon I have one good blog post in me, and one good comedy sketch. I'll do the sketch another time, but this is the blog post. I've retrieved it from Medium as I like to own my own content.

I’ve been thinking about the way people adopt new IT systems and I think a good analogy is gardening. There’s no one right way to do gardening and it’s the same with rolling out IT systems. Here are four approaches that I’ve noticed:

Landscape gardening

This is the classic approach. You draw up a plan, you involve the stakeholders, you survey the land, and then you start the doing. You clear the land, maybe retaining some existing features. You mark the boundaries, move the rubbish, and then start planting. After a period of time you hand over the garden to the owners, maybe with some instructions on future care.

Cultivating a plot

This is on a smaller scale than a whole garden. You define strict boundaries, and you may only be growing one thing. It only involves a limited number of resources and shouldn’t take you that long.

Survival of the fittest

You scatter some seeds where you think they might grow. They may not, but if that’s how it is then you don’t really mind. There is the chance that it takes off and if so you’ll be judged a success (so long as people know you did the work).

Guerilla gardening

You aren’t part of the mainstream, but you like to see things growing. You introduce strong young plants that will grow quickly and expect to see them do well. They may not, but you will have moved on by then.

Tortured analogy?

In case my analogy is too abstract, here’s how I see examples of these. A CRM implementation is landscape gardening. Everyone needs to be on board, it all needs to change at an appropriate pace, even if it’s not all at once. You can’t have a CRM that’s only used by one department and others do their own thing.

For something smaller, such as getting people to use Google Docs, or Slack, you work with a small team. You may not ask them to do everything the new way, there may be a place for Microsoft Word, but for some teams and some processes Google Docs is the way to go.

For an even more small scale approach you might start using Doodle to arrange meetings. Some people may not like it. Who cares? If it doesn’t catch on then it’s not worth trying too hard, it should just be left to die.

Sometimes technology gets implemented without IT being involved. A courageous few go ahead and try something out. This is the riskiest of all. It may create yet another place where data lives on its own, unconnected to the rest of the organisation. It may be illegal, or insecure. However it’s worth asking why it had to be done without involving IT.

Technology first?

You could argue that this is a adopting a technology first, solution-led approach, rather than using a problem led approach. Sometimes this may be what you’re presented with. “I’d like to use technology X”, says the boss. “Let’s try it on a small scale”, you say, “maybe just involving you and the other bosses at your level”. Or “let’s just put it out there and see if it takes off”.

It’s also an approach to use once the problem is defined. Rather than “let’s improve collaboration across the organisation by using Slack”, why not, “let’s try Slack with this particular team to see if it fits our culture”. That team could become enthusiastic promoters if you decide to use the Landscape Gardening approach.

J-Cuts and presentations - using a film technique

I don't know. I do one presentation and all of a sudden I'm an expert.

A J-cut is a film technique where the sound from the next shot starts before the picture does. You can find more about this at Adobe's website.

It's also a technique that you can use when doing presentations. I find myself (probably like many people) going to the next slide without really knowing for sure what it contains, and then start talking about it when it comes up. Doing a J-cut style transition would mean that you start talking about the next slide and then move ahead to it. This can be effective because the attention will be on what you're saying (as it's moved on from what the slide on display is about) and then the slide reinforces it. The danger with going to the next slide and then talking is that the attention goes to the new information on the slide (particularly if it's got lots of words), and not what you're saying.

In order to do it well you either need to remember what the next slide is, have good notes, or be using presenter view.

Why not give it a go and let me know how it goes?

I did a presentation and I liked it

 

Last night I did a presentation at Russell Davies' inaugural presentation club. 

You can attend just to see what it's like, in case you might like to try presenting one day. Or just to be supportive. Or to learn from other people doing presentations. We definitely need an audience so please come along. You will be invited to offer feedback to the presenters but your feedback must start with the words "what I really liked about your presentation was...". In my experience people are hugely aware of their failings, they don't need them pointing out, we are there to point out their successings.

It was a 5 minute talk, a cut down and revamped version of a presentation I did to some of our marketing team. I'd recommend anyone who ever does presentations to give it a go next time (7pm GMT 3 December 2025) because:

• It only needs to be 5 to 10 minutes
• You can talk about what you like
• You get positive feedback at the end
• You can focus on just doing a good job and not just pursuading/educating/impressing people or whatever's going on with other presentations

Russell Davies literally wrote the book on Powerpoint but don't let that put you off. Here's what he said about last night.

Vibe coding with Gemini - and a childhood dream fulfilled

As a followup to my post on vibe coding in Salesforce, here's what happened with Gemini.

First let me take you back to my ZX80/81/Spectrum programming days. I created a little game where you would drop blocks into a 2d pyramid shape. If a block fell outside that shape then it was Game Over. The graphics on those machines were addressable in 8 pixel squares so it wasn't very realistic. I thought it would be a lot better if the blocks had proper physics. I didn't have the words for it at the time, but what I needed to do was create a physics engine. That seemed like a full time job, and programming was just a hobby in those days.

I gave Gemini this prompt to create the game I'd imagined in my childhood:

Create a browser game where there's a block at the top which regularly moves from left to right. When you press the space bar that block should drop another blog down to the ground below. The blocks should have proper physics and collision and tumble over each other.

It understood what I meant pretty well. I didn't give it a Game Over condition, but it invented one of its own - if the blocks filled up to the top of the screen then that was it. As it was, that was pretty much a good starting point. I spent a few iterations trying to get it to not trigger game over as soon as a block fell (because it was at the top of the screen).

At this point my impression switched from "this is amazing - look how complete a thing it can generate with a few words" to "why doesn't it understand what I'm saying?". 

It did work eventually though, so I moved onto Phase 2 - the pyramid shape. Again it took a few iterations before I could get the shape I wanted - at first it did it upside down. Once I got the shape I wanted I added a game over/high score screen at the end and that was my minimum viable product. 

It's got a cheery manner, as AIs seem to these days. 

Here it is. Can you beat my high score of 26? Be warned - it's got a really annoying soundtrack and collision noises, but you can mute it.

Update: There's a sparkly option on the screen when creating these things, and I clicked on it. Straight away it decided to add an AI feature; specifically, a little autogenerated summary of your game on the game over screen. It would have been nice to have been asked, but I let it do its thing.

My first impressions of Salesforce Vibe Coding

 I spotted a new icon on the Salesforce setup menu, so I decided to give it a go. It's a full web-based VS code IDE.

As it happened I had a specific Lightning Web Component that needed to be created, so I prompted with that. I have to say, it's very impressive. It doesn't just generate a load of code, it knows about how the whole deployment process works. It has a plan mode, so you can clarify things before you put it into "act" mode. It asked me clarification questions

It asked me nine questions in all, so I answered one, expecting it to then say "what about the second question" but it went through the whole cycle again. So I gave it several answers in one go.

The process of identifying the target org it should deploy to wasn't obvious or straightforward, even though it was thinking out loud about how to get that information. I didn't know how to tell it though.

In the end I told it "set username to name@company.com" and then it put that into configuration as expected. When I later tried to get it to use a sandbox it default to login.salesforce.com

I got an error "provider context length exceeded". When I asked for help with solving it, I just got the same error. I gave up for the day, came back the next day, and it was OK. I guess it just needed a nice cup of tea and a sit down.

It asks permission nicely before it does things or creates files, so you can follow along, rather than just waiting until it's finished and you have to dig around to find out what it's actually done.

Bear in mind, I didn't look at any of the available help information, I was just ploughing on. 

I got as far as deploying the component, which then failed because of lack of org wide test coverage. It then offered me four different options. I went with running only tests related to the change. The deployment then failed because of 0% coverage on the test class. It suggested that it could write some code to cover that. I wouldn't have minded if it did that without asking, but I went ahead and asked nicely anyway. It churned away, trying deployments, adding code to set default values. All the while it was thinking out loud:

I see the issue now. The problem is that we're trying to create a User with a ContactId, but the org requires that users who are associated with contacts must be portal users. Let me modify the test class to handle this by creating a regular user without associating it to a contact, or by using a different approach for the test setup.

 In the end, after several iterations, it managed to deploy the component:

Conclusions

How you view this depends on what your knowledge is.

If you don't really know about Apex programming then there's probably too much that you need to know to get anywhere (e.g. test coverage, local vs org tests).

If, like me, you've dabbled a bit, you know about deployment and Salesforce dx, then it will get you a long way towards getting something that basically works. You can then actually read the help information and increase your skills.

If you do this sort of thing all the time I imagine that it will take a lot of the drudge work of setting up new projects and creating outline code which does most of what you want. You can then go in and use your l33t skillz to finish the code off.

Why I went for a #clicksnotcode Salesforce certification

When I started working for my recent Platform App Builder certification (have I mentioned that recently?) I initially was heading towards the Platform Developer cert, which includes writing Apex code. We don't have much Apex code in our current org, and have only modified it a couple of times in minor ways. So I wouldn't be using the code writing skills that I gained in order to get it, and they'd get rusty. Given my years of experience writing code in other languages (and the Apex I wrote in 2017 for our switch from Raiser's Edge to Salesforce) I think I could pick it up if required.

It strikes me though, that the whole development process with, say, a Flow is very much like the process if you're writing Apex. So typically you:

1. Talk to the people who want the enhancement or bug fix (let's assume it's a fix)
2. Work out how to fix it
3. Work out how to test that fix
4. Fix it
5. Test it
6. User acceptance testing
7. Documentation/training
8. Release

So step 4 is different between Flow writing and Apex coding, but everything else is very similar. Have I over-simplified everything, or is there something substantially different to coding compared to creating a Flow?