Unlock the power of Salesforce DevOps with automation

Share with

Description

DevOps really delivers once automation is up and running smoothly and reliably, saving manual effort and reducing human error. Rob Cowell, DevOps Advocate at Gearset, explains why automation is central to DevOps and gives practical tips for getting started.

Topics covered:

  • Why is automation key to DevOps?
  • What is CI/CD?
  • The foundation of successful CI/CD
  • Available CI/CD solutions

Learn more:

Related videos:

Transcript

Hello, everyone, and welcome to our webinar today, unlocking the power of Salesforce DevOps with automation.

We had a lot of people interested in today's webinar. So, we're just seeing people filing in at the moment, but we'll give it a minute or two just until the numbers flatten out a bit.

We'd love to know where everyone's diving in from today. If you wouldn't mind letting us know in the chat.

Let's see how much of a global audience we have. Whereabouts are you in the world, Rob?

I am down in Folkestone, which is right on the southeast coast of the UK. Seventy two miles from London, but only twenty seven from France.

Oh, wow. I didn't know that, actually, but that is a lovely part of the world.

And I am in London, but I do travel down to that part of the UK often. It's very nice. Very cool.

Welcome, everyone. Welcome to everyone just filing in at the moment. We're just just, gonna start in a minute or two. We'll just wait for everyone to to come into the Zoom room.

Nice to see some of our US folks joining us there, Ben.

US, Netherlands Hampshire. I'm from Portsmouth originally.

It's nice to see that name.

Welcome to everyone just joining us.

I think the numbers are flattening out a bit. So, let me do a little little bit of an intro then. And by the time I'm finished, I'm sure we'll have everyone in. So thank you very much for everyone that's joining us today.

Really great to have you with us. So today, we're gonna be talking about DevOps and automation. So I'm sure by now, a lot of people on this call know about the value of DevOps. But just in case you don't, it allows you to bring more value to your organization by allowing you to deploy to your Salesforce org faster and more efficiently, therefore, bringing more value to your users.

And at the core of DevOps as well as processes and using tools is automation, and that's what we're gonna be speaking about today. So, we partnered with, Rob from Gearset, and he's gonna be talking us through, how how to get started with DevOps through automation. So just to introduce myself, my name is Ben Ben McCarthy from Salesforce Ben, and I'm gonna be your host today. We are going to listen to Rob, who's got lots of great insights to share, for the next half an hour or so, and then we're gonna go into a q and a with Rob and myself.

So, you all should have a little q and a box at the bottom of your Zoom window, and you can insert your questions there, and we'll get around to as many as we can, at the end of the event. We do have a team monitoring the q and a as well. So if you've got any, answers which are quite quick to answer, then we can, we, the team will get around to answering them. So, Rob, if you're ready, I will hand over to your fine self.

Thanks, Ben. Let's, let's get some sharing going, and we'll make a start.

And I think we should be good. Alrighty. So, yep, thanks for the, the introduction there, Ben.

As we know, the session today is on unlocking the power of Salesforce DevOps with automation.

So a little about myself just to kind of help explain why it's me talking about this. So I've been working with Salesforce around twelve or thirteen years now. I started out as a developer, and then I moved into a few sort of architect roles. So over the years, I've seen a lot of change on the platform. It's grown. It's evolved.

But one of the biggest changes that I've kind of seen is the increasing importance of automation in the Salesforce DevOps process.

So in today's webinar, we're gonna look at why automation is vital for a robust and a mature Salesforce DevOps process.

As a quick agenda, I'll begin with outlining what both DevOps and automation mean and then specifically what they mean for Salesforce development and deployment.

Next, we're going to move into why automation is so crucial for mature and successful DevOps before we explore some of the different types of automation from unit tests all the way through to continuous integration and continuous delivery.

And then finally, we'll have a look at some of the tools available to help you start automating your process wherever you are in your DevOps journey.

So let's start from the beginning.

So for anyone that may not have come across it before, DevOps is a set of practices that encourages software development and operation teams to combine their responsibilities.

