Salesforce DX is the new development environment that will eventually replace the Salesforce EDI that’s based on Eclipse. Recently, Salesforce announced that they won’t release any new feature for the Salesforce EDI any longer. While they will still support it until October 12th, 2019 all new features will be released for Salesforce DX.
On Oct. 12th, 2019 we will no longer provide support or updates of any kind to the Force.com IDE.
Salesforce DX takes advantage of the very popular open source editor Visual Studio Code and has published all its add-on exclusively for that platform (as of right now). Therefore, if you want to develop there are a couple of add-ons that are required to use Visual Studio Code for Salesforce Development. They offer APEX syntax support and various API integration to manage your projects.
Additionally, Salesforce wants to make sure that you integrate your development efforts with Git, specifically GitHub. That allows you to keep track of any changes in your code and traceback code snippets to a specific point of time and developer. If you are familiar with GitHub, you are most likely familiar with the concept of branches and pull-requests that allow you to develop various features simultaneously without affecting the main (master branch) code. From there, you can deploy those versions on separate instances and test those accordingly.
Salesforce allows a very similar behavior by allowing developers to leverage Scratch Orgs. You are already familiar with Sandboxes, which are used for development and testing purposes. A Scratch Org is basically a developer environment that allows developers to easily push and pull the code that lies in separates branches. Therefore, it can be developed independently before releasing for testing. Additionally, the newly released Salesforce CLI allows you to manage those scratch orgs and log in from the terminal. That makes managing your credentials 10x easier. Once it’s set up, you are able to push and pull code as well as a login at any point of time without remembering your login for that specific org.
We truly believe that Salesforce DX is a brilliant move in the right direction for Salesforce and demonstrates the wisdom of Salesforce’s direction.
Before you can start with Salesforce DX, you to enable the Development Hub for the organization you are working in. That’s amiable under the regular Setup and can easily be enabled with a click of a button.
npm install sfdx-cli --global
Now that you have installed the Salesforce CLI you can take advantage of the following commands:
Additionally, you can look up the official documentation as well right here or run:
At any given time, you can easily add
— help to get some guidance in regards to what options are available. Especially, in the beginning, you will find this particularly useful because there are so many CLI commands.
From here, you create a new folder that will store & manage all your source code.
To get started, you have to maintain your Salesforce connections. I started with my production environment to get the initial status quo and all dependencies that are required to do actual development through Salesforce DX going forward.
sfdx force:auth:web:login --setalias my-hub-org --instanceurl url
Having the correct origination connected to your CLI brings you to the next step before you can start your development.
In the Setup, create a new package and include all dependencies and custom fields that are required for a copy of your current organizations. This is required when you want to create your Scratch Org later since Scratch Orgs do not include all the customizations you have done your system. That is also the first major difference to a regular sandbox that normally includes all customization you have applied to your Salesforce environment.
Since no customizations are included, please make sure to include all managed packages from the App Exchange in your dependencies as well. Otherwise, you will run into errors since those are not included automatically.
Once you have created your package, release it, download the full content and unzip it. This will allow you to convert it into a Salesforce DX project.
sfdx force:mdapi:retrieve -s -r ./mdapipkg -u [your_username] -p
unzip ./mdapipkg/unpackaged.zip -d ./mdapipkg/
Now that you have bundled up, all of your customizations and exported it, just run the following command in the Salesforce CLI and it will be converted into a Salesforce DX compatible project that you can use for further development.
sfdx force:mdapi:convert -r ./mdapipkg
Let’s catch up. We installed the Salesforce CLI, connected to your preferred Salesforce organization, bundled up all customizations, defined dependencies and converted them all into Salesforce DX compatible project.
Pretty cool — so far it seems pretty extensive to work with Salesforce DX but I promise that once you have completed this setup, it will get a lot easier and you will appreciate the ease of Salesforce DX (Once again, if you are coming from a JavasScript development world i.e. this will still look crazy to you :))
Set up a new scratch org and upload your complete project. This will pretty much create a Developer Sandbox. Now you can easily, modify existing code and add new functionalities. Additionally, everything from here on works with the typical git push/pull structure.
sfdx force:org:create -f project-scratch-def.json -a [ScratchOrgName]
To push your Salesforce DX package into the newly created Scratch Org you can use the regular push command:
sfdx force:source:push -u [ScratchOrgName]
I got stuck, wondering why my latest changes didn’t make it into the scratch org for at least 30 minutes.
Let’s say you run into an error that you are using a custom field that doesn’t exist yet but you just skipped over the error message. Unless you modify the file and push it again it won’t show you the error message again. Having said that, it’s very important to read ALL error messages if there are any while you are pushing up your changes. A lot of times, I had the toughest time finding out what was going on and why my modified files weren’t pushed up into the org.
Reason for that was an error that was just getting ignored when trying to push again without modifying the actual file. I think that’s a flaw in the current version and will hopefully be something that they will improve going forward.