Webinar: How to set up a Salesforce DevOps process in Gearset

Share with

Description

Understand the benefits of DevOps but unsure where to start? In this webinar, now DevOps Advocate, Jack McCurdy, and Account Executive, Jed Ingram, introduce the core pillars to a strong Salesforce DevOps process. With the foundation of version control, Salesforce teams can introduce tools and testing to reduce deployment errors, and should utilise automation to drastically increase release speeds.

Learn more:

Related videos:

Transcript

Alrighty, everyone. Thank you so much, everybody, that has joined us for today's webinar, setting up a Salesforce DevOps process in Gear Set. My name is Jack McCurdy. I will be cohost for you this evening, along with my colleague, Jed Ingram, who will be delivering this awesome presentation for you guys today.

Couple of housekeeping bits and pieces. Of course, this is Zoom, so there is a chat window which, that you can all feel free to participate in and ask questions through. There's also a q and a button there as well, which will be monitored, throughout the session. Having said that, there will be time for a full kind of q and a at the end of the session. If you have any questions that want to wait till the end, but I will do my best to field the questions and, pass those over to Jed where appropriate as we run through the webinar today.

So without any further ado, I will pass over to Jed and get this thing started. Over to you, Jed.

Thanks, Jack. Welcome. Good morning, good afternoon, good evening to you wherever you're based in the world. I hope everyone's keeping well throughout this global crisis that we're all facing.

As Jack mentioned, my name is Jed Ingram, and today we're going to be discussing setting up a Salesforce DevOps process in GearSat.

So to keep it brief, I'm an account executive here at Gearset, so my day to day consists of speaking to a whole host of customers ranging from SMEs to the Fortune five hundred about release management and DevOps.

When I'm not talking all things DevOps, I like to do my fair share of hiking. If any of you have ever been to the UK, or Cambridge in particular, you know how miserably fat it is. And like everybody else in the UK, I like to have a couple of cold beers on a sunny day.

Anyway, that's enough about me. Let's get some let's go over to the interesting stuff.

So if you're new to this space, Gearset is the leading end to end DevOps tool for Salesforce.

It scales from teams first dipping their toes into DevOps, right through to teams of hundreds of people making the most of parallel development and continuous delivery.

We're a team of around seventy people now, with over half the team focusing on improving Gearset and that's one of the reasons we we can release new updates daily.

So today we're going to be covering what is DevOps and why is it important.

We're then going to be looking at where you're currently at with your DevOps journey and how we can take that to the next level.

And then finally, we're going to run through a live demo to see how this looks within Gear Set. And for any of you that like a bit of a challenge, we've got something special planned for the end as well.

So to kick this all off, what is DevOps?

So to answer that question we have to cast ourselves back around five or more years ago, where you might remember seeing this little guy at some of the Salesforce events.

And Salesforce had a completely 'chicks not code' approach, which was great.

This little guy is still around now, but the message isn't as prominent.

However, this does draw the question of why are we looking at DevOps now then? So over the past five years Salesforce as a platform has shifted towards a new future. It's becoming more important than ever for the developer experience to improve, to make way for better customisation, easier building and better features.

And sometimes this can prove difficult with just the clicks not code approach.

And just to point out here, we're not just talking code, declarative changes as well.

We therefore find ourselves in a situation where we have, more often than not, developers and operators working on the same team. So in brief, all DevOps is is a software engineering practice that tries to unify those developers and operators that we typically see as administrators.

However, when we talk about DevOps in the Salesforce space, you can see lots of different definitions that vary on what people think the most important aspect is. I've heard some people say DevOps is about automating manual processes and making smaller, more regular, and more reliable releases.

Then you hear other people say, no. No. No. It's more about agile and responsive way of developing with a core focus on reliability and speed.

I'll be completely transparent with you here. I wouldn't focus too much on the definition, as for most people all Salesforce DevOps is, is a better way of managing new deployments and releases.

So why is DevOps important then?