By breaking down the silos of development, operations, and development, it encourages greater collaboration with which helps teams to build, test, and release their software faster and more reliably.

For Salesforce, DevOps means bringing the people responsible for building the applications, usually the developers and admins, together with the people responsible for releasing, monitoring, and maintaining those applications, which can also be typically admins but also team leads or release managers.

Now, the DevOps philosophy also encourages an agile approach to development and releases. It prompts teams to release their changes in smaller bite sized pieces rather than a big release at the end of a project.

DevOps has been the industry standard for quite some time across other areas of software development because it has many benefits.

For example, integrating your work and releasing small and often helps teams reduce bugs and deployment failures.

It helps achieve a higher release frequency, which means that you see shorter lead times to getting change delivered, and you can recover quickly when a bug is inadvertently released, hopefully not too often.

But most of these benefits aimed at helping teams from where they begin on their DevOps journey, and they only kind of realize and mature once the CICD is in place, which we'll explore shortly.

So how and why does automation factor into this equation? Let's have a start by looking at what automation actually means.

At a very high level, automation refers to setting up processes or tools that can run tasks for you without the need for manual intervention.

But given how broad that definition of automation is, it's unsurprising that automation can come in many different forms.

Many of you will be familiar with automation in the Salesforce context, with flows, roll ups, and even formula fields, which technically are forms of automation.

But for today's session, we're going to look at bringing automation to your DevOps tasks.

So one of the most common DevOps automation tasks is automating unit testing.

This involves setting up a process that automatically runs your unit tests during development as well as an ongoing basis in production so that developers can catch any issues and spot declining code coverage early.

There's a number of platforms out there that will help with this, including GearSet.

Another important automation task is org monitoring.

This involves setting up processes to automatically monitor your orgs for changes that may have come in by other means. For example, in a previous role that I had, the dev team didn't actually have production access, but the support team did. So any changes that support teams made directly to production on behalf of the users would be identified automatically so that the developers could absorb them into their work and make sure that changes weren't overwritten.

Finally, one of the most important areas of automation in Salesforce DevOps is the aforementioned CICD.

This involves setting up a continuous integration and continuous delivery process that automatically builds, tests, and deploys changes to your orgs, and I'll be talking more about this in-depth in a moment.

So how does automation support DevOps?

When it comes to managing a Salesforce org, there's a lot of moving parts to keep track of, from customizations to data migrations to testing and the deployment itself. And without automation, these processes can become time consuming, error prone, and can lead to delays, errors, and downtime.

By automating tasks like unit testing, deployments, and monitoring for unexpected changes, organizations can improve the speed and accuracy of their DevOps processes and focus time on working with each other rather than manually actioning repetitive tasks.

Now, as we mentioned earlier, CICD is one of the more advanced uses of automation in this space.

The term CICD is itself made up of two separate parts, continuous integration and continuous delivery.

So starting with the first one, continuous integration is the process of merging your new development back into the main branch of your version control system on a regular basis.

Merging early and often will ensure that your work can be successfully integrated with the rest of your code and any other new development by your colleagues.

If you leave your new development in your org or your branches for too long, it makes it more likely that you're gonna hit a conflict when you try merging.

The aim of continuous delivery, on the other hand, is to automate the promotion of that work along your release pipeline. So, for example, automatically deploying any new development into your main branch out to your testing orgs.

Automating this delivery helped increase the speed of delivery out to your end users.

But keep in mind that this doesn't mean rushing your release to production, because robust testing and validation is still essential, and without your continuous without it, your continuous delivery will likely fail or break.

But CD can also mean continuous deployment, which focuses specifically on automatic releases, which are deployments to production.

Automatically deploying to production without human oversight is a risky option, so we only recommend continuous deployment if you are completely confident in your testing process.

If you're not at that level of confidence, perhaps continuous deployment isn't quite right for you at this stage.

There are many tools available that enable CICD for Salesforce, but before we look at what's on the market, there's a few key building blocks that you're going to need in place to see maximum success with your implementation.

