Hi, my name is Rohit Mehta.
I'm a product manager on the platform team at Salesforce.
And today, we'll be talking about environments at Salesforce and
focusing a little bit on Scratch Orgs.
Scratch orgs are a new type of environment that were introduced with Salesforce DX.
They are a source-driven and
disposable deployment of Salesforce code and metadata.
Scratch Orgs is fully customizable allowing developers to emulate different
editions with different features and preferences.
Playing a critical role in developer productivity and
collaboration during the development process.
They can also be used as part of automation testing and
the implementation of a full continuous integration suite.
And now that we have an overview of Scratch Orgs,
let's jump into a demo to see how we can use Scratch Orgs.
So to get started,
I'm going to show you my setup on the command line interface.
I have a few things set up already in my command line interface.
I have the Salesforce DX plugin installed, and
I've also authorized into my production org which has the dev hub enabled.
The dev hub is the piece of functionality which lets me create Scratch Orgs.
To navigate some of the commonly available operations within the Salesforce DX
plug-in.
I'm going to type in the Salesforce sfdx command,
followed by the force topic, followed by the help parameter.
This lists out all the different operations aggregated in one place.
The one that's of interest to us is the force:org command which will show
us all the different commands and that we can use to interact with scratch orgs.
Very often, I forget all the different options that are available as part of
the force:org command.
A very simple tip to get you going is to type in the help parameter.
This lists out all the different operations that you can possibly
do with the org subtopic.
Such as creating a scratch org, deleting a scratch org, displaying the details of
a scratch org, listing out all the different orgs that you have authorized
from the command line interface, as well as opening up individual scratch org.
Like I mentioned earlier, scratch orgs are extremely customizable, in that
a developer can select any edition, feature, and preference of his choice.
These configurations are stored in JSON format on the file system.
Which makes it super easy to version not only all your metadata and
your source, but also the configuration used for creating a scratch org.
This configuration can be shared across your development team,
to get a consistent scratch org created for every single developer.
Locally, I have this configuration stored in my config folder.
The configuration looks something like this.
It has a few different fields setup,
such as the country, the edition, which has been specified as developer.
In my feature section I have multimurrency and Apex enabled.
And in my preferences, I have lightning/chatter enabled.
You can see that I can also disable certain preferences which is super
powerful if you don't want certain preferences,
certain features that are enable by default within your Salesforce org.
While creating a scratch org,
this configuration file is passing the parameter to this sfdx forced:org command.
One useful tool type here is to alias scratch orgs,
which makes it super easy to reference these scratch orgs at later point when
performing other operations such as deleting or displaying more information.
For our demo, I'm going to call this a demo scratch org.
What you'll notice is after showing this command, in just a few minutes,
the scratch org will be created and will be ready for consumption.
When the scratch org is created, it is completely empty.
It does not contain any metadata or data from your production org.
It is up to the developer to push source into the scratch org
via some of the CLI command center available.
You'll also notice that I didn't specify a username and
password while creating the scratch org.
This is in fact a feature which allows someone to
create these scratch orgs rapidly without having to worry about the credentials.
Scratch orgs are, after all, supposed to be disposable.
How many log ins are you going to be able to remember
if you were to create hundreds of these scratch orgs in a week?
Once you've created a scratch org,
these should appear in the output of your org list command.
As you notice here, we have the production org listed here along with
the scratch org that I just created.
Now that I have all my scratch orgs listed out in this command,
I'm going to try to log into one of my scratch orgs that I created.
By issuing the sfdx force:org:open command,
and providing an alias that I previously gave to my scratch org.
I can very quickly and easily pull up a browser and log in to the scratch org.
It's a quick and easy way to look at all the changes that you made
at your file system and that you push to your scratch org.
You can also make these changes in your scratch org declaratively and
pull those changes down to your file system.
Deleting a scratch org is just as easy as creating one.
Deleting involves issuing the force:org:delete command
followed by the alias of the scratch org.
A prompt is put up asking you for confirmation of your delete.
And just like that, a scratch org can be deleted.
So that was a quick demo on how to use scratch orgs.
Now, let's talk about some of the environments that are available
within Salesforce.
After all, the environments are the glue of application lifecycle management at
Salesforce.
In addition to your production org, you have two other types of orgs.
One of which we already spoke about.
We have Scratch Orgs, but we also have Sandbox orgs.
Both Scratch orgs and Sandbox orgs are used for development and
testing on the platform.
There are four types of Sandbox orgs as you know.
Developer, Developer Pro, Partial and Full
and all of these different Sandboxes provide different functionality.
One commonly asked question is, how are scratch orgs different from sandbox orgs?
Scratch orgs like I mentioned earlier are fully configurable in that you can specify
different parameters that go into creating the shape of a scratch org.
Sandboxes are not the same in that they cannot be configured.
They are replicas or near replicas of your production org.
Scratch Orgs are also ephemeral in nature, they are meant to be short lasting.
Today, in beta they have a seven day expiration.
Sandboxes on the other hand, they do not expire.
They can be deleted and they can be refreshed after a refresh interval.
The different refreshened roles for the different sandboxes is one day for
the Developer
And the Developer Pro sandboxes and 5 days and 29 days for
the sandboxes which contain some amount of data.
Which brings me to data, what do each of these different orgs contain?
Scratch Orgs are empty.
The metadata that you populate into a Scratch Org is sourced from a version
controlled system.
On the other hand, Developer and Developer Pro sandboxes
have metadata that have been populated from your production org.
Partial Copy and Full Copy sandboxes are similar to Dev and
Dev Pro, in that they pull in the metadata from your production org.
But they also contain sample of your data and all your data respectively.
There are also different data limits which decide the amount of data that you can
populate in these orgs.
Scratch orgs, and Developer sandboxes have a data limit of 200 megabytes.
Developer Pro sandboxes have a data limit of one gigabyte.
Partial have five, and Full sandboxes have same data limits as a production org.
So the fundamental question is which environment to use when?
Scratch Orgs, Developer and
Developer Pro sandboxes directly used in development and testing.
Scratch Orgs are great for building code, rapid prototyping and testing.
Developer and Developer Pro have an overlapping functionality in that they
can also be used in development and testing.
However, scratch orgs, are ephemeral in nature and so
any amount of load testing is not possible in the scratchorg.
Sandboxes fit this use case.
Sandboxes do not expire.
They also have headroom for loading data into these orgs.
Developer sandboxes can be used for loading a small amount of data and for
unit testing.
Developer pro sandboxes can be used for loading more data and for
running a full suite of functional tests.
Partial sandboxes have data from a production org, and
they are great means to test against largest suite of tests.
They can also be used for training and for user acceptance testing.
Full sandboxes contain all the data from your production org
and they can be used for staging as well as load testing and performance testing.
So this was a whirlwind tour of the different environments at Salesforce.
You can also learn more with the different Trailhead modules that we have at
trailhead.com.
>> Rohit Mehta: Thanks for joining me, and I hope you found this informative.