A couple of words, DevOps is the future, and there's good reason for that. After speaking with a number of teams that have adopted DevOps, there are a few key benefits that it all experienced that really stood out.

The first being quicker deployment cycles, which will allow you to get new features out to your users and customers faster, giving them an overall better user experience. There was an increase in product quality.

The smaller development cycles within DevOps allowed for more frequent code releases. This process becomes easier to identify code defects so the teams could overcome the amount of deployment failures using the principles of agile programming.

We also noticed faster innovation cycles that allowed for more frequent user feedback, which overall increased the number of innovative ideas being pushed through, and it also allowed allowed Teams to change directly change direction really quickly when needed.

And then finally, the last benefit. There was a reduction in suspension of operations.

So teams using DevOps have faster restore times in general, in the event of a service outage.

Good DevOps teams were able to restore within the hour, meaning very, very little downtime.

Alongside this, we typically see a reduction in errors because there's more frequent, better testing, smaller smaller releases more often, and automatic checks.

So this is the DevOps journey. You might have you might have come across this on our website before or in some of our white papers. But to break this down for you, we typically come across five different stages of the DevOps journey. I'm being completely honest, most teams typically in the beginner or the novice stage.

So as I run through this journey, I want you to try and picture what stage of the journey you're currently at, and then throughout the rest of the webinar, hopefully, we'll give you some idea of how to get to that next stage.

So just quickly, if you're at the beginner level, you're usually working directly in production or in sandboxes with very infrequent releases.

At Novice, you've probably started your DevOps journey by adopting version control, but you're only using it periodically, maybe to store metadata as a backup.

At this point you're still either using Chain Sets, or you might have switched over to AMP or a DXCLI, or maybe a combination of them all.

When you get to Practitioner, you're halfway there. Your team has started working in their own independent dev dev sandboxes with a subset of metadata. You're now using version control as your single source of truth and have the option to roll back the metadata changes.

If you got yourself to leader, you've pretty much got yourself a nice Aston Martin. Your team works in the CI workflow with Git as the source of truth for the majority of the metadata. And you've also got a well thought out branching strategy.

Automation is now a key part of your workflow, with automated unit testing and continuous deployments to staging environments, with regular, reliable releases to production.

And then finally, if you've made it to Innovator, you're doing incredibly well. You've still got that smooth, smooth CI workflow with Continuous Delivery in place, but you're now also regularly backing up both your metadata and your data with a tested restore process in place.

So hopefully after speaking about them different stages there, you can picture yourself in one of the brackets. For the rest of the webinar, we're gonna try and talk you through how to get to that next stage.

So if you're currently a novice, the next stage would be to get to practitioner, Practitioner, so small bite sized chunks rather than jumping straight to the innovator. So together there's a couple of things that we need to consider.

The main pillar is version control, and there's one core concept for version control and that's just to track changes to files over time. So for version control and that's just to track changes to files over time.

You've then got continuous integration, which is just a practice that developers use to integrate their code automatically through to another environment.

You've got Testing, which basically identifies errors, gaps or missing requirements in your code that you're pushing.

And then finally, this is usually the missing piece of the puzzle that people often forget about, but it's very, very important, is backup. And that's essentially taking a copy of your data and your metadata and putting it somewhere else. So if Salesforce does go down or if there's any problems, you've got something to restore to.

So just to break them up into a little bit more detail, we'll start with version control.

In the context of Salesforce, version control simply means you can track changes to your orgs and have multiple people working on the shape of your org independently without treading on one another's toes.

There are a few options when it comes to this, but we recommend using a Git based version control system like GitHub or Bitbucket, as they're the best for conflict handling, tracking changes and are better integrated with DevOps tools like Gearset.

As mentioned, version control is the core pillar and foundation of your entire process, and that's how you're going to get to that agile development.

Everyone should be starting here. It's the future of development on the platform.

And with DX movement and the shift to DevOps on the Salesforce platform, it's clear that source control should always be the source of truth for your orgs.

