Developers are always source-driven people. Salesforce DX (developer experience) enables the developer to work with any externalized source – even incorporating version control. “What is Salesforce DX ? It is an open standard developer experience, letting you build with the tools you love including Git, Selenium, Eclipse, Sublime, and more. Salesforce DX includes an updated Eclipse integrated development environment (IDE) that significantly expands the value of the toolset to developers. However, the development process is source-driven.
Moreover DX not only allows them to collaborate with other members of team. Moreover, the environment for a developer never works in perpetuity – something that the developer can simply dispose of, on project completion. It is this combination of the environment and the source code that leads to faster development of mobile apps -something that is a yearned by a developer always. Finally, it is a packaging model that is used to aid in the distribution of changes – across environments.The below figure shows some of the core principles around which modern software delivery is centred around.
Let us now find out more on the advantages of Salesforce DX:
Advantages of Salesforce DX
The advantages of Salesforce DX are:
- Salesforce DX has a source-driven development process, This allows to test the features with agility and confidence.
- Salesforce DX helps developers build together in teams. In many ways, it brings together the best of the Force.com and Heroku developer experiences. It’s a new approach that supports team collaboration with a focus on quality, predictability, and an open and standardized development lifecycle on Salesforce. The advantage for this is that it enhances productivity and a faster development – thereby decreasing the time to market the product or service.
- A core theme of Salesforce DX is letting developers choose the tools they want. For example, we’re investing in making the Force.com IDE a best-in-class solution, but with Salesforce DX and our new command-line interface, you can use the text editor or IDE of your choice, along with the CLI, to develop your app. It’s up to you.
- When it is time to test your development work, then a Salesforce DX uses a scratch org and pushes the metadata. This scratch org, otherwise known as developer server.- serves only the purpose of testing and validation. There must be automated test runs for each of the change sets for your application. This is named as continuous integration(CI). This is for ensuring quality before any corrupt changes makes it way into the source repository.
Following are some of benefits of the scratch org:
- It is easy to integrate scratch org into a CI process. The scratch orgs are created by the CLI and this makes the life of the developer much easier as scripting them in CI flow becomes easier.
- These can be created throughout the day unlike the sandboxes.
- The scratch org is easily deleted whenever the need arises.
- It works with limited overheads.
- The scratch org can send reminders to Github and when it reaches expiration it will send an email to remind the user.
- Another example is build automation and how you run tests. With Salesforce DX, you could use our all-new Heroku CI, currently in private beta, combined with Heroku Pipelines enhancements to drive both continuous integration and continuous delivery. Or you could also choose to integrate a different build automation tool, such as Jenkins or TeamCity.
- The Salesforce DX has shifted from an application life cycle model to a packaged development model. In the packaged development model, the source of truth is the version control unlike the other models, where production.org is the source of truth. The Salesforce DX organization actually organizes the source into package directories, These directories ensure that the packages made through this – easily updated, maintained, versionable and installed.
- As soon as the developer becomes ready for continuous delivery automation and release testing then they start using a packaged version in each of the testing environments visit maidwhiz.com. This is preferred than use of change sets to move changes between environments. After testing is completed the same packaged version is installed in the production org.
- However, when we speak of continuous delivery then we speak about sandboxes. Here the packaged version is used and installed in the sandbox. In this use case, the steps to test are replicated for releasing it to the production org.
- Finally, the build and deploy process that is parallel operation to the above change set method is still supported by Salesforce. These use cases are still supported by the Metadata API mdapi:convert and mdapi:deploy commands.
- First the metadata source is retrieved from an org and then converted into the source format. At the time of creating the deployment artefact, once the app or the customized solution is developed then source data into the metadata format. This essentially makes the source ready for a deployment in a scratch org. It is the deployment process that takes care of the changed files. So, whether it is release testing or continuous delivery, the DX process iterates with the conversion of source data into the metadata format.
The Dos and Don’ts in Salesforce DX
- Never to export entire org in a project instead think of modularization of code.
- Put shared schema and be careful
- Watch out for shared objects
- Atleast running with a CI for commit
- Must not export live data from production org. No need to make copies of production data into scratch org. t is good to create good sample data
- Make sure the work for all developers must be integrated.
Salesforce DX is an open-standard developer experience that enables them to work with their favourite tools like Github, Selenium, Eclipse etc. There are certain core principles around which DX is built. It is source-driven and offers a collaborative environment for the developers. The source of truth for DX is the version as it has moved to a packaged development.
It has a combination of source code and environment that ensures a faster development of mobile apps. Salesforce DX has a command line interface (CLI). The developer can make an app with a text editor or IDE along with CLI.
When the time to test this app arrives, then DX uses a scratch org for pushing metadata. There must be automated test runs for each of the change sets for your application. This is continuous integration(CI). This is for ensuring quality before any corrupt changes makes it way into your source repository.