Description
Salesforce developer Monica Thornton Hill, takes us through how McKesson, a Fortune 5 healthcare giant, builds, validates and deploys changes between Salesforce environments in minutes with Gearset. The McKesson team use CI jobs to migrate declarative changes automatically every 4 hours. For code changes, they use Gearset’s compare and deploy on Fridays.
Learn more:
Transcript
Hi. My name is Monica Hill, and I'm a Salesforce developer at McKesson Technology. And I'm gonna walk through how my team uses CareSet to deploy our metadata changes between Salesforce environments.
We have about sixteen Salesforce admin and Salesforce developers that use Gear Set throughout the week to deploy changes between sandboxes.
In our current state, we deploy declarative or admin changes automatically every four hours to our production environment from our staging environment using Gear Sets continuous integration or CI job feature. We also run unit tests during our CI job.
For code changes, though, our admin team runs a full comparison once a week on Fridays between our stage and production environment, and it's really straightforward. And that's what I'm gonna walk through with you today.
So we are going to start our comparison by selecting a source and target. For our source, we're gonna use a demo staging environment, and our target will be a production environment.
And for our metadata comparison filter, I'm gonna use the one that we normally use for our Friday deployments that we call full comparison because it's all click changes, all code, flows, process builders, anything that usually would go during the CI job during the week or, every and everything else that's going to basically impact the logic in production that we prefer to have go on a Friday after work hours where we can validate over the weekend or roll it back if needed.
So I'm gonna start our comparison, and that's going to take the highest default API version between the two environments, in this case, summer nineteen. Going to evaluate all of the changes between those between these two environments within the scope of those fifty three different metadata types. So it's gonna pull in all of the new items, changed items, and any deletions into a comparison.
Alright. Now our comparison is finished, and it's loading all of our results between the two environments. There's a lot of changed items. As they come in here, you can see if you were to click into each one, you can see the differences in the XML between the two. This is super helpful for troubleshooting or if you see something unexpected that that you didn't know was going to production or if there were any potential dependencies that you could identify from here. For Friday deployments, we usually check off all changed and new items, and deletions.
For the sake of this demo, I'm just going to select a new object and a layout, and I'm gonna also move the permissions for this layout.
I could go ahead and save this draft deployment and share it with my team if I wanted to. Maybe there's something I I found that wasn't expected, and I wanted to send it to a particular product team.
And it generates a link that I can share with anyone who has access to Gearset, where they can also find it under draft appointments.
Next, it's gonna move on to problem analysis, and this is just in case there's any missing dependencies or any potential issues.
For instance, if I tried to move the, layout without the custom object that doesn't exist on the target yet, this layout would have a dependency on that custom object, and it would probably be identified in that problem problem analysis phase of this process.
So now that my deployment package is ready, I can go ahead and deploy or I can validate. I can also download it as a CSV. I can export it.
I'm gonna go ahead and do specify test run. There are no tests involved in my my target and source of this deployment, so none are being automatically suggested here. But if I had any new code or any test classes, I could select them here or put them in the text area.
I'm gonna go ahead and say don't run any tests.
On a Friday deployment, our team would have a specified list of all the test classes that we needed to run for all of the new code that was going that weekend, if any. And my validation has succeeded. And you can see all of the different components that it went through as the validation is running. If anything fails, it'll appear here as it goes through each item. If anything fails, you can always go back to the comparison, where you can revalidate.
And same with any Apex tests that fail or if they don't reach seventy five percent code coverage. Then you can go back to the comparison and refresh it, which saves all your selected items, and you can go back in and maybe add something that was missing. Or if someone needs to make changes, then you can go back and refresh it after they made those changes. If this was a Friday deployment, I would go ahead and schedule it for eight PM eastern after work hours.
I could add my manager's email here or director, anyone that might wanna know that that the deployment had succeeded that night.
I usually post on our, MS Teams channel when it succeeded just to let everyone know, and then I can save the scheduled deployment.
And now on Friday at eight PM, that will run.
I can now also click into it and view our deployment summary, to go in and see what's moving on Friday. I can share this with others, and also download an expert just like on the other pages.
So before we used Gear Set, most of us admins or developers were not part of the deployments to production. I was previously a Salesforce admin and remember feeling very unfamiliar with the process, and I was not envious of the late Friday nights that our DevOps, team members experienced.
With Gearset, though, it's extremely straightforward. It's all point and click.
Unlike the previous process, I don't feel any sort of intimidation or any sort of concern about what I might click on, what I might do. Like, it's all very clear what each thing does and every step's purpose. The validations can be done ahead of time, which is super useful for whoever's running the deployment. They can get their work done well before the end of the workday.
And If they need to pull someone in, it's really easy to send that link to someone else, then they can take over from where they left off. There are also options in Gear Set to connect to Jira or connect to a source control, such as Bitbucket or GitHub. Because of the transparency that Gear Set enables, everyone can become involved in the process. This makes it easier to address any issues that arise during our deployment process.
No one is really on their own. Thanks to Gear Set, our deployment process has become a team effort, and it's always improving. And thank you for joining me today as I walked through deploying with Gear Set.
