Use Metadata API or Package.xml with Salesforce DX
If you have existing VCS which stores metadata information about your Salesforce instance in old format, dependent on package.xml and you want to use Salesforce DXthen this blog post is for you. As you might already know, Salesforce DX does not need package.xml and can automatically detect changes in your Salesforce instance, therefore new Salesforce DX project format is different. In this blog post we will see, how Salesforce DX can be used without enabling Developer Hub and using Salesforce DX with normal Salesforce instances.
There are two solution to this problem
Keep using old Project format and use Metadata API to retrieve and deploy
Convert old project format to Salesforce DX project Format
Sample of Package.xml to deploy Custom Metadata Types
Most of you must already know that there is new way to control your program behavior in Salesforce with the help of Custom Metadata Types. Previously we were using List Custom Settings to create functionalities like managing Trigger’s On/Off behavior or controlling Integration endpoint URLs. However we were not able to use Migration tools to import export records into custom settings.
So, into the new world of Custom Metadata Types, I used change sets mostly to perform deployments. Recently, I needed to use ANT migration toolkit to retrieve and deploy Custom Metadata Types. I was able to do it however If you ask me, I spent more time then expected.
Received errors like :
package.xml - Entity type: 'CustomMetadata' is unknown
Just to make sure not to repeat same mistake and save time in future, lets discuss how we can import / export or rather I will say retrieve and deploy Custom Metadata Types in Salesforce using ANT Migration toolkit.
While implementing real Continuous integration in Salesforce, we need to perform various adjustments in metadata before deploying it to build server or production instance, many automated scripts (automation) are needed. If you need to change ANT scripts or metadata frequently, then it means continuous integration or deployment process in your Salesforce project is not yet fully matured.
There could be multiple situation where we don’t want some component to be deployed on production and example of one of them is List view.
Going through multiple comments, I decided to create this 5 minute video tutorial to demonstrate, how we can use DestructiveChanges.xml in Ant migration tool to delete components.
As known already, we cannot simply delete components from Salesforce production using changeset. Apex classes, triggers etc cannot be deleted manually as well.
subscribe to Youtube channel, to get notifications about new Salesforce videos.
As your Salesforce Organization undergoes heavy customization and frequent builds, moving changes from one Sandbox to other sandboxes starts taking longer time and effort. Also, in normal Salesforce project, there are chances that you will have minimum three sandboxes likely Developer Sandbox, QA Sandbox and UAT Sandbox. After some time you will be in need of some solution which can reduce your effort.
This time its Salesforce using Jenkins. In this article I will walk through solution of above problem using Jenkins. Don’t forget to watch Video at end of this article, where I provided demo of everything explained in this article.
If we want to use Ant Migration tool to fetch Salesforce Organization metadata info or to deploy some changes to Salesforce, we need to create “package.xml” manually or take help of eclipse. wildcard character (*) doesnt work with some components like report, emailtemplate, dashboard and document. Package.xml must needs to have folder name and files inside folder name. After getting package.xml from eclipse, what if some folder is added into Organization ? We need to update “package.xml” again with help of eclipse or do it manually. Therefore I wanted to automate generation of package.xml completely and came up with this article and below workaround.
I would be using Ant to generate “package.xml” with below steps
During project development life cycle it is very essential to backup your code and Configurations daily. However sometimes developers forgot to commit changes in Git, may be because of workload. It may create an issue if someone wants to check back history of code for that duration, there will be no use of having code repository in place if it cant help us to get out of problem.
In this article, I will move one step further and explain how to setup automated script which will run on your System startup and commit backup of your Salesforce organization into local Git repository without any manual interference.
Salesforce Automated Script for Data Backup Using CommandLine
Step 2:
Set Environment variable “ANT_HOME“. The path should be of parent folder of “bin”. Also add the “bin” folder to your path.
Step 3:
Check whether ANT is installed or not properly by running command “ant -version“. It might be possible that you receive message something like unable to find tools.jar. You can copy this jar from “JDK_HOME/lib/tools.jar” to “JRE/lib” folder.
