Our last webinar in 2017 - “Experience Salesforce DX at its best with AutoRABIT” was very much exciting and engaging not only to the audience but to us too as our team had got a chance to address many queries around Salesforce DX and how AutoRABIT helps adopt Salesforce DX effectively. We handpicked some of those questions here to help enterprises / Salesforce developers embarking upon Salesforce DX.
- What is a Hub org?
Hub org is a placeholder for your scratch orgs. You can create and manage scratch orgs from the command line and Lightning Experience. It contains details of scratch org's expiry date, who created the scratch org, and the number of scratch orgs created, etc. Ideally, Production Org is your Hub Org.
- Log in to your production org (if you’re a customer), your business org (if you’re an ISV), or your trial org as the System Administrator.
- From Setup, enter Dev Hub in the Quick Find box and select Dev Hub. (If you don't see Dev Hub in the Setup menu, make sure you're in your production or business org, and your org is one of the supported editions.)
- To enable the Dev Hub, click Enable. (After you enable the Dev Hub, you can’t disable it. If you're using a trial org, Dev Hub is already enabled.)
- Read more about it here: https://goo.gl/oFzrQL
- Well, I have enough scratch orgs for development. Do I need developer sandboxes as well?
Scratch Orgs do not replace sandboxes. They are temporary, ephemeral instances that are terminated after a set number of days. These can be used for temporary development/ peer review/ automation testing etc.
- What if I want a scratch org for sprint?
Salesforce does not set any business limitations on how a scratch org can be used. However, it is not ideal to maintain your entire sprint in a scratch org as these instances are ephemeral and do not contain your Production data. So, as you adapt to scratch orgs, you should go for feature-driven development model.
- How does AutoRABIT add value to both the developers and release managers?
AutoRABIT is an end to end release management suite that adds value to all functions of a Salesforce development practice. Developers can quickly identify changes on a Salesforce org (scratch org/sandbox) and allows them to check-in the delta of a file to their version control repository. They can also tag their commit information to their project management (ALM) tool such as Jira, VersionOne, etc. Developers are also forced to run sanity tests before checking their code+configuration – This is highly effective for release managers and team leaders as they can see “Who” changed “What” and “Where” from a compliance perspective. Release Managers can use the change management to merge the code related to a specific user story from the respective feature branch using AutoRABIT. From a high-level understanding, in AutoRABIT, feature branches and scratch orgs are with the development team and what goes into the release line is with the release manager. AutoRABIT is a catalyst for adopting Salesforce DX.
- How do we manage the proliferation of such orgs?
You may delete a scratch org once a feature is moved to a release line. You will not have trouble managing the proliferation of scratch orgs as they are ephemeral.
- What is the difference between a scratch org and a developer Sandbox?
Scratch org is an empty container which does not have any metadata in it, but you can configure it using a definition to support a specific edition or a supported feature such as ServiceCloud, ServiceWave, etc. After the creation of the scratch org, required metadata must be moved into the scratch org to support a development story. On the other hand, Developer sandboxes are connected orgs and are refreshed from Production org to pull metadata into them. But developer sandboxes may not have all the features like scratch org which is Einstein- enabled by default.
- Most of the user stories are interdependent, and they cannot be tested individually. How to leverage scratch org efficiently in this scenario?
The answer is Packaging. Once a scratch org is created, it can be optimized to support a user story by deploying components based on a package. A package should contain components that logically form an application.
- What if we are looking for just CI / CD and want something on-premise and not cloud? How can AutoRABIT help?
AutoRABIT offers on-premise connectivity as well by providing VPN, VDC, tunnels support.
- Does AutoRABIT's Data Loader support migration of attachments, chatter feeds, etc.?
Yes, AutoRABIT's data loader supports migration of attachments and chatter fields. Check out the case study which describes how AutoRABIT ensured the split of a complex Salesforce Production Org instance with its unique algorithm for one of its Fortune 50 clients. AutoRABIT allows you to apply complex filter and transformation logic.
- Do I need to migrate my entire code base to Salesforce DX format if I need to use a scratch org?
You can start with existing source format.The reason is, it will take a while before DX process is synced. And, you also need to componentize your application into smaller application models. Until the time you can do that, you can continue to use the existing source structure. Ideally, it is recommended to componentize your app and then move towards scratch org source structure in the long run. Here is a webinar recording from Salesforce which talks about adopting Salesforce DX in a systematic fashion.