Description
Struggling to introduce version control to your Salesforce team? Eric Kenney (Support Consultant at SaaScend) shares his journey from discovering Git through DevOps Launchpad to implementing it successfully. Gain actionable advice, learn about the real impacts of effective version control, and get inspired to start your own DevOps journey today.
Learn more with these resources:
Transcript
Wonderful. Thank you so much. I'm really happy to be here and, yeah, and share with share with you all my experience of getting started with Git, getting started in a in an org that wasn't using it, and how we transform our deployment and DevOps cycle.
So quick quick note about me. Some of you may know me. I've been around in the Salesforce world for, oh, going on almost fifteen years now.
Twelve years, I think.
I have been in the nonprofit sector. I've been in the education sector.
And then a couple years ago, I moved into the consulting side of things. And presently, I'm at a company based in the United Kingdom called SUSCEND.
And everything that I'm gonna talk about doesn't isn't involved with SUSCEND. This is stuff that happened at a previous organization.
So, you know, you know, just that that just that that goes from there.
Okay. So let's get started.
First off, let's talk about the problem.
And I'm sure as admins, you have experienced this every time you've ever done a deployment, especially if you have multiple individual contributors, multiple developers who are working on on your environment.
You're you've got a series of sandboxes, and you have to get the changes from each of those sandboxes into production. Well, what that means is creating change sets that go from sandbox to sandbox, pushing things upstream from developer sandbox to partial to full to prod. You have overlapping chain sets. Maybe one of your ICs did something in one box. You had an another IC did something similar in another box, and you have to push those, and you have to merge those things.
But as you know, as you work with chain sets for the most part and development like that, there's no visibility. You don't understand what's been changed unless your unless your ICs are keeping meticulous notes as to what records were or what metadata was changed, flows, page lights, whatever, you have really no good visibility.
And then this is a particular problem, especially for your newer admins, is understanding cascading metadata changes.
So you got a new pick list value. Well, new pick list values affect record pay record record types. So you gotta think, okay. So now that I've got a new pick list or a new pick list value, I've also gotta deploy record record types to that particular object.
So if you don't think to include those, you're gonna miss out on that. You're gonna have to update that information manually.
At the at the at the organization that I worked at, before we introduced Git, we basically took Thursday afternoon after lunch, and that was our deployment time. And it took between four and six hours every two weeks.
It was just kind of a slog. We just blocked out Thursday. We did Thursday, so that way if anything went wrong, because it did, we had Friday to be able to roll back changes, to update things, and it was always error prone. We were always rolling back something.
You know? It was we never had a hundred percent deployment any given spread. We always had maybe seventy five, maybe eighty if we were lucky.
But incorporated with that, and this is also going back to the overlapping changes and no visibility, is it was always manual fixes that had to be done upstream. So you have two things that are that are different in different sandboxes. You need those to be merged together, well, now you're going into full or partial, whatever your lower your your second tier sandbox is, and you're having to update that information manually in those so it can be pushed into prod.
And, you know, as I said, so we had, like, huge, huge time spent every two weeks to be able to do deployment cycles. And sometimes we couldn't get something deployed because because of the complexity that we knew that we weren't gonna be able to do it on a particular regular cadence. So that meant pushing it out a week. So we deployed it on a off week cycle, frequent rollouts.
You know, Thursday was just one of those days that everybody in my team hated because it just, you know, it's just like this tedium of deployment that happened, after lunch.
So I come into this organization with some experience using Git.
At my preview at my previous job, I had kind of started to learn SFDX and Git, but I was a solo developer or or a solo admin. So I didn't have anyone else to compete with, so I wasn't really getting the full experience of what that meant.
But, you know, this was all new to me. This whole concept of Git and command line and everything with SFDX and the Salesforce CLI, all of this was new to me. There was all of this jargon. All of this developer jargon.
I'm not a developer. I'm an admin. Like, give me a point and click, and I'll be very happy. Don't ask me to write Apex.
I'm not a developer. And learning Git was like learning a new language.
I first started with blogs. I went to help. I did Trailhead. I used Salesforce Saturday, all these different things to kind of understand what this was.
You know, I'm getting these terms like pipeline and branch and CID CICD and and DevOps life cycles, and I'm just like, I don't I don't know what any of this means. All of these terms are just, like, foreign language to me.
In all honesty, you could probably get me to answer what a like an Apex class is and inherent sharing is before I would understand what any of this meant because at least those are concepts that I were familiar with.
And I'm sure as an admin, if I say these things to you, if you've never experienced Git, you're like, I don't know what that is. A pipeline that feeds water, branches what comes off of trees, c I c d. That's just nonsense. So so, you know, so what is what is an admin to do?
So I first discovered Gearset and the DevOps Launchpad probably on LinkedIn. Maybe it was an email from Gearset. This was back when it first launches. I think I think it was twenty twenty two, twenty twenty three maybe.
And I went over. I went on to the dev DevOps Launchpad, and I discovered that this was very familiar to me. It felt like I was going on to Trailhead. It was very user interaction, like, step by step modules. And one of the things that I found so disconcerting about, particularly Trailhead and getting started, is because of all these these terminology, there was some level of knowledge that I felt was expected of me to be able to go through some of those DevOps processes, the SFDX stuff in Trailhead. Well, the Launchpad actually helped me get over that because there's some foundational modules that are in this platform that helped me understand what the term pipeline, CICD, and and branching and, you know, a a a branching strategy and all these terms that were being thrown around that I didn't have any idea of, they gave me that confidence to be able to understand that.
But the great thing about DevOps Launchpad, we didn't use Gearset. I've actually only just started using Gearset most very recently.
The great thing about it is it is vendor neutral. So anybody using any DevOps process out there, who wants to get started can start on this platform.
So how do you get started?
There's a couple of sort of housekeeping things that you need to be able to do before you start the process.
So in your production org, you wanna enable Dev Hub. So you just go into setup, find Dev Hub, turn on the settings. So There's a couple of different things. You just wanna enable Dev Hub, and then you want to enable unlock second generation managed packages. And I think there's a third option that allows you to use source tracking in sandbox in your developer sandboxes. So you wanna turn that on.
You can use Scratchworks. That's fine.
Most of my team at the time was comfortable working in developer sandboxes.
Most most people still are. So you want to enable that because that allows you to to have that environment without having to create a new scratch org.
Once you get this set up, you want to create or refresh all of your developer sandboxes.
The source tracking that is available in the dev hub and as part of this process is only available in those developer sandboxes. It isn't available as you move up the pipeline with partial, full, the developer pro. I don't think it's a developer pro. So it's like as you get further up in those those bigger, more robust sandbox environments, the source tracking is only available in the lower one. But the great thing is is that's all you need. Because once you get it, once you start the process, you work entirely in that lowest level sandbox, in those developer sandboxes.
Then you wanna set up your Git project. Now setting up your Git project, that's something that's gonna go through as you go through the DevOps law the DevOps launch pad, that's something that's gonna show you how to do that. It's gonna show you how to set up Git on your computer. It's gonna show you how to set up SFDX and or not SFDX, Versus Code and and your Git repo and all of those things.
So I'm not gonna go into that. That's that's the, you know, the the tools that are available to you to help you get started.
After you've got your project set up, you wanna get your metadata from your org into your Git repo so you can start tracking those changes.
Now the key thing here is start small. You do not have to start with everything in your org. You don't have to pull in every object, every report, every Apex class, every flow, every you don't have to do all of that stuff. Start with a few items.
A few items that you regularly update. Maybe your account object, maybe your contact object, maybe a couple of flows that are are being worked on, that you're working on a couple of new flows or you know that are going to be updated. You know, page page layouts, lightning record pages, something like that. Start small.
Because once you get it set up, you could always add more later.
In three sprints from now or next quarter, now all of sudden you have a big project where you're working with cases and you've got a new custom object and you have all this stuff that goes along, great.
You don't have to worry about that now. He's not working on that. But, you know, you can pull that in later at another point, and and the Git repo will maintain that history and that tracking to be able to show you how things have changed.
What this does is this establishes a baseline. This is basically like, we're gonna start tracking our changes, doing source, source driven development from this point. So everything that has changed from this point gets tracked, and it's little things like adding a field to a layout, renaming renaming a value in a pick list, you know, renaming a a pick list value, adding a custom label, creating a new flow, updating a flow. Anything like that, it'll show those changes. And the the Git repo will actually anytime anything changes, it'll keep a track of that as part of the history.
So you'll go in, you'll update a flow, you'll make the changes, you'll commit all that to your Git repo, upload it to your master branch. And then the next time you make a change to that flow, it'll know all of those changes. And the next time you work on it, it'll have those changes incorporated, and it'll show the difference from the last time it was modified modified.
And as I said, add metadata as you need it. Don't worry about getting everything all at once. Just start with what you need right now.
Think about your Git branching strategy.
Again, all this terminology will make sense once you go through the DevOps launch pad. I promise, like, I'm not speaking a foreign language.
Yeah. One of the one of the best ways, especially if you have multiple people in your team, you probably wanna think of something like a master deployment development branching strategy. Basically, you have your master branch, which is essentially pro your production environment, your deployment branch, which is essentially your full or partial sandbox depending on what you have available to you, and then your development is what you're working on in your developer sandboxes. We use Jira.
There's also an integration with Asana. I'm sure there is with various other ticketing systems. Basically, anytime we had a Jira ticket that came in, we created a branch off of that from our master branch, which was production, and then we tracked all of those changes against that, and then we merged that up into our upstream just like as if we were merging our changes. So we're doing two things separately, which is the Git side of things and the DevOps cycle inside of Salesforce, and where those are working in concurrent. And one is basically logging the changes that the other one is doing.
So some results. So after I turned my team onto this, they went through the DevOps Launchpad.
We went from four hours to twenty minutes.
We had nearly one hundred percent accuracy every sprint, and we almost eliminated any of those manual changes that you have to do because Git manages all of those conflicts. So that's one of the advantages that it keeps track of the different versions. And when you try to move merge two different versions of the same thing, Git goes, nope. Can't do this because these two things are identical, and they're diff like, they're two diff they're identical fields, but the changes in them are different.
And I can't I don't know what to do with that. So it'll give you the option to, you know, merge the changes together, to delete changes, you know, and it'll give you some options, like, on the screen where you can go in and kind of, like, update the code, the code. And the code that is that Git uses and the metadata uses are XML files. So it's very, very easy to read.
So XML is similar to HTML. It's just basically like like, it just has a tag, and it says flow, name of the flow, you know, closed hash flat, flow.
And it's, you know, status, active, you know, assign value, give you a value. So it's really, really easy to use. You don't have to know Java's you don't have to know Java or JavaScript or Apex or any of that stuff. If you can if you can parse through fairly weird looking text, but it's fairly easy to read, you can read the XML files that are created as part of this DevOps process.
And the Git will just show you those those changes. It'll be like, you know, this these brackets that are the same on this flow show two different values. How do you want me to update them? And maybe you might have to go into your maybe it's two different assigns or something like that.
You have to go into your your thing, and you have to fix it, but that's not very common.
So that's one of the great things. But, yeah, like, the fact that we went from four hours to twenty minutes, basically, deployment was a breeze. We would do it at four o'clock on Thursday.
The longest I think it ever took us was an hour and twenty minutes because we had some we had some missing metadata when we were deploying. But for the most part, it was fifteen to twenty minutes. We were done, and then we usually took the rest of the afternoon off because it was it was super easy.
But why would you do this? Well, the biggest thing is you've got some really key things. Tracking. The with source tracking, you can see all of those changes.
All of the every change in every box gets recorded against the Git repo. You have a history of what has changed. So if something breaks in a week and you're like, oh, crap. It's this flow that we deployed.
Something happened with this flow. You could always go back. You can always roll back to a previous version. You go into your Git repo.
You pull in that commit of the one previous, deploy it to prod, takes all of five minutes. You've got that that version that older version in your in your environment rolled back.
Rollbacks are, fairly easy, but they're also not common. They're all well, they weren't common for us. They hopefully aren't common for you as well, but they're, you know, they're they're easy to do.
Speed, four hours versus twenty minutes.
And one of the better things is is collaboration. So every one of your your admins and your individual contributors can have their own environment. They can work, independent of each other.
You don't have to have the same login for different environments. You can do different thing. So different people can work on different things. This is especially helpful if you have developers who are working on a thing, admins who are working on something else. They can all kind of work in their own environment, and then you use the tools that are available to you to roll those up and merge them later.
So my recommendations are, you know, use the DevOps Launchpad to get started with training.
Get familiar with the terminology.
Understand what it is, what all of these words mean.
Decide how you want to set up your development environment, whether it's development master, development deployment, master just the master strategy, whatever. That's up to you.
Set up your GitHub project, enable DevHub, refresh your sandboxes. Be sure to include your incorporate your ticketing system because this is gonna be your documentation for your changes as well as the actual physical changes that occurred.
And most importantly, start small.
So here's some QR codes for you to kinda get started.
And with that, I'll turn it back over for any questions.
Awesome. Thank you so much, Eric. What a fantastic implementation story for us all. I know a lot of it resonated, and I'm so glad to hear deployments aren't are no longer taking four to six hours each time. So we have a bunch of questions that have come up in the chat and the q and a here. And then we've got a really good one to start off, and it's it's very a a practical question that I think a lot of people starting out will be unsure of.
So this question here is from Carlos who asks, all of the members of my team, will they need their individual Git accounts, or can we have a shared one?
You can have a shared one. So you'll need a you'll need a, you'll need some sort of master Git account.
And, you know, if you work for a company, maybe you can have your your IT department or you as the senior admin set one up, and then you add everybody as collaborators. They all well so let me let me backtrack a little bit. Everybody will need their own Git account, but everybody works in the same Git project. And they just you know, Git GitHub is free. You don't need any don't need to pay for anything. You just go in and you sign up.
But everybody needs to be added as a collaborator to that particular Git project, and then you can all work on the same in the same environment.
Yeah. Exactly. Great advice, Eric.
Fantastic. So we've time for a few more questions here.
So we've had one come up in the q and a. How did your team overcome initial resistance or hesitation from team members when adopting Git? I think this is really key because a lot find it quite challenging getting all their team members on board regardless of role and things like that.
Yeah. I mean, for me, it was it was showing the benefits. Like, I did.
Before I before I made everybody go through this, I was like, here's what I'm proposing, and I did a deployment, basically, using the the Git process, the dev the DevOps process. I didn't have everything. I didn't have, like, the, like, the sandbox and all of that sort of migration process, but I showed how to use Git and SFDX together to be able to deploy things from one sandbox to another with a simple right click on a file.
And it took, you know, thirty seconds to deploy something from one environment to another, and, you know, I showed them how to use the manifest and and different different tools that are available to you.
And this this was all you know, Gearset is one option out there that that you can do that. I mean, Salesforce has their built in I don't remember what it's called. DevOps center, I think it's called, which basically is a GUI that sits on top of GitHub or Bit Bitbucket.
You know, there's other competitors out there and that do these tools. But, you know, like, at its core, I was just using the Salesforce the SFDX and the Salesforce CLI using Versus Code.
And just to be able to to deploy and how quickly it was and how seamless it was, my team was like, yeah. Like, okay. Like, we get it. Like, just seeing how quick it was was was the biggest thing that allowed me to to shift mentality pretty quickly.
Yeah. No. That is key, I think. Once everyone sees how much time it will save, once everyone's not scared of the process or getting started, that those are the, yeah, real keys to overcoming adoption challenges.
We've got a couple more questions, some fantastic questions coming in.
Another perhaps more technical question from Carlos, which is about sandbox syncing and refreshing. And, Carlos, we do have some super specific resources on Devil's Launchpad about sandbox syncing. I will add those to the email we send out following up this webinar tomorrow. You can read more there.
But, Eric, maybe you'd speak a bit if you experienced anything like this. He he says, you mentioned that we need to refresh all sandboxes. Would it cause any issues if an older backup sandbox is not refreshed?
So you don't need to refresh all your sandboxes. You only need to refresh the sandboxes that you're developing in.
If you have a backup sandbox that you have and you just, like basically, you're just having metadata from a previous project that you're just kinda storing there, you don't need to worry about that one. It's fine. It doesn't matter. You're only going to be able to source track against the the sandboxes that are refreshed or created after you enable Dev Hub.
So anything that was created before Dev Hub just doesn't have the source tracking. You can still access it with some of the tools, with with SFDX. You can still access those. It just doesn't have, you're just not gonna be able to use some of the automated tools that are available to you to be able to pull in those those, those changes rather than but you could still pull them in manually if you need to.
You can still deploy to it, but it just doesn't have the source tracking enabled to it.
Yeah. Fantastic advice there, Eric.
We've got time maybe for one, perhaps even two more questions. This question here is from Joanna who is asking about pros slash cons for doing Salesforce DevOps versus not using Salesforce DevOps, but using version control and Salesforce CLI, so command line Mhmm. And all that kind of thing? Any pros and cons you have?
If you're talking specifically about the DevOps center versus just using the command line tools with with with, Versus Code, the advantages are really the that DevOps Center is a GUI. Like, it's a graphic user interface. So you're using records and you're using, Lightning pages and stuff that you're familiar with in terms of being an admin, whereas the Versus code is all command line driven.
So you need to kind of understand what that looks like. So the look and feel a little different, The functionality is exactly the same. There is no function functional difference between the two of them. It's just how it looks and how how you interact with the data.
Yeah. Great answer. I wasn't quick enough. We Gears actually has a build versus buy white paper, Joanna, that might give you some more insight. I can see if I can find the link there before we we finish.
But, yeah, as Eric mentioned, all of these QR codes here, we'll send you on some on some extra resources. They're both DevOps Launchpad, and there's a guess at version control white paper in there, goes super deep dive, anything you could want to know, and it also gives some information about different DevOps solutions that we've talked about today.
But, unfortunately, that is all we have time for today.
As I am speaking about DevOps Launchpad, you can check out all of the free Salesforce Delt specific courses that, Eric has chatted about today, the ones that he's taken that have introduced him to Git. And all of these can be scary technical jargony terms. It will go through all of that either in the version control fundamentals course. We have a Git branching strategies course as well. So do check those out.
Joanna, let me see if I can find that, ebook and white paper for you right now, and I shall post the link in the chat because that will be helpful.
There we go. That is the link to the bill versus buy white paper, and you'll find a ton of other.
Paul, I know you're interested specifically in CICD. There's a CICD ebook on there as well that you might find useful.
But that is all we have time for today. We have slightly run over, but not to worry. Thanks so much for everyone for joining us today. Thank you for your comments in the chat and for being super a super engaged audience.
We love to see that. If you do have any questions off the back of today's webinar that you, don't think about until tomorrow or later, please feel free to reach out to us. You can reach out at team at dev ops launch pad dot com via email. Or as I said before, you can just reply to the follow-up email we'll be sending out roundabout this time tomorrow, and that will have your webinar recording and some bonus resources in there for you to learn a bit more about Git, Git branching, version control, all of the lovely things that Eric has chatted about today.
And just a reminder, if you aren't currently a DevOps Launchpad user, do go check out those courses. There is a lovely button at the top of the screen that that will take you to where you can sign up to a free account, yeah, and explore all of the training for completely free.
So thanks again, everyone, for joining. Once again, a huge thank you to Eric for presenting today's fantastic session and for divulging us all with your implementation journey and your personal experiences with Git.
We all we hope you found it all super insightful, and we shall see you again, hopefully, on our next DevOps, success in practice webinar. So thank you everyone, and take care.