So when speaking with customers, we come across a lot of benefits with version control and I've just picked out a key few that really come to mind.

So the first is enabling that parallel development stream by allowing developers to work on changes in isolation without the environment changing underneath them.

Version control helps resolve merge conflicts by highlighting them to you.

Also, every time you save a new version of your project, your version control requires you to provide a short description of what was changed.

Additionally, you can see exactly what was changed in the file's content.

This helps you understand how your projects evolved between versions. It's also really useful for compliance, if you need to follow any.

Also, because you have someone else reviewing your code, you've got double the chance of spotting any errors or bugs, so you can get them ironed out really early along in the process.

And then finally, being able to restore to older versions of a file means one thing: you can't really mess up. Well, at least it's very hard to.

Knowing this should make you a lot more relaxed when working on the important bits of a project.

As mentioned, this this is the starting point. Version control is very, very important, and you can see I've got a link there to a white paper on version control, which discusses best practices, branching strategies, a whole host of stuff that I'd really recommend checking out.

So continuous integration is where the automation comes in. Deployments without clicks. They're no longer manual, but scheduled or automated.

DevOps is all about reliability of process and speed. We get reliability from the workflow, I. E. The branching and the source control, and we get the speed from the automation part.

So this is where you want continuous integration and continuous delivery to come in. And if you're thinking it might be complicated, it's much simpler than what you think. You don't need to write any complicated scripts or anything like that. You can use a tool such as Gear Set and create your CI jobs in just a few clicks that I'll show you in a second. And you'll still get all the visibility.

CI isn't just for deployments either. It's also to validate your changes, which is really important to do this regularly and ahead of time. So every time you make a change in a branch, these changes can be validated automatically so you know it's going to be going to be a successful deployment.

This essentially stops you going down a path or building on top of something that's not actually deployable.

If there's an issue, you'll catch it early. Again, just a couple of benefits.

So the main one is the faster release rate. CI improves the time to market because the code changes are essentially smaller and then issues are easier to detect.

This improves the customer satisfaction. It keeps your customers happy because you've got a faster turnaround on new features and bug fixes and things like that.

And utilizing a CI approach also keeps your product up to date with the latest technology and allows you to gain new customers really easily.

We can increase the team's transparency. So CI is a great way to get continuous feedback, not only from customers but also from your own team. This increases the transparency of any problems in the team and encourages, encourages responsible accountability.

You've also got that test reliability which improves due to the bite size and specific changes being introduced, thus allowing for more accurate positive and negative tests to be conducted.

And then finally, probably the most important part here, we're actually going to reduce the costs. So automation in the CI pipeline reduces the number of errors that can take place in the many repetitive steps of CI and CD.

Doing this also frees up developer time that could be spent on product development, as you should be doing, as there aren't as many code changes to fix down the road if any error is caught quickly.

So just jumping across to Salesforce testing, there are hundreds of different software tests, but we're just talking about a few key areas of testing here. To name a few, you've got unit testing, which are important as these are these are essentially checking whether Salesforce is happy or not with the changes that are being made.

You've got Regression Testing, which verifies that recent changes have, haven't altered or destroyed the existing functionality.

And then you've got user testing, and these are the changes just checking whether user is happy and they're working for that user.

So CI jobs can be used to automate the testing process. You can use outbound webhooks within Gearset to trigger tests to start running, and we'll touch on this a little bit later when we jump over to Gearset.

Again, this will speed up your release process, but we've got to think why is this so important?

So back to that idea of DevOps processes being reliable, testing is a crucial part to DevOps, and as I'm sure you all know, Salesforce require at least a seventy five percent code coverage.

Testing once is just no good. It must be baked into your process because every time you change something, you don't know if it's going to work.

So there are two things to consider really. Test early. Don't get two weeks into a project before you test something. Make sure it's happening early in case there are any issues. And then don't stop after the first test. Keep testing regularly so you know each step of your project is performing as expected.

Some further benefits that come to mind when thinking about unit testing include the quality of your code is essentially improving. So testing identifies any defects that may come up before the code is sent further for integration testing. It exposes the edge cases and makes you write better code.