Now some teams will take a big bang approach to adopting DevOps, where they try to implement lots of new tools and practices all at the same time.

But this has been found to be the least successful approach.

Instead, we recommend layering in new DevOps practices gradually over time when it comes to CICD.

There's two main key building blocks that you probably should have in place first.

The first is to have a source driven workflow where you're using version control to manage your code changes.

By using a version control system such as Git, you can keep track of those changes over time, roll back changes if necessary, and collaborate more effectively with other developers on your team.

You can still automate parts of your workflow without using version control, but for CICD specifically, you're gonna need to be using source control as your single source of truth.

Furthermore, your choice of Git branching strategy will significantly influence the structure and efficiency of your CICD pipeline.

The branching strategy essentially determines how your code changes are organized and merged, and it directly impacts how and when these changes are going to be built, tested, and deployed in your pipeline.

Now choosing a branching strategy is not a one size fits all decision. It depends on your team's workflow, how complex your projects are, and the level of control that you want over your releases.

But understanding these implications can help you design a more effective and efficient CICD pipeline.

It's also important that your deployments are already reliably successful.

If you're trying to automate a workflow where your deployments regularly fail already, adding in CICD is only going to cause more job failures, which will need unpicking.

Not only is that going to be time consuming, it's just going to be very frustrating and difficult.

This foundation isn't essential for all types of automation. You can still add automation to your workflow, such as automated unit testing without any of the above. But for a full CICD pipeline, version control and reliable deployments are that necessary foundation.

And there's something else that you should get right outside of your workflow that can have a big influence too. Culture is the key to successful DevOps and CICD.

And that's because DevOps isn't just getting the team used to new tools and new processes, but the whole team needs to see the value in adopting these ways of working, understanding the why of DevOps.

Having even just one member of the team that feels disillusioned or confused by processes can undermine the rest of the team's work. So it's important that you get alignment across the whole team.

So if you're ready to start introducing your automation, whether that's the automatic unit testing or all the way through to that full pipeline, what are the tools on the market that can help you?

Generally, there's two main categories of automation that we can look at for Salesforce.

Generic tooling, which is tools that can be used across your tech stack, not just for Salesforce.

This can make it quite an appealing option to the business if there's other teams already using a particular solution elsewhere in the tech stack.

Jenkins, Bamboo, excuse me, and GitLab are popular choices of these tools.

But the other option is Salesforce specific tools, which are built specifically for the Salesforce platform.

We'll have a start by looking at setting up an automation with some of that generic tooling, specifically focusing on Jenkins as an example.

First, you'd need to install Jenkins on a server and configure it to work with your version control system and Salesforce DX.

Once it's installed, you can create a job or a pipe pipeline in Jenkins for your Salesforce project.

This involves writing a script called a Jenkins file that tells Jenkins what to do when code is pushed to GitHub.

This script might instruct Jenkins to pull the latest code, create a scratch org, deploy the code to the scratch org, run some tests, and then if the tests pass, deploy the code to a staging or production environment.

Salesforce provides built in testing frameworks for Apex on the back end and for Lightning Components on the front end. And your Jenkins pipeline should be configured to run these tests automatically as part of your CICD process.

In your Jenkins file, you would include a step to run those tests after deploying your code to a scratch org or other environment.

Jenkins can then capture the results of those tests and even prevent further deployment if tests fail.

Finally, you should set up monitoring and alerts for your CICD pipeline.

Jenkins does include built in tools for monitoring the status of your jobs and can send notifications by email or Slack or whatever mechanism you prefer if a job fails.

There's also a marketplace of plugins to integrate Jenkins with other monitoring and alerting tools should you need to. And this allows you to quickly identify and resolve any issues that might arise in your CICD process.

Now as you can tell, Jenkins is largely a means of orchestrating those various tasks by executing other tools, such as the Salesforce command line interface, in an automated script.

And that will be most likely a script that you're gonna have to write and maintain yourself for your specific environment.

