Description
Salesforce is an incredibly powerful and fast-growing platform. By pioneering the Software as a Service (SaaS) model, it has enabled thousands of businesses to improve their operational efficiency and grow their sales. Adopting a company-wide platform is not without its challenges. Managing change and avoiding conflict in a system where end users, as well as development teams, are encouraged to edit the production environment requires a planned approach and effective information management. That’s where Gearset can help.
Catch up on this webinar where Kevin Boyle, Gearset’s CEO and Co-Founder, shares insider tips on why you should consider moving away from change sets or ANT to run your deployments, how to avoid the common pain points, and the steps to move towards an automated continuous integration release model. We’ll also demonstrate how Gearset, our Clone Inbound Change Set feature, and our test runner, can simplify your releases.
Learn more:
Transcript
The webinar today, is about, you if you use Chain Sets or AMP at the moment, how those tools work, and how Gear Set might be able to simplify, some of your Salesforce release challenges.
Just before we, start, do a quick introduction to who's speaking to you today. So I'm Kevin. I run the team here at Gear Sets.
So a jack of all trades.
Feel free to ask questions throughout the webinar, but if you have anything that comes up afterwards, feel free to tweet me, Kev from Ireland, or else reach out to me on LinkedIn or via the the Gearset website.
I'm Jason. I look after the business development side of things at Gearset. You've got my Twitter and LinkedIn contact details there on the screen. So, similarly, feel free to reach out if you've got have any questions after the webinar.
So before we dive just straight into, talking about Salesforce release challenges using Change Sets and Ant, I think it's important to acknowledge just how mission critical Salesforce is in our organizations.
It's the right definition of mission critical software where, you know, as software developers and admins, we we get to have a pretty big impact in our organizations no matter what we do or where we work. But with Salesforce driving your sales team, your service desk, your marketing activities, mistakes in Salesforce can cost real money to your organization and, you know, a very measurable impact.
So it's important to have a good release process with Salesforce to make sure that bugs don't get through to production.
That said, it can be very difficult to have a good release process with Salesforce.
It can be very hard to deploy things, reliably, robustly, and in a way that you understand.
And when mistakes do happen, it can take hours for that fix to get through unit testing, to get actually into production. So it's important that bugs bugs don't make it through.
Salesforce is also a complex beast.
It, manages your it models your entire organization. It models your sales process. It models your HR process, possibly. It models everything, and organizations are complex, and that's reflected in in Salesforce.
So I think fully established that Salesforce release management is critical.
Some things that make that extra challenging, Salesforce encourages users to make changes in production. It's kind of the power of the platform is that users are empowered to make that. And that's a great thing that we don't think you stop. We don't think the process of release management should, you know, tie your hands in any way or restrict the power of Salesforce. But it does increase risk. And a good release management process provides a framework for controlled change. Your deployment tool underpins that entire release process, and so it's important that you understand the pros and cons of what's out there.
So the Salesforce deployment tools that we're going to look at today that are out there are the two from Salesforce themselves. So you first of all have Change Sets, and then you have the Force dot com migration tool, or commonly referred to as Ant.
So we'll talk about the pros and cons of each of those, and then we'll sort of dive into where Gear Set might differ.
So Change Sets, really optimize around that very quick, easy to use use case. So they prefer click not code.
Admins love this. Well, I say admins love this tool. Admins use this tool a lot. I'm not sure love is the correct word. It's convenient for very quick, simple deployments.
One of the great things about it is it's accessible from anywhere. It's cloud based in Salesforce, and it runs all of your unit tests for you. This is the thing that people most commonly use, or certainly as they begin to do, Salesforce release management, you tend to start with with change sets. What you quickly run up against is some some serious problems with change sets, though, or some limitations that are sort of, kind of a reflection of what it was designed for. So first of all, there must be a trust relationship between two orgs that must be connected, which can make it a little bit tricky to do that nice release pipeline.
You have limited granularity. So if you want to make changes to different object types or within an object type, like, if you want to do something like fine grain profiles or permission stuff, that can be really, complicated with change sets or just not possible. So an example of something that isn't possible is deletions or destructive changes. Just isn't supported with change sets. It's kind of designed for that my first Salesforce type experience, nice and simple. And I guess deletions are viewed as something, you know, you don't want within the hands of of ordinary users.
It can be very difficult to set up that pipeline, as I said. So when you have an inbound chain set, it's hard to convert that into an outbound chain set. So if you find yourself going from a development environment to QA through UAT and through production, it can be very labor intensive to constantly have to recreate that chain set. So although it's convenient to use and it's in the Salesforce UI, it can be a lot of clicks. And if you have a large org, clicking around between pages and pages of components as you add them to a chain set and doing that for each of your environments, that can be, you know, an untrivial amount of work.
There's obviously some problems around automation. So you've got a lot of manual post deployment steps. And we find that people that use change sets heavily also tend to rely on other tools like Excel or a spreadsheet just to have a list of things that you do once your change set is applied.
And no support for source control. So some of the audit problems, some of the audit, capability you might want when it comes to change sets just, aren't there.
So a quote from one of our customers that, now uses gearset.
Gearset that moved away from chainsets is around that manual configuration for deployment that, needing to handle things like profiles, pick up value changes, and custom settings manually. So they do a change set, make the deployment, but then find they have a load of stuff to do extra. And that for people with a tight, deployment window, these guys worked in the healthcare industry, that that can be very difficult to work with and manage.
So the second tool that Salesforce provide natively is the force dot com migration tool, otherwise known as Ant.
This is a very different tool from Change Sets, but has a similar set of advantages and disadvantages.
So on the on the pros, Ant gives you the ability to work at a very fine level and to edit the XML to produce exactly the deployment package that you want. So it's a command line tool. It's downloaded to a local machine, and you run it there. And it's extremely powerful. It supports almost every change that you can deploy via the metadata API, and it's fully supportable to be automated as well. So if you're using something like Jenkins to kick off a CI workflow, you can integrate that nicely with Ant.
It also has support for version control as you can deploy and make changes straight from a folder on the disk. So you can check that out check those out from your source control system and go from there.
The other advantage of AMP is that you can deploy between all organization types. You don't have to set up any prior prior linkages or relationships, and you can just use it to deploy anything to anything. So it's a very powerful tool when you put it in the right hands. But it also has a set of limitations.
So as I mentioned before, it's command line based, and that can be pretty scary for people who aren't familiar with how to manually edit XML. The screenshot you've got on the right there is a a typical short deployment. And if you don't know what you're doing there, it can be very easy to get lost and just completely give up.
You also have to run manual code diff. So if you want to view the differences between your two orgs before you kick off your deployment, that's a manual process, and that usually requires a third party tool, which can be slow and also error prone.
Now with Ants, you build the deployment packages yourself, which can be a benefit if you're looking to edit the XML, but it can also be a source of error. Manually editing files yourself is a good way to miss small amounts of syntax or a question mark here or there, and that can cause your deployment to fail with some pretty opaque error messages.
It also requires iterative package creation. So with Ants, there is no automatic dependency analysis. There's no way of knowing exactly what you need to include in your package aside from prior knowledge. And a lot of our customers find that they have to repeatedly deploy their package, fail, and iterate, and include more dependencies before they can get it to succeed, which is quite a slow process.
It also lacks reporting. And because it's downloaded as a local machine build, it's not suitable for remote working. So you can't just log in from anywhere to access your history.
We've got another quote here from one of our customers, something to do with Ants, just mentioning some of the problems they run into in terms of iteration and the tediousness associated with building those packages.
You we also find that for some customers, the complexity of ants and the fact that it's inaccessible to their admins can drive a wedge between the release processes of the two different teams, and that can be really difficult when it comes to reporting and also managing the change process.
It can also be extremely difficult to set up in the first place. So change sets is great to get begin with, but to get started with AMP, you need either an experienced Salesforce dev or often the help of an implementation partner to get you going.
So as a brief summary of the ups and downs of chainsets and ANTS, chainsets is great to get started with, and it works for small organizations extremely well, but it has a few key limitations over the functionality, and it doesn't scale well for larger or more complex systems. Ant, on the other hand, is extremely powerful if you use it correctly, but it's complex to use. It's inaccessible to people who aren't familiar with code, and for many people, it can be an over engineered solution.
So a lot of people in Salesforce aspire to a better release process. The idea of ALM or application life cycle management is widely known and adopted outside of the Salesforce world. And there's a lot of benefits of doing this. It helps speed up your project delivery, it reduces risk, and it increases the collaboration between your teams.
It also allows you to move towards a more agile release process where you work in short sprints, promote your changes up from a dev environment through to staging and production, rather than holding back six months of work and pushing it all across in one big bang.
The problem with change sets and AMP is that they lack the real functionality to enable you to move to a true ALM workflow in the Salesforce environment, and this can be a problem for a lot of people.
So what we've got here is an example of what many people aspire to in terms of an ALM workflow.
You have your team of devs working in separate environments.
They once they finish their changes, they push those up through a source control system. And Through a continuous integration, that gets merged into an integration or a QA testing environment. This is often a partial copy sandbox in Salesforce.
Once those have been tested, they then get promoted manually through to UAT or staging. And then finally, once they're ready to go, they get promoted into production.
Now moving this process through with other chainsets or AMP is extremely difficult in the current Salesforce environment, and that's where we think there's room for improvement.
So how does Gearset fit into all of this?
Well, a little bit of background about Gearset. For those of you who don't know us, we launched back in Dreamforce back in September twenty fifteen. You see a photo of us on the booth there. And we've been making rapid progress to make to revolutionize the way that Salesforce deployments are run. We believe that there is a better way that you can run deployments. They could be faster, they could be simpler, and they can be more effective. And we're hoping to increase our reach and bring Salesforce bring Gearset as the de facto Salesforce release management tool.
So So what can you expect with your release management by moving to Gearset?
It's simple, but also powerful. Gearset is an entirely user interface driven service, so you don't have to know coding, but we also don't limit the functionality of what you can do.
It's fast and repeatable, so you can run your deployments quickly and repeatedly.
It's also reliable. It'll help you improve the deployment success rate through intelligent change management and problem analysis.
We also have good audit and reporting, so every report you every deployment you complete is reported, and you can easily share those with your colleagues. And finally, it scales well.
Gearset has been designed to help collaboration for both small teams and large and work for organizations of all sizes.
As a little extra here, one of the, most common requested idea exchange suggestions to do with cloning inbound change sets, which is a real blocker for many people who want to move through a true ALM workflow. We're gonna show you how to solve that using Gear Set today.
So demo time.
I'm just gonna walk you through a quick demo of how to use Gearset to build and deploy a package between two organizations, and then give an overview of how to promote this across and look at some of our monitoring and ongoing testing.
If you want to see a full demo in a lot more detail of how to use Gearset, then our previous webinar where we talked about the importance of release management has a much longer session on that, and you can view that on our YouTube channel.
So to get started, I choose a source organization and a target organization, and I'm gonna run a comparison between the two of them to see the metadata differences.
By default, we choose the default metadata set, but you can also choose your own custom sets to exclude certain metadata object types.
You hit compare now to start the comparison, at which point Gearset downloads the metadata from your source and your target org. And we start to pick apart the large objects and look at the dependencies and relationships between them. So for things like profiles or permission sets, we don't just treat them as one large static object, but we break them apart, and we actually look and pass the XML as well as giving you the visual diff of your two orgs side by side.
We do all this by the Salesforce metadata API, which is the same system that AMP uses, but we also add a lot of our own, unique analysis on top of that.
So you got the results of the comparison here. At the top half of the screen, I have the objects in my orgs, and in the lower half, I have the line by line visual diff of the code between my source on the left and my target on the right. So just as a starting point, this gives you a great way to understand what the differences are between any two orgs at any point in time. You can see who made the changes and when they were made, and you can easily understand exactly the state of these two.
For this quick demo here, I'm going to grab this custom field of a pick list value, and I'm gonna promote this across from my source to my target. So all I do is I select the objects I want to include in my deployment package, and I hit next.
Gearset then runs our problem analysis to look for anything like missing dependencies.
And if anything is found, then we'll help you resolve those issues as quickly and easily as possible.
Once you get to the summary page, you get the summary of the objects to be included in your deployment package. So I have my four objects here. I can enter in a commit note for the reporting. So I will call this webinar deployment.
And at this point, you can download the package if you wish to keep a copy of that. You can kick off the deployment immediately, or we also support the creation of validated deployment packages, which is what I'm gonna do now.
So in this case, what we're doing is building your deployment package, sticks to stitching together all of the XML, and then running a test deployment against your target org. And this allows you to test whether your deployment package is going to succeed without actually pushing it live.
This can be really good if you know you have a set, deployment window during a maintenance window overnight or on the weekends, and you want to test your package prior to pushing that live.
So once this has been validated, I know that this is gonna push across successfully. So I go ahead and hit deploy now to kick off the deployment.
So we do the usual upload process to Salesforce. We run all of the associated tests. So you have your seventy five percent code coverage if you're pushing to a production environment.
And we then provide you a report once the deployment succeeds, showing you the key information about the source and the target, the objects you pushed across, and the test results.
This is automatically emailed to you, and if you just click download here, you can grab a copy of this report as a PDF. So you have an instant audit trail of exactly what objects you pushed across, when that happens, and who made those changes.
Now one of the key points we mentioned earlier was promoting the same change between your organizations as part of the true ALM workflow.
And this is something that you can't currently do with changesets.
So what I'm gonna do, I'm gonna jump across to deployment history where you can see all of my previous deployments have been stored. So everything you do in Gear Set is automatically recorded, and you can use it to go back and grab copies of these reports for any previous deployment.
But let's say this package I just pushed across now, I want to then clone this inbound chain set. All I do is click clone package, and I choose my source and my target organization to push this between. So I choose, example here, my dev and staging.
And when I hit run comparison, GearSet will automatically rerun the comparison between these two orgs. It will then automatically reselect the objects in my package and take me across to the summary screen. So you don't have to manually go through, reselect your objects, you don't have to rebuild that package, and it can be a really great way of saving time and effort by promoting this package throughout your organizations.
Now on the second half of Gear Set, we also have the ongoing monitoring and testing.
The monitoring tab here is a way to keep an eye on the drift and ongoing change in your orgs over time. So a common problem for many people, especially when you get to larger teams, is that undocumented changes in your production environment can go unnoticed. And at a later point when you kick off your deployment, they can then cause your deployments to fail.
So by setting up a change monitoring job in Gear Set, you can eliminate that and always be aware of everything that's happening in your orgs. So if I jump into the view history here, for any org that you set up a comparison on, you can see at daily intervals all of the metadata changes that happened in that day. So for a change history here, I have the days where nothing's happened in my org and a few days where people have made changes.
And if for any of these days, if I want to inspect exactly what happens, I can view the comparison to see the complete summary of all the objects that have been modified during that day and who made those changes.
So if you weren't expecting any of these to be pushed across, you can easily track down who's been making changes to your org and what they were. And if you are expecting them, you can use this to validate that your deployments have happened as you expected.
Now this change monitoring covers all, changes no matter how they were made to your org, so you don't have to use this purely to monitor your gear set deployments.
We also have a similar test automation feature, which runs the unit tests in your org on a daily basis and shows you a summary of your test passed and failed along with your code coverage.
Now for both of these jobs, you can set notifications to get notified when they happen. So you can either get emails, text messages. We also integrate with Slatter and Check for the ongoing background noise as to how your logs are changing over time.
So that's the end of the quick demo. If, as I mentioned earlier, if you want to see a demo in a bit more detail about how some of the dependency analysis works or the other features of Gear Set, then you can view our previous webinar for a bit more information on that.
Just gonna jump back to our presentation.
Yeah. So one of the things I like is to hear what customers of software actually say.
So we call it case studies, which we have put up on the website, where, you can find out from real customers how they've actually used Gear Set and what part of the release management process it's helped with.
But I've just got a few quotes. And so as someone's been leading the team, this is really great to hear that people are really starting to rely on Gear Set. That's one of the quotes that jumped out at me. They're starting to rely on it to drive quality, you know, lowering that barrier for resource to execute complex deployments.
And we focus on, making Gearset as easy to use as possible. So one of the things that's really affected our team from that Salesforce do is sort of customer success mantra. And it's great to see that Gearset users are finding it incredibly helpful. The monitoring's been well received. And this final one around the time savings with Gears seven are extraordinary. That was from a healthcare client where they reduced their deployment window from about eight hours, they set aside, which obviously meant they only deployed maybe once every two weeks or three weeks because it took so long. And they reduced it down to around forty five minutes, so massive savings.
So the roadmap for Gear Set, we're working hard on iterating the product, again, based on customer feedback. So a great chunk of this road map has come from from our users.
Some of the stuff we've delivered in q one around that, test monitoring, better deployment reports, the status alerting, by chatter in Slack so you can set up jobs. But just keep your team that's an ambient knowledge. Keep everyone on on your team aware of what's happening on production.
And those validated packages as well was a highly requested feature.
Some things that we're still planning for this quarter, around team sharing. So if the reports are easy to share with your team, the idea is that it'll you guys will collaborate better. So let's let's look at there, and you can see that at gearset dot com slash roadmap.
So key takeaways from today, just before we open it up to some questions.
Chainzets and AMPs, they're both great deployment tools. You know? They're great at what they'd be designed for. But unlocking major benefits of having a great LAM strategy in Salesforce does require something else. That's what our customers are telling us, and that's what our own experience at Salesforce has been.
So what you seek is predictable, agile delivery.
It should be easier for teams to collaborate.
You want a clear audit trail, so for compliance, if it's a regulatory environment, or just for team collaboration, being able to understand why changes were made, what business case was it that drove a change, And for presiding for, providing insight into your orgs, so as your team grows, as you get teams across time zones and regions, it can be really important to, understand how those changes are occurring.
Gear Sets, the only Salesforce release management tool designed to be both accessible and still powerful. We focus on simplicity of in the UI. We want to scale to some really complex teams. And we're the people that are really taking feedback from users and have a strong desire to constantly improve.
So let's open it up with some questions. Hopefully, in the little corner of your chat window, you should be able to see, questions section.
And, feel free to just type anything in there. Jason, you want to read the question?
Sure. So we've got one here from Rob. I typically have to gate or stage releases to be pushed to a production org where I have multiple packages that need to be deployed in a specific order using Ants.
Does dataset allow for grouping packages for a release candidate or custom app?
We don't yeah. It'd be interesting to have a chat when we send you an email after webinar to dig into that, as to why you have multiple packages.
So short answer at the moment, we don't yet support that.
But we'd love to know why you do it. So I'll reach out to you after the webinar if that's okay.
Any other questions?
Just give people another two seconds or so just to, get a chance in.
Okay. We got one from Harry. Hey, guys. So the deployment package, once I've built it, can I deploy it to any org?
Yeah. Absolutely. That clone feature that Jason showed off, that's between any two orgs. So one of the limitations that our customers told us from change sets is the needs of that trust relationship and recreating packages is a is a real time sync.
So Gearset works any two orgs. We allow you to connect via OAuth. That just registers it with Gearset. There's nothing to install in the org, or we have no impact on the org.
So you can try Gearset, use it to do a few deployments. If you don't like it, you you know, there's no lock in there. But for the cloning packages, sending things through that pipeline from dev to QA to UAT to production, yeah, it's any any combination of any of those.
Okay. Any more questions? We'll give it another ten or fifteen seconds, and then I think we'll move on to the wrap up.
And as before, feel free to reach out to us at team at gearset dot com. Or if you're using the product, you'll see a chat window on the bottom of, of the Gearset app that you can reach out to us. And we we love speaking to users, so, you know, if you if you have something to ask afterwards, feel free.
So I wanna thank you for attending the webinar.
For more information, you can contact us, team at gearset dot com, or visit gearset dot com to start your free trial. We'll send you an email afterwards. This webinar was recorded. And if you have any other questions, just please do get in touch.
Thank you very much.