Writing the test first forces you to think about your design and what it must accomplish before you write the code. This not only keeps you focused, it makes you create better designs.

And then finally, testing helps simplify the debugging process. If a test fails, then only the latest changes that you've made in that code needs to be debugged, not all of the previous.

So with a couple of words, a regular testing process will make sure your release process performs reliably and is healthy. And they're the core features really.

And then finally, this is typically the missing piece of the puzzle.

What is data backup? It's essentially a copy of data stored elsewhere so you've got the ability to restore in need if needed.

Your Salesforce business and customer data is critical. The cost of a data loss or corruption incident is so steep, you must really make sure you have a reliable backup strategy in place. You never know what's going to happen. It could be an unexpected data loss or corruption.

It could potentially be a rogue colleague who's accidentally or purposely, depending on what you've done, deleted something, or it could be something on the Salesforce end like Permageddon all over again.

The point is you just don't know what could happen and with something so critical to your business it can't be ignored.

I just want you to spend the next thirty seconds or so thinking about what your process would be if you had to restore data in the event of a data loss.

Just think about how much time it's going to take, how much is it going to cost you. It's even more prominent than ever now that Salesforce have just retired their native tool.

The benefits of a backup solution are really self explanatory.

Firstly, protection for your data and your metadata.

With a tool in place, regardless of the type of incident, you'll know your data will be safe.

A good tool will make sure you have automated daily backups, but the most important aspect is the ability to restore.

This part is crucial, because if you think about it, having a backup tool without the ability to restore the data is just a little bit pointless.

So make sure when you're trialing solutions, you test that part really, really well. The ability to restore is what gives you guaranteed business continuity, so it's really worth testing the solution before making any decisions.

You may also need to comply with certain compliance regulations on data storage, I. E. Do you need to keep the data for a certain period of time, for example. It's all worth considering when you speak about data backup.

And they were the four pillars, and I know it's all well and good me speaking about them, but how do we actually put all this together?

So we're now going to jump over to Gear Set, where I'm going to run through a live demo and set up a source driven DevOps workflow with Gear Set, including CI. I'm going to be starting completely from scratch, like I've just set up my Gearset account.

And to make this a little bit more interesting, I'm going to time how long it takes me. So I'm gonna, I'm gonna build this workflow and we're gonna time how long it takes.

And then and then and then at the end, I'm gonna challenge everyone afterwards to see if they can beat my time setting up that full DevOps workflow. Jack, do you mind kicking off the clock for me?

The clock is ticking.

Wonderful.

So hopefully everyone can still see my screen when we jump across to the Gearset website.

So Gearset's a completely web based app and you can start a free trial whenever you want. You can also go ahead and log in. That's why I've already got my account set up. You can you can log in in a couple of different ways. You can use your Salesforce credentials, Google or LinkedIn. I've got mine set up with my Salesforce credentials.

And that'll take me straight through to the app. So this is completely fresh. There's no deployments being made, there's no CI job setup, there's no unit testing job setup, there's no data backup job setup, so it's completely from scratch.

So you can see the main homepage is the Metadata Comparison.

On the left you've got the Feature Bar, which allows you to do some continuous integration, some unit testing and some monitoring, which we'll talk on a little bit further down the line. You've got the Data Deployment Tool, so a way of moving data for sandbox seeding.

And then finally you've got the Data Backup tool, a way of copying your metadata and data, so you've got it elsewhere.

The first thing that you'll need to do is set up a my Connections' tab. So you can go to your Salesforce orgs and this is where you add your new organization.

So any orgs that you wish to deploy data for, deploy metadata for or to backup, you need to add them here.

So just quickly, I'm going to add a new organization. I'm going to type in my username, and then I'm gonna authorize that.

This will take me through to Salesforce, and it'll ask me to log in. So I can just fill in my password there and click log in.

Once that's authorized, it'll take me back through to Gear Set, and it'll just give me a green thumbs up. All done.

