Webinar: 7 steps to faster Salesforce deployments

Share with

Description

Learn how to speed up your Salesforce deployments in this live 30-minute webinar. Led by DevOps Advocate, Rob Cowell, we’ll explore how 7 key deployment principles, including good preparation, using sandboxes, keeping orgs in sync, and improving visibility, can help your team deploy faster and more reliably than ever.

This webinar is for you if you’re a Salesforce Admin, Developer or Manager.

Learn more:

Related videos:

Transcript

Welcome everyone to today's webinar, and we are indeed gonna cover seven steps to faster Salesforce deployments.

Ultimately, what we want to do is have faster, smoother, error free deployments on the platform, and hopefully some of these tips are gonna get you there.

So as Amy has confirmed, I am indeed Rob Cowell, one of the dev ops advocates here at Geerset.

So my missions help Salesforce professionals like you have an easier life when it comes to deploying and releasing your changes. And hopefully, by sharing some of the tips and techniques of dev ops, we can get you there.

So let's get started with some of those tips for faster deployments.

So launching into the Salesforce world is kind of a big deal for any business It's not just about getting a new tool. It's about making that tool work for what you need. So the idea of a structured approach is like having a good recipe before you start cooking. It helps everyone know what needs to be done, how it's done, and what we want to achieve at the end of the day.

A structured game plan will help spot any road bumps before they turn into mountains.

So with a clear plan, everyone can work together better, and we can fix issues before they become big headaches. It's about keeping things running smoothly and getting the most out of Salesforce.

And so it doesn't just end with setting it up right it's also about keeping that momentum going, following a solid plan from the start, helped not only make the initial setup a success, it helps keep the good times rolling as we roll Salesforce out down the road. So as we go through today's session, we'll break down into seven simple steps to make streamlining Salesforce a breeze and ensure that it does exactly what it needs to do for your business.

So the first step for any efficient process, dev ops or otherwise, begins with thorough planning and preparation.

So we can further break this down by planning by applying that planning to each step along your entire development life cycle.

So kicking off our Salesforce journey begins with the sale at the discovery phase, which is all about mapping out the territory.

It's here that we dig into what our users need and decide on what we'll build in order to meet those needs.

Then we step into version control.

Think of this as marking our trail on the map so that we can always trace back our steps. It's a crucial part for knowing who did what and when, and it sets us up for success in a number of ways that change sets alone can't deliver.

We're gonna explore version control a little more when we look at ways to track changes efficiently, whether they're declarative and conflict changes or code changes.

Now onto the development phase where we actually start the journey trekking through that coding terrain or building new pathways, even improving the existing ones in our Salesforce environment.

The testing phase is our checkpoint It's where we ensure that the pathways we've created are safe and lead to where they're supposed to. And this journey includes user acceptance testing. Where our users get to walk the paths and give us the green light or feedback of any roadblocks they might encounter.

Lastly, we reach the product release, our destination, and it's where we open up those new trails to all our users, ensuring we have a smooth journey ahead in the Salesforce environment.

So this step by step approach, this roadmap ensures that we're all well prepared and equipped for that journey, making sure that what we deliver aligns with the needs and patience of our users.

Every phase is a crucial part of that map. Miss one, when we might find ourselves a little off course.

So the next step is the use of sound boxes. Sound boxes and Salesforce are special areas where you can test and develop things safely away from your live environment.

And of course there are different types of sandboxes each serving a unique purpose.

The developer sandbox is a lightweight sandbox used mainly for coding and configuration and testing by individual developers and admins. It's like a personal workspace, but with limited data storage.

The developer Pro Sandbox is a bit larger than the developer sandbox. It offers more space for data, and it's used for similar purposes, coding, configuration, building, and testing, with a little bit more room to work with.

The partial copy sandbox is more substantial still. It carries a chunk of your live data for more accurate testing and development, and it's useful to see how your new changes will interact with existing data.

