Description
The first session in the 2024 Gearset 360 training series. In this session we cover implementation tips and tricks, and how to set up your team for success in Gearset,
Transcript
A variety of places. Welcome, everyone.
Hello. Hello.
Yay. So let's start.
Hello. I hope you're all having a great day, and ready to learn how to make the most out of Kearsets. You've signed up for a series of four events. In the next weeks, you will learn more about CICD pipelines, Salesforce data recovery, and CPQ deployments.
Today is the first one and is focused on setting up your team for success in Gear Sets. My name is Maria. I'm here with George and Charlie, and we are all in the customer enablement team, and our focus is to make sure that our customers and our employees understand how Gearset works and which problems it's resolving. We'll be holding a q and a at the end, but feel free to post any questions in the chat throughout.
Charlie will be monitoring and responding to you.
Today, we will cover how to compare and deploy more efficiently, how to speed up promoting changes through your workflow when you don't have an automation like CICD or pipelines, and how to integrate your tech stack under one roof. And at the end, we'll share some of the support and learning resources available to you. With our recommendations today, we'd expect you to be able to reduce time to deliver value to our business, meaning shorter release times, spend less time doing repetitive tasks and more time where your attention is needed, and decrease the need of extra resources and tools within your DevOps process. Let's start then.
For comparing and deploying section, we will be looking at how to get speedy and dynamic, comparison retrievals, granular and efficient packages, shift left testing, and integrated tech stack. So today, my user story is that our team has a few tasks to complete this week, and we integrate with Jira ticket system, which we will show you a bit more detail later on. But for now, I'll just check what are the tasks that I need to do.
I was asked to create a new field in the managed package object, also to assign a few, field permissions to the correct profiles and add it to an existing layout. I was also asked to amend the value in an existing attacks class. I've already done all changes in the developer org, but now I need to deploy to my testing environment.
Once I move to testing, I will also need to make sure this progresses to in progress status in Jira. We work we work on a shared sandbox, and it has a lot of customization from all of us in the team. And now I want to make my comparison in gear set as fast and as efficient as I can.
Most of you used our comparison solution already. Gearset requests all metadata from a specified source and the target unless the pre comparison filter is specified to reach three fewer components. To make comparisons more responsive more responsive and to remove the bottleneck of metadata retrieving times, now we provide you with the metadata that you want faster with an optimized approach that is currently in pilot.
I'll show it in a moment, but if after this session you want to give it a try, you can go to my account and enable compare two point two, pilot. This is the page where you can see all our pilots available. And now it's enabled, so I can go back to selecting the source and target.
Yeah. So I'll select from developer to testing.
For now, you have the ability to use whichever approach you prefer, but today, we're using the more dynamic solution compared to point o pilot. Let's start and oh, no waiting for retrieval, just straight into the comparison.
This lets you take charge of your comparisons and get results on demand, reducing the number of comparison steps required. Here, I can see a list of all the metadata types, and I will include the ones that I need. So I needed to make change in objects, so I'll include object, effects.
I also needed to change layouts.
So I adding here, and now I can see here the list of what I've I've included.
This is what I remember that I need, and I can see here my full list. Not only this makes my comparison faster, but I don't need to scroll through million things I don't need. It only retrieved the types that I wanted.
One of my tasks was to deploy the new field trail list, but it's not here in the new tabs. Oh, yeah. Because it's part of manage package, and I know that you said supports deploying manage packages, but I haven't specified it. So I can come here to customize, configure this comparison, and I'll ask Gearset to include the managed package.
And now I'm including the one that I need here. But now that I'm here, I actually decided that I want to make this even more specific, my comparison even more specific.
Let's go to objects, and I will not want to retrieve all objects. I will only want to retrieve the specific one that I need, which the object that I'm making changes is trail.
So I will include that one and not retrieve all objects.
And now I update my comparison.
So basically, I forgot something, and I don't need to start all over again, nor I need to refresh the whole comparison. This allows you to include items when needed and to retrieve only what you need. You'll spend less time waiting for comparisons to finish even when your head your org is heavy. Oh, and I see here the item was retrieved.
Let me select it because I need to include this in my package. When I select this here, it moves to my selected items, so I can see everything that I'm adding to the package that I'm building here. One thing to note, I'll go back to comparison. One thing to note, if you use source tracking and have it enabled in your orgs, you could use it for further speed, in recent in checking recent changes.
For today purpose, let's assume that I don't use it, so I will not select it.
There's a few more efficient ways, there's a few more ways, that are efficient to make the best use of our of the granular named items. Let's look at the Apex classes, for example.
And I can click here to take me straight to the filter for Apex classes.
And I can see here there is nearly one hundred Apex classes found and a lot of them are from the managed package.
Let's say that I want to include Apex classes, all the Apex classes to be retrieved, but I will never make changes in Apex classes in managed packages. So this is just adding noise to my comparison if I selected everything.
But I also don't want to select one by one to just include the ones that are not managed packages. That's time consuming, and I may miss out something. Also, it might not it will not retrieve new items if I save these for for a filter in a future comparison. So instead of selecting the ones that I want, I will use add rules to include or exclude Apex classes.
What I will do is instead of selecting the classes that I want, I will add, regular expressions. If you're not familiar with regular expression expressions in Google, you can find a couple, that are common. Today, I'll use this one, period and star, and then when I include, I'm saying include all Apex classes. And then I'll do another one, period star, underscore, underscore, period star, and to exclude, which means include all Apex classes, but exclude all Apex classes with underscore underscore, which means managed packages.
So I've just made my filter more efficient. If this is something that I'll be working on often, I might want to save this for feature. So I could click here, save filter, give it a name like Apex and manage packages, and I could save this just for myself or share the filter with the team.
So I'll save this here.
I've finished customizing these, and now I'll update the comparison to refine my results.
Hopefully, this helps you to understand how to customize these, in your favor.
Now I want to make sure that the new field that I I'm adding is added to the respective respective layout, and I'll find it is in the changed items. In the layout I find here the layout. In the layout view, I can I can see a very similar layout to the pages layout in Salesforce instead of the daunting XML?
We have a different simplified views for certain metadata types like layouts, pick list views, and many others to help with readability for teams less used to work with XML. Because I wanted to add the new fields to the layout, I will select the change. But whilst I'm here, I noticed that there's a field being deleted from the layout and another field that is moving places, and I have no idea what George is up to. So I'll cherry pick only my change, and I'll leave behind things that is not my work. This is allowing us to work together without overriding each other's customization.
And as I added here, you can see in the selected items, one more item was included.
Another task was to update the Apex class account info validation account info validation that is here.
So I can see here the changes, but what I was asked was to change the value from twenty to thirty. And once again, I see here more changes than the one that I needed to do. At this point, I could select the whole class, but I'm risk interfering with George's work. I could select just additions, just deletions.
I could select lines or a block of code, which is what I'm going to do now because I want to include the block that brings the thirty value, and I want to include removing the value twenty. And George can deal with the other changes later.
Can you still hear me?
Yeah. Okay. Cool. Thank you.
So whatever I select, I can check the final result in the preview selections without having to deploy first. I can preview here. However, whilst I'm previewing, I notice a wrong value in my change. Name limit should be one and not two.
So what I will do now, I click here in this blue link, and it takes me straight to the org, to the Apex class that was selected. I don't need to open a new tab, to log in and find what I need. I just come here, I change the value, I save, I go back to hearset, I refresh just this item. So basically, by doing this, I amended these very quickly, and I'm asking hearset just to refresh this value and not the whole comparison, which makes this much faster when I need to amend something or if I forgot to include something.
And I can see the value was amended, and yearset also remembers, yearset also remembers the selections that I've done before, amending the value. This means that once again, I'm not deploying work in progress items, nor I have to wait to speak with George to go ahead with my work.
There's one more thing that I need to do. I still need to include permission the permissions given to the new field created.
For this, I need to include profile, metadata type, which I forgot before, but I can include now.
And as I mentioned, I don't need to include everything from the beginning. I add as I need. Profiles and permissions are one of the most complex metadata types in Salesforce and is well known that they are hard to migrate with the likes of changesets. But Gearset makes deploying these changes much easier by breaking them down. If I go here and I, for example, look at the admin profile, let's look at the profile. Rather than just deploying the whole profile, which in this case, we can see that there's no changes, it's unchanged, Well, if we expand its components, you will see that individual permissions are broken into individual deployable pieces. You still have got the option to select everything if you wanted to, or you could just select the ones that you care, which in this case will be the field security, level for the field that I'm adding here.
This is helpful when you've made changes to a variety of different components of a profile but not wanting to deploy the entire profile as it has changes that are not ready to move yet or you're not sure about them. So let me collapse this for now.
Let's say that I wasn't too sure which profiles were given permissions for the new field, and I don't want to go what profile by profile to find them. And here, I was just assigning to admin anyway. So there's other useful ways to do it if this is what I want. Let's look again in the new items so I can find the field that I had before.
So I can see the field here, but I also can see custom field permissions.
Here in the custom field permissions, I have an easy visualizer that resembles the permissions in the org just to see what permissions are being given if I include this. If I wanted to assign all these these permissions to all these profiles, I could just select this. But assuming we only want to deploy some permissions here, I would also gain control in the field itself. So if I expand the field itself here, I can see profiles and permissions for this field. And now I could be very granular, and let's say those are the only profiles that I want to give permissions for now, and the other ones I will deal with them later. I will leave them out of the deployment, but I'm being granular about which profiles I want to include now.
Gear set breaks this to allow you, only to include your desired and specific changes. As you can see, there are a number of different ways of navigating the comparison depending on what you'd like to of what you'd like to achieve achieve. Hopefully, this show you how you can be very precise and have greater control over what you include in your packages, also allowing greater collaboration and reducing post deployment steps or even failed deployments. I will, at this point, save the draft deployment. So let's say Apex and Trail, review.
Now I'll save this. So then I can ask George to have a look at these and check if the Apex classes are all good and if the the the work is all fine before we deploy. Also, now I need a break, and I will keep working on these later. Those were the tips and tricks I wanted to show you about making your comparisons process more efficient and building packages with higher chances to succeed and not override work in progress changes. Now George will show you a few more tricks to make the whole process needed. George, up to you.
Thank you very much. Yeah. I'm just gonna start sharing my screen and then take over that process.
Cool. Okay. Alright. Well, yeah, thank you very much, Maria. And so as we saw, she recently saved a new draft deployment, and then I'll be able to see that if I navigate to the draft deployment page.
I'm just gonna open up the latest one here. In this case, I know Maria has only recently built this package, so it's largely going to be up to date. However, it's always a good idea to refresh these components, to ensure I'm deploying the latest versions for my source.
It's just occurred to me this is a little bit on the small side. So let me just zoom in a little bit just to make it a bit more easy for you guys to view.
Cool. Alright. I'm gonna now get over to selected items, which is obviously all the components that Maria selected as part of her, package. I can right click them, and I can refresh just the selected ones.
So all that's gonna do now is refresh the ones in the package, and it's not gonna pull anything else, which will obviously speed this process up quite a bit.
Those that have used Gear Set for a while know that previously, I may have needed to do a full refresh, you know, all the components and retrieve the latest. But rather than doing that, this will be much, much more efficient.
And while it's retrieving those, this is a good time to check the original Jira ticket and just basically make sure that we've got everything we, we were supposed to. So navigating over to Jira. Let's open up our Jira ticket.
So looking at the package according to the ticket, it looks like we've basically got everything that we want.
The only thing that I think is missing is this final Apex pass here, the change password controller.
Let me just copy the name of that. I'm gonna navigate back over to my comparison, switch over to the comparison view. Now I can search for that, and, I can see the class, its test, and obviously the associate permissions to each of those. So I'm gonna add those to my package.
And now that my package really has everything that it needs, we're good to proceed.
So Gearset, at this stage, will automatically recognize that I've got a new field in my package, but that I've left out some permissions.
Just giving you a quick solution by offering to include all the permissions associated to that field. So with one click, I can include all the permissions should I want to. But as Maria demonstrated, you're not forced to include all the permissions and we wanna be quite explicit about the permissions that we're including. So I'm not gonna take that suggestion and actually choose to ignore it in this case. But the, the option is there depending on, what what you'd like to do.
But, yeah, now that I've ignored that, I'm good to go to the pre deployment summary.
And then on the summary page, you've got the usual options of giving this deployment a friendly name and a description. So I'm just gonna give it the name according description. Obviously, relates to, the components in my package.
And once added, just below, I can associate this deployment to the ticket that we've been working on as well, first by selecting, obviously, Jira, the project, and then the ticket in question.
Ticketing systems obviously make for better collaboration with your team. The use of them, you know, allows for better delegation of work, helps ensure that everyone's knows what they're working on, what their responsibilities are for any particular sprint.
And GearSet integrates with, obviously, the likes of Jira, Azure DevOps, Asana to to bring your existing tech stack into the fold. So today, of course, we're using Jira, and I just wanted to demonstrate how easy it is to assign a ticket to this particular deployment.
You've got a bunch of customization options, but the default will simply just update the Jira ticket with the results of the deployment. So we'll leave it like that for now.
Finally, with regards to the status, we do have the option to automatically update the Jira status following the deployment or the validation. So, currently, this is in to do status. But if I select in progress, it will update it to in progress app as a result of this deployment.
So that's very useful for reducing the amount of post deployment steps involved, meanwhile keeping your Jira ticket supplemented with with important information.
So now I'm basically ready to go.
If my deployment package didn't include any Apex class or triggers, I would basically go ahead and validate and deploy as as is now. But because I do include some Apex, there's a little bit more functionality that I wanna just show you.
So down in the bottom right here, if I click on this little arrow, I've got a few options here.
By default, Gear set will only trigger the required tests as part of any deployment, which means that in lower sandboxes, no tests will be triggered.
Due to this, it can be quite easy for issues to go unnoticed until it's too late, namely when you're releasing to production. You probably heard the term shift left, meaning to bring testing to an earlier stage in your process, avoiding pain down the line. To this end, GearSafe provides you the option to customize which tests get run as part of any validation or deployment.
And as you can see, you're presented with obviously a few options, but today I'm gonna be looking at specified test to run.
When you choose this option, Gear set will list all the available test classes that are contained within the target or or indeed the package itself.
And because my package includes the Apex change password controller, it's suggesting that I probably wanna run the associated test along with it.
If I wanted to though, I could choose to, you know, include more of them. But in this case, that will do just fine, so I'll go ahead and proceed. And then when I click run tests, it will trigger that deployment or validation, along with, obviously, running the tests. So So I'm just gonna do that now.
And then I'm predicting that this test will fail, due to a lacking test coverage, which is exactly what we wanna catch early on. So it's brought the pain forward to now rather than leaving it to production. So if this was genuine work that needed releasing, we could now go back to the org, fix that problem, and retry again once we've got enough coverage, ensuring that, you know, nothing makes its way over to the next environment without being truly complete. So, so, yeah, just a bunch of built in functionality there.
Now moving on to the next part of our presentation, which is speeding up promoting changes through your workflow, without automation, I'm gonna be covering a bunch of different things. So, deployment history, cloning packages, combining packages, and some additional Git specific functionality.
So let's navigate over to that. The the user story in this case is that I'm a release manager, and I'm promoting my changes through to production.
Everything that we've shown so far has been pre deployment, but now we're obviously moving on to the history. So this is obviously a list of all of the deployments that have been made by me and any member of my my team. Firstly, I wanna describe the use case for the deploy to target functionality.
So as an example, you've recently deployed, say, from your dev environment to a UAT environment. Everything has been approved. It's been tested just fine, and you simply wanna deploy that exact same package to the next environment in your workflow, perhaps pre prod.
Deploy to target does exactly that. No need to run a comparison. No need to make adjustments. No need to run a problem analysis.
You already know that that package works in that lower environment. So it will simply take that exact package and attempt to either, you know, validate or deploy accordingly.
This makes very light work of promoting changes to multiple further environments, so that's perfectly suited to, you know, smaller features or releases.
Just navigating back now.
Next, I'm gonna talk about the clone and combine features. So imagine a similar scenario to the previous one where you'd like to take the package and deploy it to another environment. However, in this case, you would actually like to, you know, see the current state of your target environment before you make that deployment. And in that case, running a comparison makes perfect sense. So that's what clone package is for. So this will allow you to select a source and target of your choice, and then we will automatically populate the filter according to the components that were in that original package, and then you can run a comparison between those two environments.
To add further flexibility, though, we've also got the option to do this whilst combining multiple deployment packages together. So that's that's actually what I'll show you now.
So you'll notice these checkboxes on the left hand side, that relate to these two deployments, so release part one and release part two that are both in pre prod. If I make the selections and click combine package, you'll get basically the same model, but it's telling you exactly which, packages we're gonna be including.
The source in this case is gonna be my pre prod environment because that was the target of both of those previous deployments, so I know that all my changes are combined within it. And then the target in this case is gonna be production.
I'm just gonna load up that comparison.
The filter that it would have used will be a combined filter that was used on each of those, deployments, so to make sure that we include absolutely everything that we need to.
But, yeah, on this comparison screen, you'll notice a couple of things. Firstly, that everything that was part of the original package has been preselected, so you don't need to remember every single component.
And secondly, as per any normal comparison, you've got the option to make adjustments. So I can, you know, remove one of these components should I want to.
It provides, you know, a plenty of flexibility, and that could be very handy for staging releases to production. So perhaps you and your colleagues have made several deployments to pre prod, and now you can combine and clone everything and then release it all the way to production.
Finally, on here, I wanted to show you this last bit of functionality, which is rollback, which is some really, really useful functionality.
So whenever you run a deployment in Gearset, we'll automatically take a snapshot of your target environment, prior to a deployment taking place. So that way, we've got a place in time that we can return to should we need to, a safety net for any deployments made in Gearset. So in case of rollback, Gearset will be able to run a comparison between this snapshot and your org's current live state, and then you can use, you know, you can selectively choose within that comparison whichever components that you want to roll back. So again, full control just like you do with any other comparison. It's just allowing you to undo whatever that previous deployment did. So, yeah, some some really, really useful functionality there.
There is just one final section for me to talk about today, and it's obviously a little bit of a departure.
Everything we've shown you thus far was org to org, which which is obviously a common workflow especially for smaller teams. But some of you may have already integrated version control into your process or are perhaps considering it for the future.
As a lot of you know already, we integrate with all the most popular Git providers, so Bitbucket, GitHub, GitLab, Azure.
For simplicity, the way that we handle these in Gearset is largely identical to the way that we handle Salesforce source. You can compare, build So if I select source control as my target in this case, I just need to select my repository and a and a source branch, and then what you'll see right from this page is the ability to create a new branch right from within Gearset.
So where possible, we like to avoid you needing to leave Gearset to get the job done. So so, you know, right from this page, you're able to do that. So I can just click here. I can, give my feature branch a name.
Click create branch, and now without leaving gear set, I've now created that branch within my repository, and now I'm ready to compare my, you know, developer environment or any org that I want to to my new feature branch.
Once again, removing the lead you know, the need for you to leave the app and break your flow and, you know, nothing else.
So this is obviously very, very convenient.
I could go ahead and start running this comparison, but, obviously, as we've already seen that today, what we presented earlier, I'm just gonna skip ahead to the end of this process right after I've made a commit into my new feature branch, which is my, commit successful screen.
And as you can see, you'll be presented with the option to create a port request right from this deployment results screen.
You simply need to select a target branch, customize it as you see fit, then click create a pull request. And once that's done, your PR is gonna be ready for review by a colleague.
So once again, removing the need for you to leave the app at any point. So, you know, this is much, much easier for teams to adopt, especially if you're, you know, a team that's a bit less familiar with Git. You know, you don't really need to leave the app at any point.
And then finally, the last bit of functionality, which is, you know, a little known to to customers, especially if you've not, handled repos recently, is our repo dependency cleaner. It's very common for your Git repository to build up a collection of metadata that's missing its dependent files. So as an example, let's take an Apex class. At some point, a class was deleted from my repository as part of, you know, sprint, as part of normal work. The deletion took place just fine, but the permissions for that class are still present in your repository. And these permissions aren't in a deployable state, nor would you want to deploy them as they relate to a class that no longer exists.
So our cleaner is targeting these, these components and removing them for you, saving you need to do needing to do it manually.
The cleaner is automatically run on a target branch when the commit contains any changes of any sort. So, so so, yeah, in this case, I can see that I was, you know, committing a couple of deletions, a couple of classes that I wanted to remove, and then we've got a separate tab here for the repo cleaner, which has also gone ahead and, and removed a couple of unrelated, Apex class permissions.
So, automatically keeping my repo in a in a very good state, in a deployable state, so I know that everything that remains within it, I can then deploy further on to an org. You you know, sort of saving you that kind of post deployments that having to do it. But, but, yeah, that's everything from from my side. So, I'm just gonna hand you back over to Maria to bring it to a close.
Thank you, George.
Let me just share my screen now.
Can I just make sure I'm on the right screen in your set? Yeah. Okay. Cool.
For those of you who are new to your set or just haven't come across these really, now I just want to show you a few places where you can find support and learn learning resources. And I know that in the chat, some of you were asking about this, so I think it's it's good to know. One place that I I want to highlight is our intercom chat. From any place in the app, if you click this icon, you can speak with one of our customer support engineers.
You can just start a chat with them. Or if you want a more self serve option, you can click in help, and then you can type keywords to find things like, for example, version control. And I could type control the keywords, and it it will give you all the articles about why don't more use Steam is to use version control, for example. This is a way that you can explore resources on things that you're looking for. And if you're stuck, then you can just come to the messages and message someone in your set.
Another way to stay on top of what your set is releasing and what is changing is coming here to what's new. And this is our change log where you can see what has changed recently in your set, so you know what new features are coming out available to you. And most of them will have documentation for you to read more about this as well.
Our blog is also a great source for learning more about DevOps.
Gear Sets blog post, has a lot of how to guides, best practices, events, gearset news, knowledge about sales Salesforce, gearset, DevOps. And one thing that is very I highly recommend, if you click here, it takes you to the DevOps Launchpad. DevOps Launchpad is our platform to learn more about Salesforce, DevOps, gear sets, and is a great place to start, because it's interactive, and then you can learn more about topics that you are wanting to deepen your knowledge, with our training courses.
I hope you found this useful, and after today, you'll be able to maximize the potential of your gearset usage and deploy Salesforce customization even quicker and more efficiently. I'll stop sharing my screen now, and I just want to ask if there are questions that anyone wants to ask us that were not answered yet.
Yeah. I've just made it possible if we would take themselves off mute if they want to. So, so, yeah, feel free to do that and ask us a question.
Meanwhile, I'm just gonna have a look through the chat, see if there was anything else that's gone unanswered, but I think the team's been pretty hot on it so far.
Yeah. No. It'll be A second what Alice is saying in in the chat.
Yeah. Exactly. Lots of places to learn.
Cool. Alright. I think considering that there's no additional questions and nothing further coming in, thank you all for for your time today. Really appreciate everybody's time. Azela said, we're gonna be recording and sharing the slide deck and everything else along with this session.
And, yeah, look forward to seeing you all on the next one. Thank you very much.
Thanks, everyone. Bye.
