Salesforce is a unique development environment. With its declarative nature, many customizations require no code at all (e.g. creating custom objects, fields, formulas, workflows, reports, etc.). But it also supports programmatic customizations too, such as apex classes, triggers, controllers, and visualforce pages.
If you’re coming to the Force.com platform with background as a traditional programmer then you’re likely accustomed to geeking out some code on your local machine then committing to a source control repository, such as git or cvs, then deploying to a server. You maintain a backup of your code in the source code repository where you can version it and rollback to if necessary. (if not, get started today!)
But after working on the Force.com platform for a while you quickly realize, as a cloud service, anytime you make an apex code change or workflow tweak or create a formula field, that change has occurred instantaneously to that Salesforce org. There is no commit to source code repository and there isn’t any deployment from your local machine into Salesforce. It’s just there. And if you’re not careful, it’s also very easy for other developers to accidentally overwrite those customizations and no native way to rollback.
So how do we apply the software development best practices of source control, or at least a versioned backup of our customizations, to the Force.com environment? The answer is the Force.com Migration Tool!
There are plenty of resources online about how to setup continuous integration with Salesforce, but those assume you are doing work in one org and wanting changes synced to other orgs. That is a valid use case, but what I want to share with you is how to setup a very simple ant script to retrieve all the metadata from your Salesforce instance then commit the metadata to git source control so that you can begin scheduling routine backups of all your customizations.
This automation greatly frees up you and your team to work in the Force.com platform, make declarative and programmatic changes directly in your sandbox or production instance, and have peace of mind that behind the scenes all the metadata is being backed up to source control!
Getting Setup
- To use the Ant Migration Tool, you’ll need to have Java and Ant installed on the computer/server that will be performing the metadata backup and commit to source control
- Create a new git project in your source code repository then check it out to the machine you’ll be using to perform the metadata backup
- Download the ant-salesforce.jar from Salesforce. Go to Setup | Develop | Tools then click Force.com Migration Tool link. This will download a zip file; extract the ant-salesforce.jar to the project folder from step 2 (e.g. /yourProject/lib/ant-salesforce.jar)
- Next you’ll need 3 files which you can get from this gist: build.properties, build.xml, and package.xml. Save these directly in your project folder from step 2.
- Update build.properties with the system administrator credentials for the salesforce instance whose metadata you want to backup
- Review package.xml to ensure it lists all the metadata types you are interested in backing up. Note that Email Templates must be specified explicitily by name individually, this metadata type does not support the wildcard * operator.
- Open a command prompt in your project folder then type ant. Assuming ant is installed and ANT_HOME added to your path, this will invoke the build.xml script to login to salesforce and retrieve all the desired metadata from package.xml and put it in a new folder called src
- Now you can commit to source control. If you’re using git as in this example, you might issue these commands to add and commit the changes to local git repository then push it to remote:
git add . git commit -am "auto-sync metadata" git push -v -u https://<git_username>:<git_password>@<git_url>/<git_project_path>
- The last step is to automate! Schedule a script to issue the ant and git commands on a periodic basis. I do hourly snapshots, but you can do it more or less frequently.
References
- https://developer.salesforce.com/page/Force.com_Migration_Tool
- http://www.salesforce.com/us/developer/docs/daas/index.htm
- https://developer.salesforce.com/page/Continuous_Integration_Cruise_Control_and_Force_Com
- http://blog.jeffdouglas.com/2013/03/18/setting-up-continuous-integration-for-saleforce-development/
- https://www.youtube.com/watch?v=a0u1CBUsj_I
Thanks Doug. Your post definitley helped me in automating the backup. Can you tell me how did you schedule it?
LikeLiked by 1 person
Glad you found it helpful, Prajakta! I automated it at work using Atlassian Bamboo. It would run the commands hourly. But you can use any tool of your choice to execute the ant command shown in step 7. For example, you could create a ‘run.bat’ text file with the single command ‘ant’ then use Windows Task Scheduler to schedule that the ‘run.bat’ file should be launched every 5 minutes or every hour or daily. You might be interested in these materials on the developer site: https://developer.salesforce.com/page/Continuous_Integration_How-To
LikeLike
THanks Doug, this was very helpful
LikeLiked by 1 person
Glad to hear, thanks Hernán
LikeLike
Your blog helped me a lot in setting up a similar functionality in our Project.
It was a good read and was very informative.
LikeLiked by 1 person
Happy to help, thanks Aquib!
LikeLike
Hi Doug, new to salesfoce and recently was directed to this blog posting. We needed to back up metadata on a nightly basis for reports, dashboards and email templates. We implemented the tool but quickly realized that we could not get the reports metadata using the wildcard. We needed to list them out individually. I know the email templates, as stated above do not support wild card, are we doing something wrong with our implementation that is causing wildcard not to work for reporttypes and dashboards?
Thanks in advance Doug.
LikeLiked by 1 person
Hi John,
For reports, dashboards, and documents, you likely need to be retrieving them based on their folders and/or explicitly specify each one you want.
Check out this documentation on the Report metadata type as it has some package.xml examples.
LikeLike
Hi Doug,
Nice Post!
On Step 6 – Did you mean Package.xml??
Also could you please let me know how to prepare package.xml with all the latest org metadata??
LikeLiked by 1 person
Good eye, Kumar! Three years and I think you’re the first person to point out that typo. Thanks
Regarding creating a package.xml file, please see the Metadata API documentation. Some third-party tools like Force.com IDE, IlluminatedCloud, WelkinSuite, and Package Builder provide a UI to select the metadata components to put into your package.xml.
LikeLike
Hi ,
I am not using git.
is there a way to automate backup to the server without git ??
LikeLike