And finally, we have the full copy sandbox. And as the name suggests, this one's a full copy of your live environment.

It can be used for performance testing, user acceptance testing, and training. And it's ideal when you need to test those changes in a full replica of your live setup.

Now before you refresh any sandbox, it's smart to have a list of the configurations and settings that you'll need to update afterwards. It's like having a checklist for everything that needs to be reset.

Well, it's time to refresh. Should choose a time that causes the least hassle. Since refreshing takes a little time, it's also good to pick a window for when that sandbox is least needed.

After the refresh, you can go through the checklist and update the necessary configurations, reestablish any needed connections, and ensure that the sandbox is ready for use again.

And lastly, communication is key to everything we do. Make sure that everyone who uses the sandbox knows when the refresh is happening and what they need to do before and after.

So keeping everyone informed will help ensure that the sandbox is ready for testing and development once that refresh is complete.

Next, we look at the issue of handling missing dependencies.

Being with missing dependencies and a Salesforce deployment is about tackling those unseen links that could throw a wrench in our deployment process.

There's references to objects, fields, or other bits of code or setup that don't necessarily exist. In the environment that we're moving to.

The first step in that process is all about identification.

There's tools out there like Salesforce's dependency API or even some third party solutions that can help us spot these missing links.

And it's crucial to get a good grasp on what's missing before we dive into fixing things.

Once we have figured out what's missing, we can move on to resolution.

This could mean creating those missing objects or fields in the new environment or tweaking the code or the setup to get rid of or replace those missing references But the aim here is to smoothen out the bumps so that everything interacts well.

After we've tackled those missing pieces, it's time for a little verification.

We need to check and double check that we've addressed all those dependencies and that our deployment is now ready to roll this planned. So running some tests and reviewing the setups a crucial steps here to make sure that we've got everything in place.

It's a good practice to jot down the dependencies that we found, how we them and any changes that we needed to make along the way, because this documentation can be a lifesaver for future deployments makes things a lot easier.

And lastly, once again, we shouldn't forget about communication.

It's important that we keep our team in the loop about the missing dependencies and how we resolve them Because when everyone's on the same page, it helps avoid confusion, and it paves the way for a smoother deployment process.

Now we talked about testing when we were looking at those dependencies, and we need to look at testing in a little more detail. Testing is our way of making sure that what we've built, not only works as intended, but performs well under different conditions and is something that our users will find useful and easy to use.

So let's kick things off with automated testing.

Automated testing is like having a little robot buddy who checked your work. It's all about running those pre designed tests automatically to catch any bugs or issues early on. This way, we can fix the problems as soon as they pop up. Saving time and ensuring a higher level of quality in what we deliver.

Next on the list is performance testing.

Performance testings where we check how our setup holds up under pressure, it's like seeing how your car performs on a rough dirt track. We test how the system behaves under heavy load and how fast it responds to requests.

The aim here is to ensure that what we've built and what we've set up won't crumble when things get busy.

And then we move on to user acceptance testing or UAT.

And this is where we invite our users to give the setup a spin. It's about getting feedback from the people who actually use the system daily. They help us see if what we've built meets their needs, and it's easy to use.

Their thumbs up is crucial because at the end of the day, it's all about delivering something that's useful and user friendly to them, not just to us.

And testing isn't just a box that needs to be ticked as part of your deployments, it's a crucial step that makes sure that our Salesforce deployment is ready to face the real world.

So through testing, we ensure that what we deliver is reliable, robust, and ready to meet those needs.

So let's now delve into the vital aspects of tracking and compete, keeping our Salesforce setup in sync, which is all about having a good system to manage and monitor the changes that we make along the way. Now this includes version control on the technical side of things, but also includes change and release management on the process side of things.

So let's start with that version control, which you sometimes might hear referred to as source control as well.