Teams typically spend around ninety hours configuring an automation pipeline in this way for the first setup, plus the overhead of ongoing maintenance.

But there are DevOps and automation tools available that are designed specifically for the Salesforce platform, which are much easier and quicker to set up. And this is because they're specifically designed to deal with the Salesforce metadata API, which is the core way of of working with Salesforce for deployments.

They're often clicks, not code, so you don't need to write those those large scripts like we saw in Jenkins, and you don't necessarily need prior DevOps experience to get up and running.

Plus, they also often offer other functionality that's vital for Salesforce teams, such as backups, data deployments, sandbox seeding, and more. And that means that the team only has to be trained on one single single platform to get all those features, and it gives a unified audit trail of what's happening with things coming in and out of your orgs.

Now Gearset offers a variety of click driven automation solutions to help whether you're early in your automation and DevOps journey or a little further along. And as we mentioned, there's a few different ways that we can automate that workflow.

With automatic unit testing, Gearset can run your unit tests on a daily basis, and you can get notified as soon as any of those tests start failing or if your code coverage drops below a certain threshold, which doesn't have to be the same as Salesforce's threshold of seventy five percent.

This helps catch any issues early, long before they become bigger problems because you're regularly checking the quality of your changes as they happen.

Gear set will show your failing tests line by line, highlighting exactly which tests are failing as well as a stack trace so you can get fixing quicker and easier.

With change monitoring, you no longer need to track your changes in spreadsheets, which a lot of teams do, and it's a headache. I've been there.

Gearset will take daily snapshots of your org's metadata, comparing each run against the day before and highlighting any changes.

Now this includes everything from custom objects and fields to layouts, permission sets, classes, and more. And it gives you a complete picture of your org's configuration at that point in time.

Once these snapshots are taken, Gear Set compares them with the previous snapshot and detects any changes made in the org. It doesn't just monitor the changes that you made through Gear Set either, but any change made in the org, even those made directly in production, although I wouldn't recommend doing that, or through other deployment tools.

Getting notifications for detected changes can happen via email or directly to platforms like Slack or Microsoft Teams, so that you quickly review and promote them upstream in just a few clicks, which helps keep your environments in sync.

Now Gearset's Pipelines feature is designed to streamline your CICD process, enabling you to automate that process of moving the changes from development to testing and finally to production environments.

It does this by creating a clear and structured path between those different environments.

You can start by defining a pipeline in Gearset, specifying the source, which is usually your version control system, and a target, your staging or production environments.

Once that pipeline's set up, Gearset will automatically sync those changes from the source to the target.

This means that whenever you make a new commit in your source control system, Gearset will detect it and prepare a deployment to the target.

But before those changes are deployed, they can be reviewed and tested.

It'll automatically run all unit tests and perform a suite of other checks to ensure that the changes won't cause any issues.

If the changes pass all tests and checks, they can be deployed to the target org, and that can either be done manually or automatically depending on your preferred workflow.

By automating many of those routine tasks assigned associated with deployments, Gearset's pipelines will speed up your release process and reduce the risk of errors. It gives you a clear, auditable, and repeatable process for moving those changes between environments, and it makes it an invaluable tool for Salesforce DevOps.

Gear Set also provides backup capabilities, allowing for both data and metadata backups, which ensures that not only are your records safe, but the structure and configuration of your orgies too.

This is especially important as many traditional backup solutions will only cover the data, leaving your metadata at risk.

Gearset will let you schedule your backups according to your needs. You can set up daily, weekly, or even monthly backups, and Gear Set will automatically take care of it for you. You can even get hourly backups for your most business critical objects.

So with many options on the market, it can be a little difficult to work out which one is the best fit for you.

So we've got some key questions to ask as you're kind of assessing solutions to work out what's the perfect solution for your team.

How much support do you need implementing the tool? Is it easy to get up and running yourself, for example?

Is the tool flexible enough to slot into your existing workflows? Ideally, you don't want to have to change your processes too much just to accommodate a particular platform.

