Salesforce is piloting brave new tools that will make it easier for Salesforce developers to practice continuous integration and source-driven development.

If you’d rather not wait out the pilot phase, there’s a lot you can do today to get ready for Salesforce DX. Since Salesforce DX is a great toolset but it is not a turnkey solution (and neither should it be), you would need to do much of this same work regardless.

Bootstrapping Source Driven Development

This explanation is intended to orient novice package developers by quickly covering the fundamentals at a high-level. Contact me through the DreamOps Success Group for help with the lower level details.

Starting Out

When you first begin to develop a managed package, the natural inclination is to create it directly in the packaging org, and quickly upload your first version.

Before long, you realize that this approach doesn’t scale well, and you start to wonder how to get started with continuous integration and source-driven development.

Looking at your packaged code, you might wonder how to about removing the namespace references and transport the metadata to another org.

Namespace Prefix

Generally speaking, the namespace prefix isn’t an issue. It appears to be attached to the classes, but its not really hardcoded. You can retrieve the metadata using the Ant Migration Tool, and the namespaces disappear.

Transporting Metadata

Once you retrieve the metadata to a local folder, then you can deploy the metadata source code to some other org, without the prefixes. When you deploy it back to the packaging org, the namespaces will appear to be prepended by the platform. It’s really quite magical.

Ant Retrieve Deploy

Here’s a streamlined Ant build file I posted for a different purpose, but it would work in this context as well.

Version Control

After pulling the metadata out of the org, you will want to check it into a version control repository like Git. One popular host is GitHub, which will also work with the upcoming Salesforce DX toolset. (Though, I use Bitbucket myself.)

Both Github and Bitbucket have excellent getting started instructions, so I won’t cover that point here.


If you have access to Trialforce, my best advice is to use a Trialforce Source Org to generate trial orgs with the unmanaged version of your code. Then your developers can use a separate org for each feature or task.

A separate developer edition org for each developer will also work, but, honestly, it’s a huge pain, and the reason Salesforce is giving us scratch orgs. If you use a developer edition org, the Financial Force Deployment Tools ( can help you maintain your environments.

If do you use Trialforce and map each development feature to a trial instance, then you will be very well aligned with the Salesforce DX scratch orgs when they become available.

Continuous Integration

To actually do the continuous integration bit, your developers can clone the Git repository locally when they begin a task, create a feature branch, and then sync the local source with their IDE. (We like the Illuminated Cloud IDE the best, but that’s a religious question.)

When the development task is done, the developers can commit the changes to the Git repository and create a pull request to bring the feature branch back into the master branch. When the pull request is resolved, you can deploy the master branch to the Trialforce Source Org, to be sure everything deploys properly and the tests pass.

Then when you are ready for a new major version, deploy master to the packaging org instead (and the namespace prefixes magically appear).

But wait there’s more

This description just catches the surface, but it should be enough to get you headed in the right direction.

There are some more in-depth resources on this page:

It’s a lot I know, and if you search around, you will find a number of resources about continuous integration with Salesforce.

Return to Best Practices for Enterprise Development on