I need to add one more org, which is my QA org.

And I'm gonna do something slightly different here. So I'm gonna still connect to use no auth, and, again, take me through to Salesforce where I can fill in my password.

And then I've got my two orgs connected. So I've got my dev and my staging or QA, whatever you wanna call it.

What you could do here though is really nice. So that's being authorized. You've got three ticks along the bottom. You can tick on a way to monitor this org, you can tick on a unit testing job for this org and you can also tick on if you want to copy the data on this org.

So in terms of unit testing, I can create an automated unit testing job that will run your test specific time and display code coverage and test results.

So I want that on, so I'm gonna tick this on. Monitoring will allow me to track the changes being made across that particular environment with automatic org snapshots, detailed change tracking, and rapid deployment, with the option to roll back as well.

So I want that on as well.

The only thing that I'm not going to turn on at this stage is a backup of that data in that org. So I'm happy and I can just click okay.

The other thing that I might want to add at this point is any source control that I'm using and any ticketing software like Jira.

So we use GitHub internally and that's what I'm gonna connect to. So I'm just gonna check connect to GitHub. It will take me through, and it'll ask me to fill in my username and my password again, and then I can sign in.

Because I've got auth authentication turned on, it will send me a pass it will send me a code to my phone. So I'm just gonna grab my phone quickly and just fill in that number there, and then I'm gonna verify that.

Okay. That's all set up. So I've added my orgs, I've added my source control. We're pretty much ready to go at this point.

So just before going any further, I'm just going to jump across to this source driven DevOps flow with GearsFEM.

Some of you might have come across this before, but if you haven't I'm just going to explain it very briefly.

So as mentioned, version control should be your source of truth. So we've got this master branch at the bottom, which is in version control, and everything in there should be ready to go.

You've then got your Dev Sandbox at the top, so you might have your individual developers working in their own individual Dev Sandboxes.

And once they've made changes, once they've added new components, what they need to do is they need to open up a Feature branch and commit all of them changes through to that Feature branch.

Once those changes are in the feature branch, we can open up a pull request, we can do the code review with inside of GitHub and then that reviewer can merge into their master branch.

Once it's in the master branch, once all of changes are in the master branch, we can do a couple of things. So we can have a CI job that pushes through to my QA environment, we could also have a validation only CI job that will validate the package against my target, which is production, but save that ready for me to go in and manually deploy.

So I'm going to ignore step six today and I'm just going to concentrate on step five, which is the Continuous Integration part through to Staging. So that's the first thing that I need to do within Gearset now.

So jumping back to Gearset, I've got this Continuous Integration dashboard and and you can see I haven't got any jobs created at this point.

To add a new CR job it's really easy. I just click 'Add New Job' and I'm going to give the job a name. So this CR job is going to move all the changes from my master branch through to my QA, or I call it staging.

So my source is going to be my master branch, so I'm gonna select GitHub. I'm gonna select my Salesforce repository, and I'm gonna select my master branch.

My target is gonna be my QA org, so I'm gonna select Target Salesforce and I'm gonna choose my Staging org.

Yes, it's now asking me how often do I want the CI job to run. Do I want it to run every four hours, every twenty four hours, or when the Source branch is updated?

I want when the source branch is updated, so when these things are merged into master, I want the trigger to happen and not to push out to my staging environment.

Down the bottom, I can specify the level of test that I want to run. So you've got a couple of options here. You can run the Salesforce default tests, you can specify certain tests to run, or you don't have to run any tests if you don't want.

You've then got the option of different types that you want to deploy. So you can deploy new, changed, or deleted. I'm just gonna focus on new and changed for the time.

Jumping across the notification settings. So how do I wanna be notified? Do I want to be notified every time the CI job runs or only if the CI job run fails? And then how do I want to be notified? So I want to be notified via email, so I'm just going to type in my email there. If you prefer to get a text or integration with Slack, Teams and Chatter, you can do at the bottom.

