Hey, everyone, my name is Emily Rose and
I'm a Lead Developer Evangelist here at Salesforce.
Today I'm super excited to talk to you about Salesforce CLI,
how you can harness the power of Salesforce through the command line.
So let's set the stage a little bit and
talk about the developer experience with Salesforce DX.
As we all know, It all starts with these steps, plan, code, build,
test, and release, and then rinse and repeat.
It all centers on the version control system as the source of truth.
And we really want to focus on the CLI here.
So let's dig in and talk about Salesforce CLI itself.
What can you do with it?
Well, the answer is pretty much anything.
But usually you'll find yourself doing things like creating an org for
development or CI testing.
Or maybe you're synchronizing source to and from different orgs and file systems.
You can also import data for dev and test and
even use the CLI to automate a lot of your test suites.
But the key benefits here is that you have a single interface for
interacting with all of the Salesforce DX features and tool sets.
And you have that improved productivity as a result.
And of course, all of this integrates with UCS and CI and
all of your tool sets that you're already using.
So with that, let's jump right into a demo and actually start using the CLI,
see how it works.
All right, so here we are in the demo.
I'm in my command line terminal.
And to set the stage,
what we're going to do here is I'm going to pretend to be two different developers.
I'm going to start being a developer who's just getting the ball rolling with
the basic component.
And then after we've got that pushed up, and then pushed into source.
Also the CLI, by the way, I will then switch over and
become the second developer who's maybe working on adding another feature
that isn't related to what dev one is working on.
But the thing I wanted to really show here is, how you can work together through
the CLI, without having to step on each other's toes and that kinds of thing.
So the first step here is as developer one, I need to create a project, right?
So I'm going to say sfdx force:project:create and
I'm going to give it a name.
I guess we're just going to go with Dev1 since I'm the first dev on the project.
And what you see here, if we cd into this directory,
is it's done a little bit of scaffolding for us.
The big thing to note here, it's a pretty bare bones structure.
The files to note here are SFDX project, this lists, our package directories.
More on that later.
And also in config we're describing our scratch org.
So this is the scratch org definition.
And in our case, we're simply using developer edition or nothing fancy,
no extra features.
So we've done that, but
the force app itself is still decidedly lacking in any real content.
So the solution to that is to create a lightning component.
Then we can do that also right from the CLI.
So again, sfdx force:lightning:component:create.
And we're going to give it a name, we'll call this DemoComponent.
And we also need to tell it where this component's going to live, and we'll
just stick it right in the base directory, so force-app/main/default/aura.
Hit Enter, and now it's scaffolded, scaffolded all of the component files, right?
So here we have DemoComp.
We've got a barebones component with the XML, CSS, controller,
helper, renderer, all the good stuff.
But as you can see, the component has nothing in it.
So let's fix that.
I've got one of those lovely pre-baked components available for us to use.
And I'll throw it in here.
Here we go.
So we'll save that.
Now, before we go any further, there's a couple of things we need to do.
We need to take a look at what we have available for scratch orgs.
Cool, well we're set up for Dev1 and Dev2.
But we need to set the default here, so I'm going to say
sfdx force:config:set defaultusername=Dev1.
So now while I'm in the Dev1 directory,
I will always be referencing the Dev1 scratch org.
So let's see what changes I've made now that I've created a component locally.
I'm going to say, force:source:status.
And what this is going to do is show us that well,
in fact I've created several local files that aren't reflected on the org just yet.
So let's fix that, sfdx force:source:push.
>> Emily Rose: And as you may suspect,
this is actually pushing that bundle up into the org, but let's make sure.
Let's open the org.
This will launch in the browser.
And here we are.
So I've created a component, a very basic component.
Let's add it to an app.
Let's go to Lightning App Builder, and we create a new app.
And this can be just a standard app page.
We'll call it Demo App.
Header and right side bar is fine.
But what you'll notice here is I've got demo component, and
I can just drag it up there, and what do you know.
It worked.
We created a lightning component from source, right, great success.
So let's save that, we'll activate it.
So go ahead and add it to the sales page.
Cool, all done.
So we'll go back and just make sure, let's take a look.
Sales app, there it is, our demo app.
It doesn't do too much yet though, so there it is.
But as some of you may be wondering, well,
then we just make changes on the org as well?
We did, this is where we come to sfdx force:source:status once more.
And what we're going to see this time is that the remote has added files that we
don't have locally.
So let's fix that, sfdx force:source:pull.
And there we are.
We've just added all of those remote changes to our local file system.
Well, let's make a git directory or a git repository.
We'll git init, and let's head over to GitHub.
And we'll create a new repository.
We'll call it dx-test.
We'll grab that remote and we'll just say git remote add origin.
There it is.
Now, here we are, we've got everything.
Let's just git add everything.
>> Emily Rose: Send the initial commit and send it on its way.
And so just like that,
we have encapsulated all of the changes that we have done in our scratch org in source.
So any other developer can pull this down and use it to start from with any other
project that they would like to under take.
So, cool, we've done that.
I guess it's time for developer two.
So, here we are.
I'm going to make a directory for Dev2
and Cd into it.
I think the easiest way to do this is just to git clone the dx test.
This is what most developers would be doing if they were going to start
developing the project.
So we'll get in here, and let's say sfdx force:org:list.
Let's see where we're at as developer two.
Cool, so we still have the dev-hub defined, but for us,
we want to use Dev2 scratch org, so we're going to override that settings.
So sfdx force:config:set defaultusernameDev2,
and so now sfdx knows that when we're referring to an org in this context,
we're referring to the scratch org for Dev2.
So let's take a look, sfdx force:source:status.
Well as you can see, Dev2's scratch org has no changes.
So everything that we have done for Dev1 we've gotta do for Dev2 as well.
But we also mentioned that we want to work on additional projects with Dev2.
So for the sake of brevity here, let's say that Dev 2 has decided they're
going to add a yelp component to the accounts page for sales people.
So the easiest way to do that, we're just go git clone,
github.com/dcarroll/YelpDemo.
Cool, so now I have the Yelp demo.
Let's prune it just a little bit.
We don't need the package.xml.
We don't need it's own git directory.
But one thing that we need to do to make sure that
Salesforce DX knows where that package belongs and
where it's coming from, is we need to add it to our definition.
So right here, as I mentioned previously, we have our package directory and
what we're going to do is just add the Yelp demo right here.
But it's not the default, so we're going to say false, okay.
And now let's check what the source status is.
So sfdx force:source:status.
Cool, so now we have all the Yelp stuff to go up as well as
the stuff that Dev 1 did as well.
So sfdx force:source:push
Cool, all done.
So let's launch that one, sfdx force:org:open.
Here we are.
We see that we've added some custom objects.
Well, for this time, like I've said,
we're just going to add a nice Yelp component for the sales folks.
When they're looking at accounts,
maybe they want to be able to know what restaurants are nearby.
So what we can do is come up here, just going to edit the page.
And look, here's the Yelp demo component.
Let's just slide that over here, here right at the top.
Let's save that.
Activate it, assign it as the org default.
So we'll save, we'll go back, now let's take a look.
The page we were just at now has the In The Neighborhood component.
And let's say were looking for some good vegan food.
Okay, not bad, but just equal opportunity diner here.
Let's look for steaks.
Cool, there's a decent amount of steaks as well.
But again, as you may have suspected,
we've just made some changes remotely again.
Let's pull those back into source.
Here's the changes so far.
Let's say sfdx force:source:status.
Aha, so we've added that to the account record page,
we've added that FlexiPage.
So let's pull that down, sfdx force:source:pull.
Perfect, so with that, we've added Yelp.
All done, so let's look back over here.
We did indeed add our Yelp demo.
So you can come in here and see all of the components for the Yelp demo
as well as the existing default components as well that we made from developer one.
So that's that, and now you can see how you can collaborate more effectively,
bring everything into source and track it with your favorite VCS.
So with that said, the next step is to become a Salesforce DX Trailblazer, and
there's plenty of resources available for you.
I'd recommend taking a look at the badges we have on Trailhead.
If you're new to Git and GitHub, I would recommend taking the Git and
GitHub Basics badge first.
But each one of the badges covers slightly different aspects of Salesforce DX.
>> Emily Rose: And with that, thank you very much and happy coding.