Description
In this webinar, Gearset teamed up with the Welkin Suite, the developer-friendly IDE for Salesforce. See how easy end-to-end development automation can be and learn best practice tips from the market leading developer tools for Salesforce!
Catch up on their discussion on how to make and commit metadata changes to source control using The Welkin Suite, how easy it is to deploy those changes out to your Salesforce orgs with Gearset, and how to set up continuous integration to auto-stage any new code straight to your orgs through Gearset.
Learn more:
Transcript
Hello, everyone, and welcome to the Salesforce Development and Deployment webinar with GearSat and the Vulcan Suite. My name is Vladimir. I'm head of product at the Vulcan Suite and head of Salesforce department in the SAFeam company. And today, we will talk to you together with Jason from Gearset.
Hi. I'm Jason. I'm the customer lead here at Gearset. Our role is to make sure that everyone who uses the app gets the absolute best experience possible and can experience themselves just how quick and easy deployments can be on Salesforce with Gearset.
Cool. And you'll see this today, I guess. So in the webinar for the next forty five minutes, we will, start with a brief overview of who are the welcome suite and who are the Gearset. Then we will show you how you can easily develop using the Vulcan suite, and then you will see how you can easily deploy your code and metadata with gearset.
And at the end, we'll have about ten minutes of q and a session. And in case if you have any questions as we go, just feel free to ask them in the questions pane, and we will try to answer them as soon as we can or at the end of the webinar. So let's start. And first of all, I'll introduce you the Rokin suite.
It's an idea that was created for Salesforce development especially. We started working on it about three years ago when we understood that existing tools does not meet our expectations, and they doesn't benefit our Salesforce development teams. They just waste their time trying to fight these tools. So Zwoken suit is an IDE built for Windows and for Mac as well.
On Windows, we are using the Microsoft Visual Studio shell. And on Mac, we are using the mono develop IDE shell. So you should be familiar with the tools or you have at least seen them. And our main goals are to provide you the best experience, the best performance in both, like, the ID itself and as well as your, like, common day to day tasks.
So we are trying to make you your life easier and more productive.
Gearset's a tool designed to make release management on the Salesforce platform ingeniously simple.
So the core of the app is the ability to quickly see the configuration differences between your environments, whether that's metadata that's stored in source control or directly in your Salesforce orgs. When you run a comparison, Giset will then show you the differences in the XML line level with automatic change highlighting, removing the need for the manual text ifs or change tracking documents entirely.
Once you've seen what's different between your environments, you can then deploy out those changes with just a few clicks, and Giset automatically identifies object dependencies and include components you need in your package.
This adaptive dependency analysis is one of the defining features of Giset, which really sets it apart from any other deployment tool on the platform.
Just like the welcome suite, we also believe in automation wherever possible to remove those slow manual tasks.
Automation takes several forms in Gearset, including tracking all changes with daily snapshots and change reports, easy deployment rollback, testing automation, and code coverage tracking, and continuous integration, which you'll see a little bit later on in the webinar.
All of these automation tasks are managed by the app's interface with no coding, XML editing, manual package creation, or configuration of Jenkins required.
Gearset was also designed to integrate with your existing development flow, and you'll see in the demo shortly how easy it is to make some changes using an IDE such as the Vulcan suite and then push out those changes into your orgs with Gear Set to test them with your end users.
And with that, I will hand back to Vladimir so he could show you how easy development can be with the Vulcan suite.
Cool. Sounds very cool. So let's let's start.
Okay. So here right now you can see the work and field, UI. And our main idea of the UI is to provide you as many information as possible. So later you can decide what exactly information you'd like to see, in what way you'd like to see. And also not only information, but also also most important and crucial for your actions should be available in the UI so you won't leave it to for another application or so you won't switch to the browser, for example.
And, of course, your UI or, like, layout of the tool should be configurable so you feel comfortable in your environment. For example, right now, I have more, like, Java style layout here. But me being a dot net developer in past, I prefer to have it a bit different way. So I move solution explorer to this part, test results somewhere here. Oh, it'll be here.
Okay. At least in this way, it's more comfortable for me and I feel better. So what panels do we have else here except for solution explorer and test results? We have code coverage information which shows you information about unit tests, about your classes, triggers, and code coverage about them.
We have debug logs panel. We have information about your lightning bundles here. We have version control. So lots of different information in lots of different panels, and you can just do whatever you like with them and consume all you needed information.
So I guess I'll start. I I'll spend some minutes on the solution explorer because it is a bit different comparing to any other ideas or, like, developing tools for Salesforce.
To be honest with you, we don't like the way how project structure is done in Salesforce. We don't like that flat structure where you have your classes, like layouts, objects, pages, folders with hundreds, at least, files in each of them. We prefer to allow you to create your custom folders and organize the project, like, in the way it will be most comfortable for you and the way you spend less time. For example, I have created custom folder called demo where I have all the files which I'll potentially need for my today's demo.
I have created separate subfolders there where I've gathered some of my unmanaged packages. And you can also notice that I have here a mix of different types of files. So I have Visualforce page with Apex class with something else. Not just Visualforce pages and classes.
So in this way, you can easily organize, for example, your Visualforce pages with their controllers, with components, add to them unit tests, maybe static resources. All of this in the same folder so you don't need to scroll here and there in the solution explorer. Just easily find a needed folder and start working with it. Okay, so let's proceed.
And I've opened this project. I've downloaded from the git repository and started working to with it. Or in case if you don't use Git or if you don't like Git, you can just create a new fresh project from your organization, enter your credentials, and jump in and stop working.
So now let's move on to some changes and kind of development and let's imagine some pretty simple but very common situation.
For example, you have a bug or issues that was reported for you by your customers or by Q engineer or for example you have found it yourself.
And me being a fan of TDD, I have previously created a small unit test which just tests that issue and right now it is red so it's failing. In order to get to this unit test, I will open test results panel, navigate to my test class, and I see this failed unit test method.
Here in the panel, I see messages from Salesforce like assertion exception and stack trace. In case if I want to fix it, I need some more details. So I press the open log button and I will see the debug log log opened immediately here in our own debug log viewer.
And what do we see here? In the upper side, we have hierarchical tree like view of your execution flow, which is very helpful for situations when you have lots of nest nested calls, lots of triggers or very complex code in general. It's very easy to find something interesting here in the preview.
Click on it and you'll get navigated to it in the regular text view.
Once you find something interesting you just switch to the text view and proceed working with the regular, text viewer logs.
In addition here, we also have some pretty simple but very useful cover highlighting of different types of events. For example, you see that user debugs are green and pretty obviously exceptions are red.
It's also very nice to see any exceptions in the code map which is shown on the right side. You can easily notice all the red items and navigate to them.
Another way to find something interesting in your log file in case if it's not, like in my case, one hundred and fifty lines of code in if it's, like, five thousand or ten thousand of lines, you can just press this filter button, select none, and then just select whatever you'd like to see in your log file.
Done. And once you found an interesting place where you need to investigate something or to fix something, I suggest you to use one of my favorite features. It's one of the smallest features in the work institute, but I really love it. It saves me a lot of time in my usual development work when I do something in Sales I can just right click on any entry in the log file and select go to source. This will lead me exactly to that line in the source code which has shown this exception in my case.
And if this won't be an, like, short demo of fifteen minutes or if it would be some more complex situation, some more complex bug, I'll show you our own retrospective debugger, which helps you to investigate any complex issues or just to understand how your code works. In my case, it's very simple issue and we are working on time, so I will do this without the debugger.
Right here, we see that our assertion expects seven and we are calling some method and passing here parameter six. So I right click on the method, press go to definition and I see that it returns exactly the same number that it received.
And I guess that the issue is not in this class but in the unit test because in the in Apex Doc I see the description that it should return the same value it received.
So I close this method, I fix my unit test, do some changes so I want to add some notes that it was fixed by me right now. So I use our feature to generate Apex Doc header, write some description here, for example save the file and then I use one another small but anyway time saving feature from the working field. I'll go to the build menu and select build and run tests. This option will send this file to Salesforce. It will detect if any tests were changed as a part of this I'd say, deployment.
And if any were changed, it will immediately execute them. So I press build and run tests. We see our build process started.
It took three seconds to save changes to Salesforce, and we immediately see the results in the test results panel. So I don't need to switch to browser, don't need to go to Salesforce UI. I just immediately see that my unit test is right now green. So I'm absolutely happy.
And once I've done this change, I guess I need to commit it to the git so my teammates would see it. So I switched to the Russian control panel.
I'm right now on the changes tab, so I see what was changed by me. I see that it was a class itself. Okay. It was a work file that I have downloaded.
I'll just exclude it as a project file itself. Okay. I'm happy. Just write some commit message And press commit.
But before I proceed and go on, I'll show you some more cool things in the work institute. So even that we are focused mostly on the coding development like Apex, Visualforce, Lightning development, HTML, CSS, we also started recently started to work in the direction for declarative development and we already have some cool and nice features in this direction. So I'll show you them.
In our sObjects editor, you have option to modify your sObjects, their fields directly in the XML file if you know it good and if you prefer to do it this way. However, if you don't like to work with the XML file, you can easily open our, like, graphical UI and modify your fields or create new ones just from here.
Other things that saved me a lot of time is the, like, recent deployments.
It was a Figaro Security Editor. This, editor allows you to easily configure FLIs for different profiles for different fields at the same time. You can just easily change your FLIs very quickly. You have lots of different quick actions, lots of filtering options, so lots of time and useful stuff which is built to save some of your time.
And doing the same approach we have used for the layouts tab.
So it just allows you to add or remove any fields from the layouts.
Okay. So let's move more on and get back to our git. So you might know that the local field does not support all the metadata types which are available in Salesforce right now. So in my project, I have included only classes, pages, like, five or ten different types of metadata. However, if you store your project in the git repository, it should be very helpful to have the whole metadata in the git repository.
To do this, I spent about twenty or forty minutes, of my time just to build very simple, untask which retrieves some of the metadata types from Salesforce.
And also I built very small four line bot file which executes this untask.
In order to start it, I don't need to switch anywhere. I just open the open field in the tools menu. I've created a quick shortcut to execute this AMP task. So I press retrieve Azure Metadata.
It starts my AMP task.
It starts to download something.
Let us check. Okay. In three seconds, it downloaded something, so I press any key. And I see that it downloaded me app minus. Maybe it was created or maybe I have just not included in my Git repository previously.
So all the metadata that was downloaded in such a way should be included in the git repository.
So I do another commit and press commit button. Now I need everything to appear on the remote so Jason would be able to show the show the magic of gearset.
I switch to the sync tab.
I see two of my commits. If I want to see I want to show details of what exactly was changed, I can double click on each file, and I see a built in diffuser which will show me what was changed as a part of this commit. Okay. I'm happy with these changes, so I get back to sync.
Press push. Enter my login and submit.
Nope.
Let me try once more.
Nice. I forgot my credentials, but I have them saved in another tool. So just give me a second, and I will pull these changes.
Okay. I was not able to push them using silicon suite because I don't remember my credentials. Nice. But I've pushed this using another, like, Git client, so all the changes are should be now on the remote repository. So Jason is now able to show us all the magic of the gear set.
Thanks a lot, Vladimir.
Hopefully, you can all see my screen now on the gearset app.
So I'm gonna start this gearset demo by picking up exactly where Vladimir left off after he's committed that metadata into source control. So what we're gonna do with Gearset is we're going to run a comparison between that repository that we've just pressed those changes into. You can see here on the left. And we're gonna push those changes out into a Salesforce org on the right here so we can actually do some testing with our end users.
Now when you run a comparison in Gearset, you start by specifying the source and target locations for your metadata. So this can be two different Salesforce orgs to each other and you develop a sandbox and production environment. Or in this case, we're going to run a comparison from our source control repository out to a target Salesforce org. So I've selected the repository and the branch you want to use here, and I've selected my org that I want to push to for my saved connections.
Now if I want, I can hit compare now to kick off the comparison straight away. Or what you I also want to do is set a custom deployment filter here. So what this does is allow me to specify which metadata types I want Gearset to retrieve when running the comparison so I have a little bit more control over which metadata is gonna be deployed.
So now I've selected my Apex filter here. I'm gonna hit compare now to kick off the comparison.
What Gearset now does in the background is it's logging into your source and your target. All of this is done via OAuth so you don't have to worry about Gearset having access to any of your credentials or your Salesforce orgs. Gearset then downloads the metadata from your org using the Salesforce metadata API. And once it's downloaded, it actually starts to do a comparison on it so it can show you what the differences are between these source and target environments.
Once you get the comparison complete, you have the results shown on the table view like this. So in the top half of the screen here, we can see there's that Apex class, the method calls, which has been modified. And if I actually look in the lower half of the screen here in the diff viewer, I can see exactly what those modifications are. So there's the description here, which is modified by Vladimir during the webinar, and a little bit further down, there's the change to the, cert there in the test.
So this I can see very easily is what's the difference between my source here, which is my repository, and the Salesforce org that I want to push this out to. This gives me a really easy way to get that insight into what changes have been made in my orgs. If there were any other developers doing work on this environment, I could see what they've been up to. It just helps me start avoid stepping on each other's toes and making sure deployments go as smoothly as possible.
So all I wanna do is now I've seen these changes and I wanna push them out, I can simply select this object to include it in my deployment package, and I'm gonna hit next.
What gearset is now doing is checking for any other missing dependencies or components I might want to include in my deployment package. So in this case, because it's a very simple Apex class we're just deploying out, there aren't any other missing components and we're taken straight through to this pre deployment summary.
So you can see here we've got the list of the objects we're about about to change. You have the summary of your source and target just so you can be sure exactly what changes you're pushing. And down the bottom here, if you want, you can add in deployment notes. So I will call this demo deployment for webinar.
These deployment notes get carried through to the reports that are generated after the deployment completes so you have a more complete audit trail. And if you're actually pushing changes into a source control repository, then we use these for your commit message.
Now at this point, if you want, you can use gearset to create and download your actual deployment package. So this will be the valid package with your package XML and your metadata contained within it. And if you even have destructive changes, so you've got a deletion you want to push through, then those will be included in there as well.
You can also export this to Excel if you want a a CSV summary. You can kick off the deployment right away. So this will immediately push this change out to your target org. If you want, you can do things like specifying tests that you want to run, or if you're pushing up to something like a sandbox or a developer org, you can force tests not to run. But actually, in this case, what I want to do is run a validation, which I'll just kick off now.
So the validation is what's called a check only deploy in Salesforce.
So what Gayset does is it builds your package, uploads it to your Salesforce org, and ask Salesforce to run any tests on it, but doesn't actually apply any of the changes.
So this lets you test the validity of your package prior to release, and it's also a great way if you want to test something prior to a scheduled maintenance window or just be confirming that what you're deploying is about to be, valid.
You can see here that this package has been through validation, so I've got the message here, the components that were to run, any tests that were running it as well.
Now that it's been validated, I have two options for deployment. I can deploy manually, kick it off straight away, or if you want, you can also take advantage of a little bit of automation here by scheduling this deployment for a later date. So to do this, all I would do is choose a date, so let's say tomorrow, and a time, say eleven PM during a maintenance window. And then when this deployment completes, I want to send me an email and actually I also want to include my team so that the rest of them get the notification that this release has gone out.
Now if you click save here, Gearset will create this job and automatically schedule this for deployment at that date. What I actually want to do for the sake of the demo is deploy this change out right away. So So I'm just gonna hit deploy now. And what Gaze it does is now uploading this package to your target org, queuing the deployment with Salesforce, and deploying those changes out.
Now because we've been through the validation first, I can be extremely confident this deployment will succeed because we've already been through that validation stage. And you can see here, this is a very simple change, only took a few seconds to deploy. And we have this Apex class now, which we modified in the Vulcan suite. We then committed it to source control, and that's now been pushed out into our target org so we can actually test that with some end users.
I've actually just got an email as well that this deployment is completed so you can see that in the top right. We have our deployment notes which have been included here so I can see that my reference and some key information about the deployment here.
Now if I want to, I can download the full report here of this deployment as a PDF. So if I open this up, you'll see here that I have the deployment successful. I have my source and my target orgs. I have the, objects that were deployed, deployment time, those notes, and then the list of the actual components that were included as well. So these reports give you a really good overview which you can share with colleagues or if you have a, change tracking system you want to attach these to, they can be used there as well.
So this is obviously a great way to manually push those changes out once you've created them and you want to stage them in your orgs. But we talked a little bit earlier about using some of the automation in Gear Set to help remove some of these manual tasks and speed things up for you. So what we're actually gonna do now is we're going to jump across and create a continuous integration job in Gearset so that any future changes that we commit to that source control repository will be automatically deployed out to that target order for staging.
Now the way we do this is I jump to the CI jobs tab in the app, and I'm going to click add new job.
What I do here is I start off by giving the job a name. So we'll call this Vulcan webinar job.
I then choose the source environment for my metadata. So this can either be a Salesforce org or in this case, actually, I'm going to select my GitHub account because that's where we're pushing those changes.
I then choose the repository from the list, and I specify my branch. So in this case, we're gonna leave it on master. So anytime that a future release is merged into the master branch, we want this automatically staged out as part of our release process.
I then choose my target environment, which is gonna be the staging org that we used before, And I now specify how often I want this job to run. So by default, it will be on a time basis. So every four hours here, for example, this job will automatically query this source branch for any changes and deploy those out to my target org. But actually, I want a little bit more control over this and there are no there are certain times when I'm not gonna be making changes and I don't want this job to just run unnecessarily.
So actually, I'm gonna specify here run job when the source branch is updated, and this will create a webhook in a second when we save the job, which I can set up in GitHub so you have an automatic triggering of a deployment when your source branch is updated for that full end to end LMM automation.
Next, I'm gonna set up my notification settings.
So Gearset allows you to get notified when things like deployments or continuous integration jobs run so you can keep your team aware of what's happening. In this case, I actually only I'm not interested every time this job runs. I'm interested every time this job runs with a failure. And if that happens, I want Gearset to send me an email so I can get notified about it and start fixing it. And, actually, also, I want this posted into the chatter in my orgs so I have that background knowledge.
Finally, I'm gonna specify the metadata filter for this job to use. So for those of you who are familiar with Ant, you have a list of metadata components here which you can select in your deployment.
This specifies which object types you want Giaset to retrieve as part of your CI job. So you have things like apex classes here. You've got global value sets. You have profiles, permission sets, custom objects, and a few others as well.
Now in this case, because I know that I've only been working on Apex classes and I want this job to just press new Apex, I'm actually gonna use that filter that we used when you're on the manual comparison called Apex, and you can see here that that just has a few components selected here for this job to monitor.
If you want, you can also set jobs to monitor and deploy changes associated with managed packages. So you can specify those here. I'll just take all. And what GoSet will then do is retrieve those components as part of the package and deploy those as well.
Finally, if you want, you can specify the API version to use. By default, GearSet walls must identify the highest conversion between the two of them. But if you want to specify, so for example, working on b thirty nine here, then you can do that.
When I click save, GIS, it now creates the job, and you can see here it's providing me with the information with my payload and my shared secret to set up this webhook in GitHub. So what I'm gonna do is I'm going to copy my payload URL. I'm gonna jump across to GitHub. You can see here we're in the Vulcan webinar, repository under the settings and the webhooks. Obviously, the webhook setting depends a little bit depending on the source control provider you're using, so we support not just GitHub, but also GitLab, Bitbucket, VSTS.
Click add webhook. You can see here I've got my payload URL to enter. So what I'm gonna do is I'm gonna grab that here from Git from my, gearset, drop that into the page URL, leave the content type as the standard. I then have my shared secret to enter. So, again, I'm gonna grab that from gear set, bring that across, and drop that into my shared secret.
I'm gonna leave this with just the push events, set this as active, and click add webhook.
So what you've done now is you've created this webhook in GitHub here. You can see that's been created. I'm gonna click finished in gear set, and you can see that job is currently sitting there as status of pending.
So now anytime anyone pushes a commit into this master branch in my repository here, GitHub will automatically ping out a message to Gear Set, and that will trigger a deployment to push across any new Apex and automatically stage it in my staging log. So this completely removes any need for that manual steps and just makes the automation incredibly easy and simple to set up.
You can see here I've also got a few previous jobs that I've set up between orgs. So continuous integration jobs, just like deployments, we track your full deployment history. So if you want to, you can jump into the history for any job to see any previous runs. And just like for a manual deployment, that history contains information like the number of objects that were deployed. You can grab the PDF reports. You can grab reports of those as a CSV file, and you can grab the package as well. So you have that full history maintained throughout the entire process.
Finally, if you have a CI job and you want to run it on demand, so you have, for example, a webhook or you know you want to take a deployment prior to a big release, you can also click run now and you'll have the live status reporting there as this job kicks off. So you can see here this is now starting to run a comparison and download the metadata between these orgs.
So that gives you a quick overview of how to do comparison and deployment with Gearset and then how to set up that continuous integration for the full automation.
I'm briefly gonna touch on one or two other features in the app before we jump back to the q and a. The first one is something that goes hand in hand with the CI for the automation, which is called our org change monitoring.
Now the idea behind this is sometimes you might have people making changes directly in an org, which fall outside of your user release process, and you want to make sure that you don't accidentally overwrite those changes next time you come for a scheduled deployment.
So with the change monitoring, you can create a job, and Gearset will take snapshots of your org's metadata on a daily basis, and that can also be run on demand as well. And it'll then show you the comparison differences between those snapshots. So you have a day by day change history for any org, not only what changes were made, but you can see who made them, and then you can actually jump into that full line by line diff view to see what they were. So as an example here, I have a production environment, which I'm monitoring.
I know it hasn't been changed in the last day because it's currently showing as identical. But if I want to see more information about this org's change history, I can jump in there. You can see on the days where this org is identical and some days here where people have been making modifications to that org. And if I want to, I can jump into the comparison to actually see what those changes were, who made them, and see the line by line diff to actually understand, are these something that I might want to pull back into my source control system?
Are these things that I'm happy to override to my next deployment? Do I need to go and talk to this person to understand why these changes have been made?
If you want, you can also perform deployment rollback from your history of monitoring jobs and even download the snapshot of your org as a zip file.
The final thing I want to show you is talking about history there. So Gearset is designed to not only make deployments easy, but also make porting and audit trail extremely easy as well. So every deployment you run-in Gearset is stored in your history. If I jump across here under the deployments tab into the deployment history, this will show me a list of every single deployment that's been run-in the app.
I can see here the whole history of deployments between orgs and source control. And for any of these deployments, you can grab the full reports. So you've got that PDF that we looked at earlier. If you want, you could also grab the CSV export and the original package just like before.
So if you ever need to see what happened in a previous deployment, you can. There are also a couple of other features that you can do to make management and automation a little bit easier from here. One is the ability to do full or partial deployment rollback with GearSet, which you can do in just a couple of clicks. And we also have the ability to do cloning of packages.
So if you want to apply the same set of changes you've applied to one org down your release pipeline without building that package manually every time, then you can do a clone from there.
So I'm gonna stop there. That's a quick overview of we've seen how to commit some changes into source control using the VELCON suite, how to then pick that up and deploy them out to your orgs with GearSet, and then set up some simple automation with continuous integration and monitoring to check for any further changes to those orgs. And with that, I will hand you back to Vladimir, and we will move across to the q and a.
Thank you. And so questions and answer. If you have any questions, just feel free to ask them in the questions pane, and me and Jason will be happy to answer them. Or in case if you want fit in time, we'll answer them after the webinar to email or in some other way.
So we have, first question, I guess, it's about working field. So why when you ran the end script to commit to Git, did you have to do that?
In general, I ran the end script not to commit to Git, but to download different methodators to the same, like, projects that I've created in the working suite. By default, working suite supports about fifteen or twenty different methodators from the Salesforce.
However, there is about, like, one hundred of them. For example, I don't know, like, your workflows, validations, your process builder flows, your visual flows, all the stuff is different methodators.
And we do not support all of them, but it's very good to have everything related to your organization in the same Git repository.
So I've executed that, git oh, sorry, unscripted to just download that one so that WorkInSue doesn't support. It's needed only when you stop when you want to commit something to the repository, and you can just do whatever you need in your day to day tasks. So you don't need to do this all the time, just before you commit this tool. Other question from Kate.
Jason, can I see the questions?
Or I can't, unfortunately.
No. So you'll have to read them out for me.
Okeydoke. So we have a question from Kate. Does GearSet support those MDC component types?
Yes. So GearSet will support anything which can be deployed by the metadata API. So if any of you are familiar with using the forced migration tool or Ants, if it's deployable by that, then it's supported by GearSet, which is, significantly larger number of components than are supported by Change Sets within Salesforce.
So, generally, yeah, if you're working on it, you can deploy it.
Okay. And one more question to you. What is a partial rollback?
Good question. So the way rollbacks work in Gearset is once you run a deployment, we obviously have that saved in your history. When you click rollback, what Gearset does is it runs a comparison between snapshots of your org, which was stored just prior to deployment. This happens automatically in the background.
You don't have to do that manually. We'll then run that comparison between the snapshot and the org's currently live state. We'll show you the same diff results. So you get the line by line diff.
You get the objects that are changed in that table, and then you can select which components you want to undo. So the process is very similar to running a normal deployment in that you can see exactly what components have changed. If you want to do a full rollback, you just simply select everything that's changed between that snapshot and the org's live state. But if you wish to select just, for example, a field level security setting on a profile that's changed that you accidentally moved across, you can select just that component and deploy it out.
And that way, you can do very, very specific deployments or rollbacks on just the components you're interested in.
Okay. Thanks for the answer. We have lots of other questions, so I guess I'll try to go through some of just that are related.
So, again, question for you, Jason. Does CI jobs support GitLab or only GitHub?
Yeah. That's another good question. I, I should have mentioned that in the demo. So we support GitHub, GitHub Enterprise, GitLab, and Bitbuckets, as well as VSTS.
You can also, if you wish, actually run deployments from a local folder on disk if you're running a comparison. You got stuff checked out locally. So, yes, we do support GitLab.
Probably because we've had another question about VSTS.
So you've answered this as well. Another one for you. Can GearSat zip up and deploy static resources?
Yes. And we can do more than that, actually. We can actually, unzip a static resource during the comparison and show you the components within it. So it's, for example, if you've got some code or or even actually people include images sometimes within a a zip static resource, when you run a comparison with that, Giza will show you the static resource as a component. You can expand it out in the diff viewer, and we'll show you the components within it. We'll then show you the diff between those components in source and target, and you can deploy just those across if you want.
Nice.
Couple of unanswered questions for you. Just give me a second. Yeah. One more related to metadata types. So once Salesforce exposes new types via API, how long does it take for you to support it?
We're generally very, very quick on that. So we've got a a very good relationship with Salesforce. We're usually part of all of their preview programs and their beta testing for new features. We add support on a very regular basis into the app. So the one of the advantages of Gearset being a hosted app, so it's all hosted on app dot gearset dot com, there's nothing to install in your orgs when you use it, is that we push out updates multiple times a day. So if there are any changes made to Salesforce or any new features that we're working on, we can respond very, very quickly on that. You don't have to wait for the next quarter's release, for example.
Nice. Nice. And couple more again for you. So could you tell a bit more about deployment of managed packages from developer org?
Yeah. So we support the ability to deploy managed packages.
The when you run a comparison and you saw that metadata filter, you can choose which components you want to include. One of those options is to include the managed packages.
When you do that, what we'll do is we'll retrieve the components that are retrievable over the API.
So the managed package object will appear. You obviously can't see the diff within that because those packages are protected, But we'll also be able to retrieve components associated with the package. So if that package has created some custom objects or changes some profiles, you'll be able to see those components in the diff and deploy them out just like, any other metadata type.
Nice. Nice. One more. One more. So can Gear Set deploy permission sets without including all the related objects fields? We've had a challenge with change sets and having to include everything if you if you want to migrate permissions. This is even more difficult when managing permissions for managed package objects or fields.
Yes. I believe the answer the short answer to that is yes. We should be able to. With all these questions, the the easiest way to try it out is actually to give a go with Gearset. So we offer a free thirty day trial. It being a hosted app, there's nothing to install, and, we encourage everyone who's got an interest, sign up, give it a go. If you have questions, you can always let us know.
One more great question. I really like I was personally interested in your answer. So for CI with Gearset, if you set up for Apex changes as you showed and Apex change depends on a new field added to the object, does it dependency get automatically added or will it fail?
That depends on the filter you set up for your CI job. So if you have set the job to only monitor Apex, that won't get automatically included. But if you create a job which also monitors other metadata types, then we will automatically look for those changes and try and deploy them.
Cool.
Cool. Okay. We have a couple of working questions, so I'll try to answer them. In the working ID, is a permission overview editor similar to the profile editor I've showed?
This summarizes objects permissions across a set of permission sets. Right now, now we are working on the permission sets editor. We're gonna release it this week or maybe next week. Not sure yet.
And once we're done with the permission sets editor, we are looking forward to implement some kind of security helper, which will try to grab together all the hierarchy profiles, permission sets, and show you everything altogether. We don't yet have any timeline for this, but it's it's in our, like, backlog for sure, and we are going to do this, like, in in some future. Question about future features that we can expect from the suit.
It's a good question. So right now, we have good plan to use, like, our sprint release on May. We are moving towards it. You can find some details on our blog.
However, right now, our main goals are permission sites ready to run everything related to permission sets. We have huge update for Apex code completion and, like, core systems functionality. We are rewriting it again, and there will be a lot of cool features including it. We are also working on the improved writing support, so we're gonna implement writing previewer, writing completion.
And in general, like, we are not usually publishing our clients because they are changing all the time according to the request from our users, according to the feedback from our users. Well, like, we are releasing new versions each two or three weeks. So lots of new stuff is coming for sure. General question, if this webinar is going to be recorded and if the link will be sent to attendees, yes, we will do this. Maybe tomorrow we'll send the link to everyone with the recording of this webinar.
How is the Hot Keys support in Welkin? I like the feature side but I'm used to doing quick operations in Webex three. Great question.
You can easily assign hot keys to any actions you can do in Vulcan suite. There's, like, a lot of hot keys by default, and we always provide you an option to assign your own. This is, like, another way to do something. And we really encourage you to use hotkeys because they are much faster than the mouse.
Good question. Working to support Git credential caching on Windows. Not yet. Unfortunately, not yet. Our Git integration, like, we have it, it's pretty simple, and it's not yet ideal in our understanding.
So we have lots of plans to implement it in a bit different way, but not not yet. We don't have here, like, any timelines yet. So this will be done, but at some time in the future, and I don't think that this will be in the next two or three months. Maybe later.
Okay.
Another question. Can I get them of both these products? I was just in a project where we were using UltraRabbit, and I was very disappointed.
So for, Gearside, Jason says that they have free trial. We can see it again has a free trial. And in terms of demos, I guess that me and Jason will contact you later.
Yeah. And if you, just to add on that, if you have any questions or you wanna see a slightly more in-depth demo or anything, then just get in touch, and then we're happy to organize that. But we're also happy to chat about how Gearset is generally considered to be a much better tool than Auto Rabbit as well.
And the same for us as well. So if you have any questions or if you want to show it to your team or just to ask for some questions for yourself, again, write us, and we'll also be happy to help you.
Looks like this was all the questions.
So that's it.
Great. Thank you everybody for coming along.
I hope you found that useful.
As Vladimir said, if if any of you have any questions about either GIS or the Vulcan suite, then you can always let us know. Get in touch. You can email either us or you can use our own app chat.
Thank you very much, guys, for your time, and have a great rest of your day.