The third tab is Outgoing Webhooks. So this is the part if you're using any external testing software like Provar or Selenium, you can add a Webhook here that will integrate with them.

And then finally, you've got this Metadata Filter. So what metadata are you actually interested in, in Gear Set deploying? Do you want us to deploy everything? Or is there just certain types of metadata that you're interested in? So you can go this through this list to be really specific on what you want to deploy.

And then when you're ready, you can save that job.

And we're pretty much there. The last thing that you have to do is just set the webhook on GitHub. And you only have to do this once for every CI job.

So you can see Gearset's generator generated a payload URL for me and a shared secret code. If I jump over to Gearset sorry, to GitHub and log in, I can select my Salesforce repository.

I can go into the settings of that repository and on the left you can see I've got this Webhook section.

All I need to do here is add a new Webhook and you can see it's asking me for certain things like the payload URL. So I can go back to Gear Set, I can copy that across and I can paste it in there.

Same with the secret code.

The other thing that I might want to do is just change my content type to application json and then I can add that webhook. You can see it's been added at the bottom here.

So that's all done. So we've just added the CI job and that's all successfully been added to Gear Set. So as you can see it's just a couple of clicks to get a CI job up and running.

What I'm gonna do now is I'm gonna create a Feature Branch within Gear Set, and I'm gonna commit all of my changes that I've made in my Dev Sandbox through to that Feature Branch.

I'm then gonna open up a Pull Request, I'm gonna jump across the GitHub and do my own code review. You'd probably have a reviewer assigned to do that. And then I'm gonna merge that into my Master branch.

Once them changes have merged into my Master branch, that will kick off the CI job that I've just set up.

Okay. To do this within inside of GIS, I need to go back to the metadata deployment part of the tool.

My source is my dev sandbox that I've made the changes in, so I'm gonna select my dev sandbox here.

And my target is my source control repository.

So I'm gonna select my repository, which is Salesforce Development.

I'm gonna select my master branch, and I'm gonna create a feature branch from master. So I'm just gonna call this feature Webinar'. I'm going to create that branch.

That branch has now been created within GitHub for me. At the bottom here I've got this metadata comparison filter. So Gearset comes with some standard filters, you can see I've got the default comparison, which compares sixty four of the most common types of metadata.

I've got the Compare All, which compares all the metadata.

And if I wanted to manage some custom filters and create my own, I can absolutely do so. I can just come into here, I can select the metadata again and then I can save it as a custom filter, so I can reuse that and any of my colleagues can reuse that in the future as well.

I'm just gonna use this CI comparison.

So for those of you who don't use Gear Set, a comparison is taking place now. So what all we're doing is we're comparing the metadata between your Dev Sandbox and your Feature Branch, which is a replica of Master.

And then what Gear Set is going to do is highlight all of them changes on the screen for me.

In the background we're running something a little bit more complicated, we're running something called a Semantic Diff, which basically breaks down all of that metadata into the smallest possible components that we can, so we can understand the relationship that that metadata has and how it all interacts with one another.

And then we finally stitch it all back together in a way that makes it easier for us to deploy.

Okay, so that's loaded up, you can see we've got five tabs along the top. We've got Change, New, Deleted, All and Selected Items.

Your Changed Items tab basically shows any changes that have happened between Dev and your Feature branch, and you can see the line by line diff view at the bottom that highlights them for me.

So if I wanted to deploy any of these components, I could just check the checkbox.

I can also expand the arrow at the side and I can see any children components underneath. So you can see this custom object account at the top has a load of components underneath and I can see all the custom fields.

So I've just done some work on this account. Sla and that's the component that I want to deploy. So I'm just going to check that checkbox.

Jumping across to new items, these are things that exist in my Devorg but don't exist at all in my Feature branch. So they're probably new components that have just been added to Dev.

I'm just going to select one or two components from here. So I'm just going to select this custom field here called DiscountPercentage.

Again, if I expand upon that, yes it breaks down any dependencies for me. So it's really easy to see the dependencies on the top level and then I can just go ahead and select them.

