º£½ÇÌìÑÄÉçÇø

º£½ÇÌìÑÄÉçÇø 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 º£½ÇÌìÑÄÉçÇø 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 º£½ÇÌìÑÄÉçÇø

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 º£½ÇÌìÑÄÉçÇø, 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

º£½ÇÌìÑÄÉçÇø 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, º£½ÇÌìÑÄÉçÇø 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.

Browser restrictions

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.

Teams have even more options for their metadata deployments with º£½ÇÌìÑÄÉçÇø’s file on disk support! And º£½ÇÌìÑÄÉçÇø’s metadata deployment solution can help with other complex metadata types like flows and CPQ too. Learn how we could help you supercharge your release management by booking a consultation with one of our Salesforce experts.

See how else you can improve your metadata deployments with a of º£½ÇÌìÑÄÉçÇø today.