How well does the tool integrate with the other services you use? Integration is a very important consideration in any new platform that you bring into the Salesforce world.

Can you try out the tool yourself with your own environments before purchasing license, or is it just a a prerecorded demo or a self contained demo?

How much visibility does the tool give you? Can you see what it's doing, why it's doing it, how it's doing it? Does it give you the level of some granularity and reporting that you need?

What additional functionality does the tool offer to your team? As we saw, you know, some tools will such as Gear Set will allow you to have backups and sandbox seeding and other capabilities more than just deploying your changes.

And finally, how much control over security does the tool give you? Can you limit who's doing deployments? Can you have a robust review process, for example?

All of these questions are considerations that you should definitely have as you're evaluating what tooling to use to automate your DevOps process.

So I appreciate that was a lot of content to run through in such a short period of time, but let's have a quick recap of some of the key takeaways over what I've covered.

So we saw how DevOps has become the industry standard for Salesforce development and deployment.

We saw how automation is an integral part of that equation, and a mature Salesforce DevOps process can't be reached without it, especially without CICD.

In order to start implementing that CICD, you need to be up and running with version control, and you need to have a reasonably good track record of successful deployments.

And there are generic and Salesforce specific solutions on the market that can help with a variety of automation tasks for Salesforce and particularly in DevOps.

If you're keen to find out a little bit more than I can cover in today's session, you can download the free CICD for Salesforce ebook from our website at gearset dot com, which will deep dive into these topics even further than I have today, as well as providing best practices and some great stats from across the ecosystem to help you benchmark your setup against others and measure how well you're now performing.

So thanks for listening, folks. Hopefully, you found something useful in there that you can explore further. And I shall hand back over to Ben to see if we've got any questions that have come up.

Great. Thank you so much, Rob. I'm sure a lot of people are rubbing their hands together at the, fact that they might not have to use change sets anymore with a lot of those features that that come with DevOps tools. So, yeah, thank you very much for for that overview. It was great.

I'll I'll just, I'll just wait with I can see some questions coming in now. So if you do have any for Rob or myself, please drop them in the q and a box, and we can get around to, as many as possible. But, Rob, just a question from from me to kick off. If if someone's, pretty unfamiliar with DevOps and, you know, is getting quite excited by a lot of things that you talked about, what where where can they learn more about, you know, version control and and DevOps in general?

That's a great question. So the two main places that I would generally suggest folks have a look, first is, a resource that we've put together called DevOps Launchpad, at the easy to remember devops launchpad dot com. That's a free training site, a little similar to Trailhead in that there's, little sort of select courses, there's modules, and a very sort of, self paced learning, completely free.

There's also some new certification tracks on there as well, so that you can validate and and improve out your knowledge. So, yeah, that's definitely where I'd send folks first, devops launchpad dot com.

And then secondly, I think is probably the the tried and tested Trailhead. There's some great content on there around, getting up and running with Git, understanding some of that process, looking at some of the tools on the market. Obviously, we've seen that Salesforce themselves now have DevOps center, which is a great place for folks to to move away from Chain Sets from as a kind of first start into DevOps. And as they grow in maturity, you know, they can start exploring some other tools that give those additional capabilities.

Cool. That's great. Thank you, Rob.

So I can see some questions coming here. So, one of the questions that's come through is how can you after you've implemented Salesforce DevOps, how can you measure the effectiveness of it?

So as a as a kind of wider sort of industry, look at DevOps, you know, across all platforms, not just Salesforce, there's a set of metrics called the DORA metrics, that are used as a kind of pretty much an industry standard for for measuring the effectiveness.

But I think, you know, some of the sort of key ones there, are your success rate. So are your deployments successful first time?

How long it is between deployments? So how often are you deploying there?

You know, do you have resilience? So, you know, do you have a good backup strategy? Those are kind of some of the indicative, metrics that we'd be looking at there. But what I would encourage folks to do as well as kind of exploring some of those metrics, it's it's I'll say they're called Dora metrics, d o r a.