If I accidentally forgot to select the dependency here, maybe I was in a little bit of a rush or something, on the next screen Gear Set will run some problem analyzers and highlight them to me.

I won't go into them in too much detail, but if you'd like to speak about them in the future, just drop us a message.

And then finally we've got the deleted items. Oh no, I'll select one more component from new items just just to show you. We've got the Sales Demo field. If I expand upon that, I can see any profiles and permissions that relate.

So you can see the individual FLS on the profiles. And if I've just done some work on a couple of them, I can just select one or two components that I want to deploy.

The deleted items, so these are things that exist in your, feature branch, but they don't exist at all in your dev sandbox. So maybe they've been deleted from your dev sandbox or added directly to your feature branch. So if I was to select any of these components, we'd actually be making a destructive change and removing it from my Feature branch.

We've then got All Items, this basically show everything in Dev and my Feature branch and just show the difference there. I can also see when they were last changed on, and I can also see when they were last changed by.

And then the last tab is all the components that I've selected throughout, and these are the components that I'm planning on deploying.

So I'm just gonna click next here.

So what what Gearset's gonna do now is it's gonna show a quick summary of all the components that we want to deploy, and I can add some notes. So I can say I'm deploying this custom field from my Dev environment to my Feature branch. The notes are really useful for keeping a good audit history of the changes you're making and what environment you're making them in.

If I connect the Jira, Azure or Asada at the start, I can now start to integrate with them so I can start updating tickets and assigning notes.

You can schedule deployments. So maybe you want to schedule this for later one in the evening, maybe when there's not much activity going on with inside of Salesforce.

Can specify a date and a time that I wanted to schedule these for, and I can also send over an email or text to myself just to give you some feedback.

Let's take a look.

I'm just gonna deploy now.

So that deployment's in progress. When that's loading, I'm just gonna jump across back to this source driven workflow.

Just to show you what we've done, we've made some changes in my Dev Sandbox and we've now committed them to this feature branch. So we're at this point here. I'm now going to open up a pull request, do any code review and then merge that into master.

If that deployment has been successful, I've committed them changes to my Feature branch.

I've got two options on the right, I can either view this on GitHub or I can create that pull request as I mentioned.

So I'm going to give the pull request a name, I'm happy with that. I'm going to select my target branch, which is 'Master'. I can give it a quick description if I wanted to and I've got a couple of other options down the bottom here. I'm gonna go ahead and create that Pull Request now.

I can then jump across and view that on GitHub.

So at this point, as I say, you probably would have a reviewer reviewing this pull request, but for the sake of the webinar, I'm just gonna do it myself.

So I can add some comments here, and then if I'm happy, I can merge that pull request and confirm that merge.

So what we're doing now is we're merging that into master. You can see that that's been successful.

And if I was to go back to my CI job that I set up earlier, I can see that's now been triggered and you can see that that start is running and downloading that metadata. So all that's going to do is move that metadata from my master branch through to my staging org.

Okay. So that's a quick overview of the continuous integration, and and it's really straightforward to set up a source driven workflow. You take a little bit of time and think about that branching strategy that you want to make.

So the next thing that I want to do is I want to create a data backup job.

So this is really straightforward. I just jump over to the data backup part of Gear Set and you can see that no jobs have been created yet. I want to create my first backup job, so I'm going to call this 'BackingUpQA'.

I'm going to select the org, which is my QA org and I can specify the daily API call usage limit.

So as I'm sure most of you are aware, Salesforce set an API call usage on each of their orgs. We can take a percentage of that and just assign this to backup.

So if I set this as eighty percent, Gearset can use up to eighty percent of the API call usage just on backup, up, but that will give you a remaining twenty percent of any of the tools that require the Salesforce API.

I can then specify a time that I want this to run. So I know there's not much activity in Salesforce going on at one am in the morning, so I'm going to specify one am.

I've got notification settings again, so how do I want to be notified? Again, I'm happy with email.

