Gearset gives you fine-grained control over what to include in your deployment packages, and our automatic dependency analysis helps spot missing components. But sometimes you just need run a deployment from metadata stored on your local machine, or make a few edits to a package before releasing.
The new local file support in Gearset is here to help, giving you the flexibility to run a deployment no matter where your metadata is stored, while retaining the rollback, audit history and collaboration power of Gearset.
On-premise source control? No problem
If you run an on-premise source control system, or do your development work locally in an IDE, you may have your package checked out to your local machine and want to run the deployment straight from there.
Full control over what you deploy
It’s not uncommon to make a few manual edits to a package before deploying it. Perhaps a minor merge conflict means you want to remove a single picklist value from a long list, without excluding the entire custom field from the release. Or maybe the SFDC Metadata API doesn’t support fetching a deployable attribute, so you want to specify it by hand. Or perhaps you need to edit some environment variables or Apex code, but don’t want to change the configuration in your source org.
Deploying from a local file or folder with Gearset
Change sets simply doesn’t support working with local files. With Ant, you’d have to build the entire package by hand without any dependency analysis and no deployment history.
With the new local file support in Gearset, you can run a deployment from a local folder on your machine to the target Salesforce org. The deployment is stored in your history and can be shared with team members, cloned to other orgs, or even rolled back at a later date.
Let’s look at how it works.
1. From the Compare and Deploy screen, choose Local files as the source of your comparison
2. Select either Folder or Zip depending on where the metadata is stored on your device
3. Click Upload folder (or Upload Zip) to open the upload dialogue
4. Select the location of your metadata on your device, and click Upload
5. Once your package has been uploaded, you’ll see the orange tick below the source bar. Simply select your target org and run a comparison and deployment as normal
Package.xml files and comparison filtering
Gearset allows you to apply metadata filters on comparisons. These let you customize what metadata types you want to appear in the results, allowing you to narrow in on only those objects you’re interested in.
If you’ve been editing a package on your local machine, it’s possible that a package.xml file already exists in the folder, along with the metadata you want to deploy.
When running a deployment from a local folder, Gearset will scan for a package.xml file, and automatically use it to filter down your results. Only those metadata types defined in the package file will be displayed in the comparison. The package.xml file will overrule any metadata filter you’ve set for your comparison through Gearset.
This should help you focus on deploying the changes you’ve been working on by ignoring extraneous objects which don’t exist in the local folder.
Some older browsers do not support the ability to upload a folder. See the table below for more information about which browsers support local file uploads in Gearset.
|Browser||Local file support|
|Chrome||Yes (Folder & Zip)|
|Firefox 48 and newer||Yes (Zip)|
|Internet Explorer 11 / Microsoft Edge||Yes (Zip)|
|Safari 9 and newer||Yes (Zip)|
|Firefox 47 and older||No|
|Internet Explorer 10 and older||No|
|Safari 8 and older||No|
We hope the file on disk support will be a great addition for many of our power users, unlocking even more ways to deploy your metadata. As always, if you have any feedback don’t hesitate to get in touch at [email protected].