But I think it's important to do two things as you you kind of look to to take those on. So one is to get the current state of your processes so that you know how far you've come. So benchmark. How often are we deploying now? How successful are our deployments? You know, what shape are we in today?

Then implement your DevOps processes, and then you get a much clearer idea. Has it made a difference? Is it improving things? So I think those are probably the, you know, the key indicators of of DevOps success that I steer folks towards.

Yeah. Great. Makes perfect sense. And I I think it's so important whenever you're implementing even a new Salesforce product is to take benchmarks of your current processes So you have something, you know, if you're implementing Sales Cloud benchmark, how many leads, you know, open pipeline, you've got that sort of thing.

So you've got something to, something to compare and contrast against, but that's great. Thanks, Rob. So we have a question about unit testing here. I I don't know if it's quite long, Rob.

I don't know if you can see it there. I'll I'll try and paraphrase it for the audience. With automated unit testing, can they be configured to test simple changes to page layouts, approval process permissions, or are they more meant for Apex and Flow based testing work?

That's a that's a great question. So, again, there's there's a few approaches to to testing on the Salesforce platform.

Seasoned developers and and and admins will know that Salesforce mandates a certain level of unit testing for for Apex code, which is, you know, seventy five percent coverage, and they must pass. But beyond that, I think we're we're definitely seeing an increase in the need for flow testing. There are some sort of beta flow testing, capabilities, or at least they were beta last time I looked at them. It's been a little while since I've played with Flow.

But I think, you know, historically, even before that, you know, peep some of the more sort of advanced projects were writing Apex tests that exercised their flows to make sure that they worked.

And so, you know, definitely, that's an approach. But then on the flip side of that, for, sort of more of the UI testing, things like, you know, testing lightning components, There there are frameworks that cover that such as, Jest, is is one of the sort of most common ones that we see, and there's definitely support for for doing some of that. In terms of kind of validating pure configuration changes like page layouts, you know, lightning home pages, etcetera.

There are specialized tools that will cover that, and do that kind of automated UI testing, such as, you know Selenium is is kind of one that's used in development generally. It's it falls into that not Salesforce specific, but can be customized camp. And then there's other tools such as Prova, which are very Salesforce specific, and we'll be able to do that UI testing. And it's important to realize that, you know, as part of your CICD pipeline, you would be including these in that pipeline process. So we talked about, you know, having these stage gates and these tests and validations, and you would look to configure, you know, executing those tools to carry that out for you.

Hopefully, that's covered some of those points there for you.

That's great. Thanks, Rob. We got quite a few questions coming in, and we do have enough time. So feel free to keep asking Rob, some questions. So, we've got one here, about, basically, can Gear Set deploy Omni scripts, which is a feature of Salesforce, industries or velocity. So how does that work, Rob?

Yep. So I I will put my hand up quite literally and and say that I don't know huge amount of, industries, Salesforce industries or or velocity as was. But I do know that we have quite a bit of support in gear set for that stack.

And I know that, you know, there are some kind of specialist areas where we've looked at that kind of area of Salesforce and made sure that there's suitable support.

But I I would encourage folks to perhaps, reach out to us separately on that one just simply because I I don't personally have the knowledge of of industries, but I I do know that, you know, we have quite a bit of cover for it. So you can either, drop a note over to us at team at gearset dot com or you can pop to the website. There's a an in app chat there, and response times are currently somewhere between five and ten minutes. So, you know, it some someone will be able to to help guide you on that one pretty quickly, and it's a human. There is there is no gear set GPT.

That is very speedy for human answers. I hope everyone get on that. There was a question that's been answered by Holly, actually, but I think it's quite a good one. Just to highlight from Vijay, it says, does gear set support back promote? Would you mind just giving us an insight into and the answer is yes. What do you mind giving us an insight into what back promote is, Rob?

Yeah. No. Absolutely. So a lot of organizations, particularly sort of larger teams, will have a situation where as well as going through the sort of standard development pipeline, you know, would be that, you know, via sprints or or any other mechanism, we'll also have a need for hotfixes.