Smart Alerts are probably my favorite feature within the backup tool. They basically notify me when this strange behavior happening in my org.

So for me, I never ever delete any records from the object Opportunity.

So if I so if if there was some records being deleted from Opportunity, I'd want to know about it, because that's strange and I wanna go check that out.

So I can say when one percent of the records in Opportunity are either removed or changed or added, I can be notified.

So I'm just gonna add that Smart Alert there.

You can add up to twenty Smart Alerts to notify you when different things happen.

And then finally, I've got the Filtering tab. So what objects do I actually wanna back up? Do I wanna back up everything?

It's very rare that people do actually want to back up everything in their org. You can go through this list and be quite granular and quite specific on the things that you want to back up.

GIS, it also does something really neat here and it just selects the most important components that that we think. So you can see it selected three hundred and thirty four of the five zero nine objects for me. If I'm happy with that, I can just go ahead and save that job.

That job has now been added and it's completely ready to go, so at one am in the morning it will start that first run.

It will then run every day for me at the same time and I can go into the backup job and I can see all the data, so I can see any records that have changed or been added. And if I needed to restore a changed record or maybe I needed to restore ten thousand records that have been removed somehow, I can go into Gear Set and do that all in the matter of a couple of clicks.

Okay, so I've set up my backup job, I've set up my source driven workflow. The only other thing that I did right at the start was set up this unit testing and this monitoring job. So I'm just gonna show you quickly what that looks like.

So this is the unit testing dashboard.

You can see the job's been created and it's monitoring my staging org. I can see that it's been run once, and I can see my code coverage is awful. It's zero percent, and it gives me a message of the coverage is low. So it's just a way of keeping track of your tests and seeing how that code changes day by day. And I can also go into here, I can see the code has changed, and I can go adjust that with inside of Salesforce. So it's just a nice way of keeping track of all of that.

As well as the unit testing, I selected for a monitoring job to be set up. You can see it's been created here. It's monitoring my staging environment and that initial snapshot has been taken.

We'll then take a snapshot every single day of my staging environment and it will show me any differences that have happened there.

If the differences aren't supposed to have happened, I've got the option to roll back so I can remove them changes if I need.

Another use case might be I've added a hotfix directly to my staging environment. I can then deploy them changes that I've made directly in staging back through to my dev, my dev org just so I could do some further testing and some further work on them changes.

Okay. So that's everything that I was hoping to do. So just to jump back across to the presentation.

Jack, you can you can stop the timing.

Nineteen minutes twenty seven seconds.

Nineteen minutes twenty seven seconds. Okay. So I'm gonna set you a challenge. If you if you want to get involved, please do so. So if you think you can beat nineteen minutes twenty twenty seven seconds or no matter what time you do it in, it'd be really good to know.

So if you wanna take part of the challenge of trying to beat me, all you need to do is you need to go over to GearSet and create a trial. You need to add your org connections. You need to set up a git to org CI job.

You can follow this source driven branch. We'll send you that via email or you can message us about it. And you can also create a data backup job.

Once you've done all of them, you need to drop us a quick tweet or a LinkedIn post with the hashtag Gearset DevOps challenge with a before and after picture. So a time that you started and the time that it finished.

Once you've done that, you're probably thinking, what? Why should I bother? Why should I do this? The first thing is you wanna you're on your way to having the smoothest DevOps workflow around.

And if that's not enough for you, everyone that completes the challenge will also get a fifty dollar Amazon gift card or a charity donation to Feeding America.

If anyone does manage to beat my time as well, you'll also get given a gear set cap, which will be sent to you via post.

So that's a quick overview of setting up a Salesforce DevOps process in gear set. I wish you all the best with the challenge, but for now I will leave you with a little bit of information on how to start a free thirty day trial. If if you wanna start your trial, we've got some information on our doc site that'll help you get going. And if you wanted a tailored DevOps consultation or demo, we'd be more than happy to jump on a call with you at a separate time. Just drop us an email to that address there.