Description
In this webinar, adapted from our CEO Kevin Boyle’s presentations at Dreamforce, we explore techniques for deploying changes to Salesforce, from quick fixes to well-developed ALM strategies featuring continuous integration with automated deployments. Even in the world of No Software, engineers still need to collaborate in order to get the most out of the platform.
By the end of this session, you’ll understand the options available for managing releases, how to organize your developers, and what best practice is for Salesforce development teams.
Learn more:
- A guide to Salesforce application lifecycle management (ALM)
- What’s the best development lifecycle for Salesforce?
- Gearset’s Salesforce metadata deployment solution
Relevant videos:
Transcript
Awesome. So today on today's webinar, we're gonna talk about Salesforce release management.
We're gonna go through a few different approaches that you can take, and we're gonna show how Gearset can fit into that flow. This is adapted from a presentation that I did at Dreamforce. We've added quite a lot of new stuff since then as well.
So a little bit about me first. I'm Kevin, and I'm the team lead here at, Gearset.
Feel free to ask questions throughout if you if you have any questions. But otherwise, follow me afterwards on Twitter or LinkedIn and, just drop us a question.
And I'm Jason. I look after the business development side of things at Gearset, same as Kevin, really. If you wanna reach out, if you've got any questions, then you can get my Twitter or LinkedIn address on the screen there.
So Gearset's part of a larger company called Redgate.
Redgate are the leaders in release management for database platforms, and we've been that leader for the last fifteen years.
So we sell, tools for migrating changes, on SQL Server, Oracle, MySQL, and a range of other platforms.
And around three two, three years ago, we became a Salesforce customer.
So we got rid of our, homegrown CRM that was kind of, a bit rubbish and replaced it with Salesforce.
And the team that did that development work and did the migration, they absolutely loved the fact that we could delete seven hundred, eight hundred thousand lines of code. We could migrate twenty three gigs of data and put that under somebody else's, jurisdiction with backup and monitoring and all the stuff that we love about Salesforce.
The thing they definitely did not love at the time was some of the sort of software development life cycle issues that Salesforce brings in. So it can be really tricky to do grown up development with source control, continuous integration.
And some of the things that really developers and collaborators, on a development team take for granted. So from that, Gearset was born. We decided to try and bring some of our release technology and some of our deployment know how to the the world of Salesforce.
Fast forward, I think at this stage, it's twelve, thirteen months, and we launched at Dreamforce back in September in San Francisco.
People absolutely loved it, and we've now got, you know, a growing stable of customers that are using Gear Set, dropping it into their, their production environments and using it, day in and day out.
So when we brought our technology from SQL Server and Oracle to, Salesforce, we didn't wanna just assume that it's the same. We wanted to speak to as many people as we could to understand what makes Salesforce different, what makes it a challenging environment, why do people struggle with, deployment and release management on Salesforce. There's a few different reasons I'm gonna I'm gonna jump into now.
The first is that as software engineers and as developers and admins, we get tremendous privilege to make a big impact to the companies that we work for. But Salesforce is the very definition of mission critical software.
It cannot go wrong. So if we make a mistake, that affects our production org, that takes down your sales team or your back office staff. That has a big impact on the top line for your company.
That said, Salesforce is, you know, production mission critical. So when it goes wrong, you need to fix it, and you often need to fix it in a real hurry. So you tend to patch things up like this guy is doing with a bit of cement.
So what that means is there's often situations where you've made a change in production, you fix something up because you had to fix it right this second, and then later, you do your regular scheduled deployment at the end of your sprint, and you overwrite that change in production.
So those changes in production, they're great. It's some of the power of Salesforce, but it can also lead to, to challenging challenging deployments.
Another issue with Salesforce is the visibility into what different teams are doing.
So you can have an admin working in production, our two dev teams working in parallel on streams of work in their development in the orgs. Both doing a really great job, but then when you come to bring them together as all software you find they don't quite fit and there's integration challenges.
So Salesforce makes it quite difficult to, you know, share the visibility and the insight into what different teams are working on, and that's one of the things that can make it challenging.
One of the other problems with Salesforce is that it gets quite complex. Once you start to model all of your business process, once you start to bring all of your business data into Salesforce, businesses are complex, messy things, and Salesforce can end up that way as well.
So you think you're making a small local isolated change to, something in your Salesforce org, and you find out very quickly that that, goes through a few nexus objects and nexus types, and all of a sudden you're trying to reason about permission sets and profiles when all you really wanted to do was add a field to a custom object.
So at Gearset, we have opinions on what we think a really great release management process would look like.
We think it should be really easy to use. So the idea that you have to sit up, on a Friday night, like four AM to do an appointment just so that you have the rest of the weekend to actually get it to work and to debug it, We we don't think that should happen. We also don't think there should be anybody that's special on your team that has to be responsible for releases. We think it should be just a team activity that anyone can do on any day.
You should have confidence in your release process. So it shouldn't be a special activity. It should just be something you can do. You know, I'm gonna deploy something today.
It's gonna work, and I'm gonna move on with my day.
You should have predictable results. So if you wanna deploy a custom field or, you know, some some change to workflow, you should be able to do that, and it should work as you expect.
And finally, we should try and automate any of the bits that are annoying. So we all have to do compliance and audit and reporting, and you should, and those are good things. But they're not really why I go to work in the morning. You go to work to actually help users, and a little compliance and audit's important. It doesn't doesn't really help our users. Computers are better, that sort of stuff, than we are.
So, on GearSat, we've been in this journey over the last year speaking to lots and lots and lots of users, about their release force sorry, their release management sales force, and we think you go through a bit of an evolution.
And the evolution's really around levels of complexity, sort of how big your team is, how complicated your org is, and how many different environments you have.
So let's sort of look at the different levels of complexity.
First of all you have individuals.
They probably have a single org to themselves. They're not working in a team so they're probably just making changes directly in production.
You now have small teams.
The way small teams tend to work is you have one sandbox for developers, probably a full sandbox with all your data, and they're just making loads of changes there, and then they use change sets to push all those changes over to their single production org. And finally we think when you get to a large team, you tend to have developers that are working in individual developer orgs. They share their changes via source control, you have some automated process running somewhere that does automated deployment to staging or UAT orgs, and then finally that manual push to production org normally on a nice cadence as part of an agile process.
So let's look at some of the pros and cons.
For individuals that have no release management, this works really well. You don't really need any additional services. There's no overhead. You're sort of master of everything you do, and that's, you know, that's a that's a big pro.
But there's some major cons to this as software projects over the years have taught us. You can re sorry. You can really easily introduce bugs. As I said earlier with Salesforce being mission critical, if you introduce a bug into production org, you can cost your company real money.
There's no audit trail for changes, so you make a change because it was requested by a business user, you do a good job, you make that change, and a year later, somebody asks you, why did you make that change? It can be very hard to remember what actually drove it.
Everything is in one person's head, so the bus factor for your organization is bad. If you go or move on to another company, you know, the next person coming in won't understand the decisions and design decisions that you made.
There are things you can and shouldn't change in production, so having a separate org for that is important. And really around all the manual stuff, all the manual steps that are involved.
Just make this even if I'm working individually, I still want some process. I still want release management.
As you move towards small teams, you start to introduce some basic release management.
You probably have one developer org that all of your developers share together making changes in, and then use change sets to push that to production.
This provides a nice balance and complexity, so you have some isolation between developer and production.
It helps catch bugs because you make those bugs in your dev environment, which means they didn't happen in production, and it enables basic team collaboration.
So if I'm working on an object, I'm probably sitting next to my colleague, he's probably a friend on the same team as me, and I can just turn around and shout over to him to tell him what I'm doing.
There's some cons to this approach.
The biggest that we hear from everyone we've spoken to is that it's really very easy to trample on each other's work.
As I said, there's often some objects that are sort of more important than others that all work tends to flow through, and you can make a change, and then a week later your colleague makes a change and you've lost your work.
It can be hard when it comes to deployment time to know which changes should be added to a package, particularly if you're doing parallel streams of work in the same org, then Feature A is finished a little bit ahead of Feature B, You come to build that package. Which of these changes were in feature a and which were for for feature b? It can be hard to know. And again, you still have lots of manual steps, particularly around audit and reporting and capturing what changes were made.
So we think what you eventually get to is integrated release management, and this is what works best for large teams.
This is the best way to manage your releases. When we have found teams that actually do this and have this set up and working for them, there are almost no disadvantages from the team or business point of view. It provides really clear audit trail because you're probably sharing things via source control system.
You know, through user stories what the who requested who in the business requested the change and what caused it to be made.
And finally, teams tend to love this stuff just because automation removes manual steps. Nobody wants to to do the kind of manual tasks again and again that are by error prone.
The only cons from this, for this approach are that it can be complex to set up. So you probably got lots of moving parts to maintain now. You've got a CI server in the version in the form of Jenkins. You probably get some version control, like Git or Mercurial or some version, and all of this stuff just becomes expensive and, hassle to maintain yourself. The whole promise of the cloud was that we'd get away from having to manage all of this stuff ourselves. So it's nice to get all that out of the building.
So let's sort of look at that final evolutionary stage.
Visually, You've got your development cycle. This is all your developers have their user stories, they're crunching through features, they're doing great work. They're probably doing that if you've got a really grown up process in their own isolated DevOps, and they can make as many mistakes there as they want. Once they're happy with the work they have done, the configuration change or the code change, they share that with their colleagues via source control.
There's some automated process that runs continuous integration that picks up those changes from source control, and on either regular cadence or on a continuous integration basis, deploys that to your integration, testing, or QA environment.
Then either automatically or semi automatically, those changes are deployed up to your UAT environment, your user acceptance testing. And that's for your business users that had the original change request. That's where they get to test it out. They get to decide, oh, this is exactly what I wanted, or no. That's not quite right. You gotta push that back toward development.
And finally, you have that, manual step where you push from UAT to production. At this stage, you know it's right. The business has verified that it does what they want. The code's been verified through code review and unit testing.
Nice, smooth sailing from UAT to production.
So what we're GearSat doesn't do quite all of this today, but Jason's gonna hand over to Jason. He's gonna do a demo showing what we do do, some of the features of Gearset, and what's coming next.
Thanks for the introduction, Kevin.
So as Kevin mentioned, GearSet is a tool that we designed to be a complete loose management solution for Salesforce.
Now there are a few features which I'm going to go through just after the demo, which are currently on the horizon for our roadmap. But But to get you started now, I'm going to show you a demo of what you can do with Gearset and how you can use it to achieve the streamlined release management.
So you get started by just going to gearset dot com and you hit try it now.
We have a thirty day free trial, so Anyone can sign up, there's nothing you have to install on your orgs, and there's no commitment or payment details required. If you do want to try it out, then I encourage you to just try it out for yourself and let us know how you get on.
You can log in with your existing Salesforce or Google credentials.
So I'm going to log in with Salesforce here because I've got that set up, and this takes you to the starting page of the app. So the main workflow for Gearset is you pick a source organization and a target organization.
You then run a comparison between the two of them, and Gearset will show you a visual diff of the code differences and the objects between those two organizations.
You can then build a package intelligently using Gearset's dependency analysis and problem analyzer and then finally move on to deploying that to your target organization.
Gearset then keeps track of your deployment history and automatically generates an audit trail for you as well as having an extra functionality to monitor the live changes to an organization over time.
So the first time you get started, you simply enter the username here for the organization you want to connect to, and you select the organization type. So we support both developer, sandbox, and production orgs.
Once that's been entered the first time and hit authorize, this connection automatically gets saved for you so you can come back to it a second time very easily. So I'm just going to save here. I've got an example development environment, and I'm going to compare this to an example staging environment.
So before we started this webinar, I made a quick change in this source organization here. I just created a new picklist value, and I'm going to use gearset to compare that to my target organization and run a deployment.
Now if you just hit compare now, you can run a full comparison of all the metadata types between your organizations.
You can also customize it here by clicking customize comparison.
Now what this allows you to do is if you know that you've only made changes to specific metadata object types, so say, for example, I have only chosen Apex classes, you can deselect the objects you don't want to look at and only include the ones that you're interested in. Now this not only speeds up comparisons, but it also makes it a lot easier to understand to find the differences you're looking for when you compare your two orgs.
I'm just going to leave this on the default profile for now. I'm going to hit compare now.
So this kicks off the comparison. What Gearset's doing in the background now is it's logging into your source and your target organization and downloading the metadata.
We do this using Salesforce's own metadata API. So if any of you have ever used, the force dot com migration tool, then it works on exactly the same principle as that. But beyond just downloading the metadata, GIS had also applied some intelligent analysis of it. So we don't just show you the raw XML difference. We actually pass them, and we understand the relationships between your objects. And this allows us to do things like dependency analysis and help you build up packages, which are going to work first time rather than repeatedly failing your deployment and doing problem analysis on them.
So once your comparison is complete, you'll be presented with a screen which looks a lot like this. The top half here, this contains the objects that are in my organization.
I can click on any one of these, and then in the lower half of the screen here, you get a nice visual line by line code diff of the objects and the differences between my source environment on the left here and my target on the right.
The pick list value that I mentioned just at the start, you can see we render these actually nicely, but you can also switch back to the WARA XML if you like. So you can see there's this new webinar pick list item I've created here in my source, which doesn't yet exist in my target.
For all of the object types, we show you when they were last changed and who made the changes on them, which can be useful for tracking, who you need to talk to.
And we also group the changes by type at the top for easy logical grouping.
So at the moment, I'm getting changed objects, which exist in both my source and my target. You can also view new objects. So these all exist in my source environment, but not yet in my staging. So I've got a couple of Apex classes, an email folio, and an email template here.
And we also handle destructive changes through exactly the same workflow. So for those of you who have used change sets, this is a process which is just not supported using a change set. With Gear Set, we treat it exactly like any other change, and you can just delete changes through the same workflow.
So to give you a bit of an idea of how the some of the intelligence and the unique aspects behind Gear Set beyond just showing you the comparison, I'm going to show you a brief example of dependency analysis.
These two objects here have an email folder and an email template.
If I click the little arrow next to the email template, I can actually expand this out and view a tree view of the dependencies associated with that object.
So I can see here not only what the object is, but actually, GISS has identified that it depends on this email folder.
Now beyond just showing you this, which would be useful for interest, we actually do a problem analysis phase before you run a deployment which will catch these dependencies for you.
So to demonstrate this, if I just select the email template here and I hit next, before actually putting the package together, Gear Set is now gonna look for anything which is gonna cause problems with your deployment. So not only do we cover things like missing dependencies, but we also cover some of the the quirks of Salesforce, so things like master detail relationship fields, history tracking, and quite a few others as well.
You can see here that Gearset has analyzed the objects I selected, and it's found out that there's a missing dependency of this email folder.
Now all I have to do to include this in my deployment is just tick the box and hit next. And now you can be sure that this deployment is not going to fail because GearSet has found this dependency for you.
Now, this is a nice simple example here with an email template, but we do this for a significant number of the object types, and this includes things like profiles and permission sets. So we break down those large objects into their constituent components, and we'll be able to tell you exactly which parts have changed, which haven't, and which you need to include in your deployment to make it succeed the first time.
I'm just going to jump back to the comparison here, and I'm going to select the four metadata lists pick list values that I changed.
I can then jump across to selected objects, which gives me a summary of the objects I'm going to include in my deployment, and that's going to remind me to untick the email template here.
So click next again. It's gear set is going to rerun the problem analyzer, and this time, since it's a simple pick list value change, it's just gonna show me the results of my objects to deploy.
So this is a summary page showing me exactly what's in my deployment package before I actually run the deployment.
Now if I want, I can add notes to the deployment.
I'll call this webinar deployment, and these notes will be carried across through to the reporting and the audit trail once you've completed your deployment.
At this stage, if you wish, you can download a copy of the deployment package. So we will generate the package. Xml. If you've made any destructive changes, we'll generate the destructive changes to xml as well as all the objects as well. And this can be useful if you want to keep a copy of this for source control or versioning or even just for your audit side of things.
If you wish, you can run the deployment straight from here, but our recommended route is to run through a validation first, which is what I'm going to do now.
So what we're doing here is we run a test deployment to your target organization, and we'll ascertain if your deployment is going to succeed or if it's going to fail. This includes not only running the test deployment, but also any tests associated with it. So if you're deploying to a production environment and testing is required, we'll check those for you.
If your deployment does fail validation, we'll give you feedback on the failure messages so that you can help debug that and run your deployment successfully the first time.
Once your package does validate, you get presented with a screen like this, which just shows me that my components and any tests that run have been passed.
Now much like Salesforce's quick deploy feature, I can then return to this deployment validated package any point in the next ninety six hours and kick off the deployment safe in the knowledge that my tests have already been run and this deployment is going to succeed.
So I'm now going to kick off the deployment by hitting deploy now.
And Gear Set's now generated the package, and it's uploading it via the metadata API to your target organization.
We use Salesforce's automatic rollback feature. So in the event that something does go wrong, we'll roll your target organization back to its original state, and you're not left with a partially deployed org. We also don't sidestep any of the testing requirements. So if you have a seventy five percent co coverage requirement or anything like that, we use we apply all those as usual.
Now once your deployment completes, you get a report here which shows you a summary of your source and your target, any of those notes you made, and a summary of the objects deployed, and some information about the deployment itself.
This will automatically get emailed to you and any of your colleagues if you enter their email addresses as well, and you can download a copy of the report as a PDF just by clicking the button.
This can be really useful not just to internally maintain records for your team, but if you work as a consultant on a client site where you want to keep a a proof to show what you've been doing, these reports are a great, very easy way to show your progress.
Now I mentioned earlier that Gearset also keeps a history of all of your deployments.
Now if I move across to the deployment history tab, you can see this full list here.
Every deployment you ever make using Gearset is automatically stored in this list. So you can see there's quite a few I've made on this account here.
And for any deployment, you can not only go back and download a copy of the reports as a PDF or a CSV, but you can also download the actual deployment package itself as well. So this allows you to keep a copy of that for audit purposes.
You can also give the deployments friendly names and annotations just to make them a little bit easier to track.
Now the final thing I want to show off about the app is this monitor organization's ability.
So this the principle behind this is you can choose an organization, and you can detect and monitor any drift and changes to it over time.
This is usually applied to a production organization, but you can do it for any organization type of your choice.
Now what Gaseq will do once you create a monitoring job is it will take a snapshot of the metadata every twenty four hours. It will then run a comparison of the organization's current state against the previous snapshot and give you a summary of any differences that were detected.
So to give a demonstration of that, I'm going to jump into this top job here, which is currently listing as identical.
And what I can view here is a full change history for this organization.
So for every twenty four hour period, I can see were there any changes made to it, and if there are, I can dive into that in more detail. So you can see on the twentieth of January here, there was a change. Four objects were changed.
If I view comparison, I can actually dive into a line by line diff of exactly what happened in that twenty four hour window, And this will show me not only the objects that were changed but who changed them and when.
Now the beauty of this is this monitor's change is made in any way to your target organization.
So if other of your colleagues are using change sets or if people are even making undocumented changes directly in production, they'll all be captured by this change monitoring service.
So this is perfect not only for your auditing but also for team collaboration so you can understand and really get a handle on what's happening to your organizations.
In terms of the alerting, you can receive the alerts on the comparisons by email. We also support SMS, Chatter, and Slack integration as well.
So that's an overview of GearSet as it stands at the moment.
If I just jump back to our presentation We've come a long way in the last twelve months since we started out with Gearset and we have a lot of new features that we're planning to release over the next three to six months.
One of the things that Kevin mentioned earlier was about continuous integration and automation to remove a lot of the manual steps.
So as it stands at the moment, Gearsight will help remove a lot of your manual steps by building deployment packages, running our dependency analysis, and providing insights into your organizations.
But we also want to move towards the full automation. So within the first q in q one in twenty sixteen, we're going to be releasing scheduled deployments, which will allow you to run your deployments between, say, dev and staging on a regular cadence.
We're also going to be introducing team access to help you share your information with your colleagues, so things like sharing comparison results and deployment history extremely easily. And finally, the other main headline feature is going to be metadata backups. So we're going to be introducing the feature to allow you to take a snapshot of your organization and store that as a version history as the even greater part of the audit trail.
If you want to view more of what we're doing on our roadmap, then this is all publicly published on our website. You can just go to gearset dot com slash roadmap and view this for yourself. And we keep this updated with all of our progress over time.
We're also very receptive to user feedback. So if you do have any questions about Gearset or you try it out and there's a feature that you really want but it doesn't do at the moment, then please let us know because we're very responsive, and we will be able to work with you to help develop a solution that works.
So what are a few key takeaways from this webinar so far?
Well, the main one is that building a good, well thought out release management strategy is something that is worth it. It will pay for itself so many times, and the reason for this is, several. Firstly, it enables better collaboration.
Allowing your colleagues to spend more time working on the work that matters and not searching around for the right information is hugely important.
Secondly, it helps you maintain a clear audit trail. Now for those of you who have regulatory requirements, this is a clear win, but it's also useful just being able to keep track of what's happened in your teams over time.
Thirdly, it enables predictable delivery, which is key if you have deployments that are scheduled in specified downtime windows or you just want to avoid disruption to your user base.
It also allows you to spend less time on the tedious error prone work, such such as building manual deployment packages or working through missing dependencies and focus on the more important things, like delivering value and supporting your customers.
And finally, it just provides a simple release process.
And I think everybody agrees the simple process is much more likely to be followed and adopted across the business.
But you shouldn't always believe what you hear from us. We've worked very hard to deliver a tool that we think delivers value to users, but we're also very focused on getting comments from our users about how they're actually finding the app. So I've just got a few quotes on the screen here from some of our satisfied users across healthcare, Salesforce consultancies, and Salesforce themselves, as well as many other people, about how Gearset is actually helping them save time, money, and effort by using it in their organization.
If you've got any questions or you want to find more about our customers or case studies, let us know, and we'd be happy to talk about it further.
So with that, we'll open up to any questions.
In theory, there's a part of your GoToWebinar that you can click on that will allow you to ask a question.
So if you just expand that questions tab.
Okay.
If you have any other questions, just send them over to us on Twitter or teamgear set dot com, and we'll get back to you. The The recording of this webinar will be made available afterwards, so we'll send you an email with that and just a little thank you message.
On that, thank you very much.