You know, as as good as we all are, you know, the the unforeseen does still happen, and sometimes you will need to help fix something in production quickly.

And so by kind of doing that and having, you know, if you think about it in terms of your your pipeline and your your source control, you have a hotfix branch that kind of runs potentially straight into production. But you wanna make sure that those changes aren't lost with the next subsequent release.

So what we encourage is, back promotional back propagation. The the terms are pretty interchangeable, whereby, you know, the changes that are made upstream can then come downstream back to, you know, work in progress and development and merge with them so that, a, the changes aren't lost, and, b, you know, you don't necessarily have to kinda sandbox refresh all the time to pick up the latest changes, lose work in progress, etcetera.

So the good news is is that, yes, we do support that, particularly in our, gearset pipelines thing that we saw earlier where you've got that very nice graphical model of of where changes are sitting.

So we, yeah, we we can support that model. And in fact, we we quite encourage that. You know, if you are doing emergency hotfixes because reality happens, then, yeah, we want to make sure that you're still in the best shape for your ongoing development.

That's great. Thanks, Rob. There's one here which, might need a bit of explaining as well. But, how how are organizations handling blue or blue, green, or canary deployments?

Okay. So I will confess I'm not familiar with blue green deployments, and, I I suspect that Linden is far more experienced in DevOps on on that side of things. The Canary deploys, I'm gonna take a stab at as as an educated guess. So one of the things that Salesforce platform supports and thus, you know, Gearset supports is being able to validate a deployment so whereby, you know, you can see, will this deployment work before I actually commit to doing a deployment?

So one of the things that, again, we encourage, and I touched upon a little earlier in terms of that, you know, continuous deployment where we can have it automated or manual, what we encourage a lot of folks to do is a combination of two things for those deployments.

One is to make it a validate only deployment on at the automatic stage. So we can say, like I said, you know, will this deployment work were I to actually go ahead and push it to to production.

And then we would say, you know, if that is successful, then, yes, we can, we can go ahead and and and do a deployment. So based on the, you know, the analogy of a canary in the coal mine and, you know, and and sort of trying and and checking safety. I I that's my understanding of what a canary deploys.

More than happy to be corrected if I'm wrong, but that's I I think that's what's being asked there. The blue green deployment thing, I am gonna scurry off and and research after today's session. I think it's, it's it's a good thing to enhance my learning. So thank you for that question, Linden. I'll, I'll I'll go and do some discovery.

Thanks, Rob.

There was one here from Honda, for myself. Do do you see Salesforce use cases to use Omni Studio outside of the industry cloud? And do you think Flow and Omni Studio will merge somehow in the future?

Very good question. I mean, there there is a lot of overlap between Omni Studio and Flow, but also some distinct differences, which there's quite quite a lot to go into right now, but I think it's a very good point. I think Omni Studio has obviously been built around industry use cases.

So in the back end, you know, it might it might be quite confusing to to merge them together. I mean, Omni Studio Omni, Omni Studio and Flow are obviously two huge tools, with the same differences. So I probably don't see them being merged in the in anytime in the near future, possibly, you know, far ahead in the future. But, yeah, good question. Thank you, Hong Kong. I don't know if you've got anything to add there, Rob.

No. I think you've largely covered it. I think one of the things to kinda keep in mind with those type of, situations is that, you know, a lot of the more specialist functionality in Salesforce, has come by virtue of acquisition Yeah. Where, you know, they are entirely different engines, different platforms, and so the the process of technical integration of those platforms is a long time coming. You know, if we look at, the the capability formerly known as Pardot, I've I've I've lost track of what it's called this week.

But, again, you know, that was always kind of a separate, platform, you know, even a separate login. And then slowly but surely, we've integrated the logins. We can see some of the stuff appearing in in the core platform. The same with Marketing Cloud, you know, exact target as was. So I think a lot of these tools such as, you know, OmniStudio Industries, Velocity as was, you know, it'll slowly but surely start getting, sort of more sort of integrated into core platform.