Version controls our way of keeping a good history of all the changes that we make, whether that's code, flow, field changes, pretty much everything that's metadata in our org. Every time we make a change, it can be logged. So if something does go wrong, or even if we just need to look back at something that was done a while back, we have a clear record.

It's our safety net. It ensures that no matter what happens, we can always trace back our steps. And since that metadata encompasses objects, fields, clarative logic and code, and all of that metadata can be treated as a file, it means that version control of these files is valuable to admins and developers alike.

So let's look at the other side of the coin, the less technical side, which is change of release management.

This is where we plan, schedule, and control the process of building and delivering those changes.

It's about having a good plan on how and when we roll out those changes. Ensures everyone's prepared and everything goes smoothly.

We decide what changes are gonna be made, when they'll be made, and how they'll be deployed.

So it's it's having a clear roadmap from building all the way through to deploying those changes.

And this means being organized, having a clear view of the changes, and ensuring everything rolls out smoothly and consistency across the board.

So through this meticulous tracking and management, we ensure that our Salesforce set up to well organized, synchronized, and ready for deployment.

An effective change of release management process highlights how it's not just technical elements that can speed up your deployments.

A well structured process will minimize errors, streamlining the transition of changes from development to production, and overall enhanced efficiency.

A clear release schedule will improve right resource allocation.

With known release times, teams complain better, and that accelerates deployments too. And it also ensures timely checks which reduces last minute hurdles that could delay your deployment.

And once again, communication comes to the fall. Good change in release management will improve that team communication because a clear understanding of what change is being made and when will eliminate confusion and promote a faster deployment process.

But the speed of deployments is nothing if those deployments aren't reliably successful most of the time.

Reachreads and rework swallow up resources that are better spent delivering new value. So to solve this, we need to have greater visibility into our deployments.

Equally, we should be mindful that the successful delivery of projects is more than just those technical considerations.

Should always work to keep stakeholders in the loop on the progress of work from development through to delivery, and that's the key to a smoother release cycle. Providing visibility throughout that entire process.

Visibility is the lens through which we monitor deployments and understand our feedback, It's about having a clear view of what's happening during the deployment and how it's performing afterwards.

This clear view enables better monitoring help spot issues in real time. And it also helps understand the feedback better as we get a clear picture of what was deployed and how it's performing.

Monitoring deployments is about having real time insights as those changes roll out, spotting any issues early, and it allows for quick action if things aren't going to plan.

Now when we talk about monitoring, we're going beyond just watching that deployment circle in the Salesforce UI or looking out for the famous deployment fish some of you more seasoned professionals will know so well. Instead, what we're talking about is monitoring the health bar changes from start to finish.

We test early and often, looking for errors and anomalies, posing techniques such as automated test runs or static code analysis, that'll help us spot potential issues early.

We integrate our changes together with those of our peers on a regular basis and that ensures that everything sits together without unintended consequences.

We perform pre deployment validations ahead of that release to simulate the full experience and check it that all is well.

All of these steps contribute to monitoring our release end to end and hopefully avoid any nasty surprises.

Now on the other hand, gathering and acting on feedback from our testing is about understanding that user experience post deployment feedback helps in identifying areas for improvement and ensures that the setup meets the user's needs and performs well.

So we move on to training and documentation, and training is key to optimizing your deployments.

Regular training sessions keeps your Salesforce team updated on the latest DevOps methodologies and tools, and it ensures efficient and effective deployments.

On the other hand, creating comprehensive documentation is about having a solid reference died for your teams.

It aids in understanding and implementing those dev ops practices in your Salesforce deployments, and it makes the process smoother still.

So this right combination of training and documentation for your internal sales force teams is crucial for enhancing that deployment efficiency.

But it also promotes a culture of knowledge sharing and continuous learning within those Salesforce teams. And this foundation will again contribute to successful deployments, which are rooted in best practices and collaborative effort.

So let's have a wrap up of those seven actions that we can take to improve the speed of our deployment.

We began with preparation and planning where we outlined our goals and planned the deployment and it set the groundwork for the steps that followed.

Next, we looked at using sandboxes for testing and development.

This step ensures that we have a safe environment to test and refine those configurations before we move them up to the live setup.

Handling missing dependencies followed next, focusing on identifying and resolving those dependencies to ensure a smooth deployment process.

Testing was the next step, ensuring that our configurations were robust and ready for real world use through automated testing, performance testing, and user acceptance testing.

We then looked at tracking and keeping our orgs in sync, which emphasizes the importance of version control on the technical side, and a good change in release management process on the operational side to ensure a well coordinated deployment.

Visibility came next, focusing on monitoring deployment and gathering actionable feedback for continuous improvement.

And lastly, we discussed the need for training and documentation for our Salesforce teams. So here, we're talking about documentation and training on our development and deployment process, not necessarily the training and documentation for our end users.

Both equally important, but this will allow our Salesforce teams to work on those dev ops processes and best practices and fold them into their daily working.

Now adopting each of these steps is crucial for a successful Salesforce deployment. It's about being structured, informed, and proactive in your approach. It ensures that not only do we have successful deployments, but also that culture of continuous improvement and excellent in our deployment processes.

Now while none of the approaches that I've discussed today are unique to any particular solution or platform, Of course, I'm going to encourage you to see how easy it could be working with gear set field deployments.

And when we talked about visibility, monitoring deployments, keeping your all in sync and managing all those dependencies, these are all things that are possible within gear set so that you have this central place, this central user interface and dashboard to manage your deployments.

If you're not already using gear set, we do have a thirty day free trial that has all of those features enabled and you can get started on that via our website, or you can scan the QR code that I've got on the screen here.

You don't need to install anything into your org. And even during that free trial period, you still have full access to our world class support team. There's you get the same level of support during that trial as you would from a a paying customer.

So that covers everything that I was wanting to share with you today in the main presentation, but of course we're always happy to pick up any questions that you might have. So with that in mind, I will hand back over to Amy to see what questions we've got come up from everybody on the call.

Thanks so much, Rob. That was fantastic. Some really practical advice there for people to take away. And yeah, just to reiterate, If we don't get around answering your question today, do feel free to reach out to us on our live chat via our website gear set dot com we can answer any of your questions over there as well, but we do have time at the end of today's session for a couple of questions that have popped up in our Q and So I've got one here for you, Rob, and this one chats a little bit about so we've we've had emergency changes in a hotfix or straight into production that we needed to deploy, where we wanted to make sure that the change gets back down to our lower environments.

What's the best way to tackle that?

Okay. I mean, the the The kind of tongue in cheek answer is please don't put changes directly into production, but I I understand that sometimes it, you know, there are these emergency cases that are necessary.

So I would say there's there's a few options there.

So if we look first at the the more sort of platform neutral way of doing things.

You know, even if you're doing like hotfixes or or changes that are going in Australia into production, I think that adopting version control is still vital at this stage.

And even, you know, in some cases, if it is an emergency change, you may have to do that a little retrospectively.

But by putting it into version control, you can then go to the setup for your lower environments, pull those changes from version control and apply them to your environments.

And that that is a a reasonable working process regardless of, you know, kind of how you're running your your Salesforce DevOps. But on the other hand, again, putting my my gear set hat back on again, you know, we do have, a couple of features that will will help with So we have, a visual representation of your kind of entire environment and the flow through that in our pipelines feature. And then the nice thing about pipelines is something called back propagation.

Which is a fancy way of of doing exactly what I've I've just said. It's it's getting those changes back out source control and migrating them back through your various sandbox environments.

If you want if you're not quite ready for for pipelines, then, you know, you can always do a a compare between environments So rather than say, okay, compare my my development sandbox against production, you know, and see, you know, what I need to deploy to prod, you can actually flip that around and do it the other way around and say, what's new in production that I haven't got in my environments, and just use our compare and deploy feature to get those changes back where they need to be.