Personally, I think Omni Studio has a potential to be more powerful than Flow, but at the expense of maybe having a higher barrier to entry and accessibility for new admins, than Flow has. So, yeah, it it's definitely an interesting one to see, kinda how that will flesh out.

Yeah. Nicely summed up.

So we are we're nearing the end of our session now. So if anyone does have any more questions for Rob or myself, please feel free to drop them in the chat, very soon. But, Rob, quick question that's come in. Is it possible to trial GearSet? And if so, how does someone do that?

Yeah. Absolutely. So we offer a free thirty day trial, via the website. Very easy to sign up on that one. Just go straight to our home page, and it's nice and easy to find.

And what you'll find with that is it's not a limited trial. It's not, you know, you can use it with your your real orgs. You can, you know or you could spin up a developer edition.

You can, you know if you've got developer sandboxes to spare, that's always a good way to, you know, to try features out. But, yeah, we we don't limit that in any way. And it's a full thirty days, so you get plenty of time to work with it, and learn it. You know? I appreciate not everyone's doing a deployment all the time just yet, although, hopefully, we'll get you there in that release early, release often cycle.

But, yeah, I, you know, I think that's probably the best place to, to to go ahead and and find out about that. You know, it's, it doesn't require anything installing on your orgs. You don't need to sort of set up any additional permissions.

You know, you can sign in with your Salesforce credentials or or a Google account or, you know, various other mechanisms. So, yeah, absolutely. Just go and explore it. You know, full disclaimer, I've I've been at Gearset for one year as of today.

But before that, I was, you know, an ardent user of Gearset for my own projects, and that's exactly how I started. I I started out on a trial and thought, this is really cool. You know? This is saving me so much time on my client projects.

You know?

And then, you know, as if by magic, I, yeah, I I liked it so much, I joined the company.

It's a great story.

So I'll I'll just pause a second just to see if any more questions come in. Lots of thank yous for the presentation, which is our pleasure. And what, what events are, gear set gonna be at next, Rob, or or yourself? What events will you be at?

Oh, oh my goodness.

So, currently, we have, some folks out at Texas Dreaming. So the the other DevOps advocate, big Jack, Jack McCurdy, is at Texas Dreaming with some of my other colleagues.

But outside of that, I am just looking up at my list now because I have a terrible memory.

We have London's Calling coming up, June the ninth. I shall be speaking at that one. Southeast Dreaming in Atlanta.

Forselandia in Portland in July, Midwest Dreaming in Minneapolis in August.

I mean, the list goes on. Hopefully, I'll get out to to see folks at Dreamforce and yeah. So there's there's plenty of opportunities there. And we've also got some more webinars coming up as well.

So in just two days' time, I mentioned earlier DevOps Launchpad. We have Launchpad live on, same time on Thursday, where I'll be looking at how we can get your deployment success rate up. So yep. Sorry, folks.

It it's me again. But, hopefully, you know, that'll be a a useful session. You know, if you're having challenges with, you know, your deployments not being successful first time every time, hopefully, I can help with that on Thursday. So, yeah, pop to dev ops launchpad dot com, and, we'll we'll get you up and running.

Great. Alright. Thank you so much, Rob. I think we'll wrap up there. So if anyone does have any more questions, feel free to email. It was team at gearset dot com, I think, Rob. Yep.

Spot on.

Yep. Yep. Feel free to email that. So thank you very much for everyone for attending. It's been a really cool session. I hope everyone enjoyed it.

We got we got a lot of interest and a lot of people on the call, so really appreciate you spending your time with us.

Any final words before we hop off, Rob?

I've just popped in the chat as well. If folks have any more questions, they can also reach me on Twitter, Rob Salesforce.

More than happy to to have some fun threads and discussions on on Salesforce DevOps there too.

Great. Thanks a lot, Rob. See everyone soon. Thanks, Ben. Take care. Bye. Bye.