Excellent. Thanks so much, Rob. We have another question for you here in the Q and from Vanessa.

And, Vanessa's asking how do we prioritize the steps you've covered today so that we have a better idea of which order tackle them in. Maybe you could chat a little bit about the steps that you think are most important when, teams are starting to approach this.

Absolutely. Yeah. So, you know, one of the the mindsets that we always try and sort of convey to folks is, you know, walk before you can run. Okay. Don't try and and get a, you know, a complete full automated end to end continuous integration pipeline if you're just getting started with Okay. So there are some steps that, on both the technical and the non technical side that are fundamental to everything.

So starting with the non technical, you you'll hopefully have noticed a recurring theme in each of those points, that I covered. Earlier, which is communication. Okay. Communication and just having that awareness of what's coming up in the pipeline, what people on the team are working on. So for example, if you have a team member that's that's making some changes to some automation related to the opportunity object, and you know that you've got to do some stuff on automation.

Talk to each other, collaborate, communicate, make sure that, you know, you're not gonna be impacting and overriding each other's changes. So I would say on the non technical side, the biggest thing that you can do to set yourself up for success is to get that mindset of collaboration and working together and communicating together. Now on the technical side, version control every day of the week. Version control unlocks so many of the technical things that you likely to want to be able to do later.

So rollbacks, that back propagation of those emergency changes we were just talking about. The ability to automate running the tests, the ability to, automate moving things from environment to environment. So for example, you can have a scenario where, you know, your automation will pull the changes from source control apply them to an environment, run all of the tests. If all of those tests are successful, then it can move to deploying things up to the next environment.

Advanced stuff, but it's all underpinned by getting started with using version control.

So those those are the two top tips that I think are most fundamental to them.

Excellent. Thanks, Rob. I think we've got time for one more quick question here.

We've had a few questions, today about Sandboxes.

And one popped up here is during the Sandrocks preview window, how can I make sure deployments work when they're on different versions?

Oh, yes. Yes. This is always a a tricky one. So there there's a couple of things here. So early we talked about, being quite strategic and deliberate about your sandbox refresh windows.

And this is a factor that that absolutely plays into it. It's not just when people need to use the sandbox, but also when that that rare point sort of three times a year when Salesforce do a new release that we, you know, we potentially have sound boxes running different API versions. So one will be on winter twenty four, one will be on spring twenty four, you know, whatever that that window looks like. So there's a few things that we can do, around that.

Because nobody wants to be sitting there and unpicking a release.

So one of the things that we try and encourage, folks to do is, you know, and this is something that, you know, is very easy to do within gearstick, potentially it can, you know, via other mechanisms is pull metadata that has that lowest common oh, sorry, highest common denominator.

So for example, if you've, you know, and we base this on ADI versions. So again, this is illustrative, but supposing we have an environments on API fifty three and another that's on API fifty four, then, actually, I was right. It was lowest common version number. Basically, you would say, okay, I want you to treat this deployment as if they were both on fifty three. So don't include anything that is only applicable in version fifty four. Okay. So that's the technical aspect, and you can kind of say, okay, you know, match the versions between these things.

But also, you know, this also comes back to the planning side of things. So plan what you're going to release and look through that and think, okay, is this a new feature that's introduced with the upcoming release? It's probably not gonna be available to everyone anyway.

You know, but certainly by the time you get to production until that that release has gone generally available.

But also, you know, that planning around when we do those those Sandbox refreshes. So it's a tricky period, but there there are ways that we can we can work around it.

Excellent. Thanks so much, Rob. Well, that is all we have time for today, folks. Thank you to all our lovely attendees for joining us. Big thank you to Rob for running today's session, and thank you to also to Andy for answering all of your questions in the Q and A and chat today.

We really hope you enjoy today's session, guys, and we hope to see you soon on some more deployment webinars. So thanks so much everyone and take care. Thank you, everyone. Take care.