Hello, my name is Josh Kaplan.
I'm a product manager on the Salesforce platform team, working on Salesforce DX.
Salesforce DX provides you with a brand new set of tools to integrate with your
existing tools and your existing processes for developing applications.
One of the processes that I hope you're familiar with, continuous integration and
continuous delivery.
Continuous integration is the automated running of tests every time
any developer checks in a change to your application.
This will ensure that you have code quality across everyone in your team and
across the history of your project.
Salesforce DX provides a command line interface which will let you script
the test runs you need to ensure that application quality.
We'll let you integrate with the existing toolset that you already have on site or
have skills with across your organization.
CLI makes it easy to script those runs.
In an attempt to always remain open, so
you can work with development tools you want, Salesforce CLI also allows you to
integrate with a variety of different IDE environments.
We have provided a brand new Eclipse plugin
that is built specifically to work with Salesforce DX.
It attaches to your scratch orgs and
lets you do development in the way that Salesforce DX recommends.
In addition to that, there are a series of community supported tools, like IntelliJ,
Cloud9, and Sublime that you can utilize, if those are your preferred IDE of choice.
And with that, I would like to now demonstrate
how Salesforce DX makes it easy for you to work with continuous integration.
I'm now going to show you how I've integrated my project with
a well known continuous integration vendor, Travis CI.
Now doing this does not require you be an expert in Travis CI,
which is good because I am certainly no expert in Travis CI.
I was able to still set this entire demonstration up with the help of our
Trailhead modules in very little time whatsoever.
So you can see here I'm in GitHub, this is my repository.
This is my application.
I've got all of the different files I need to set up scratch orgs and
to run my continuous integration system.
So let's go ahead and make a change and
see how the automation will kick in to test my application.
Here I am in the new Force.com IDE,
which is built to work with Salesforce DX.
You see here at the top the name of the scratch org that I am currently
pointing at.
And you see here at the top,
the name of the git branch that I am currently checked out on.
I will now make a new branch to make a new change,
which I will commit and allow the test to run automatically.
So I do a new branch, we call this bigtest.
So on the bigtest branch, I'm now going to be able to make some changes to my code.
Let's add one more test right here.
After checking test, we're going to do a checking again test,
just before the just checking test.
I will now save that.
And I will push that to my Scratch org, I've got lots of ways to do that,
this button here at the top.
Or I've got buttons that right-click on the files themselves, or
I could go back to my command line if I want to.
As soon as the source is pushed down here in the corner, I'm going to go ahead and
run my Apex tests.
So I've set up a test configuration up here that runs all
the tests that I want.
I click on and run and we'll see down here on the Apex test panel
that the tests are kicking off and running.
So you can see here that the tests have completed and my just checking again test
has now also been added to the list of tests that were being run.
I'll now use my integration with Git that's built directly
into the IDE.
And I will stage the changes to my redundancy test for commit.
Commit message, added a test, because more tests is always better.
I'll do a commit and push, follow through the screens here.
And it will now push my changes on this branch up to Git.
Switching back over to my repository,
I see that the bigtest branch was pushed less than a minute ago.
And I can now compare the changes and do a pull request.
I'm going to compare with my master branch, see that I can merge.
And as soon as I create a pull request, automated tests are going to kick-off
through the magic of continuous integration.
I can see right here that Travis,
my continuous integration tool of choice, is running.
And if I were to open this tab, you would see that the build is booting and
kicking off.
While that's happening,
let's take a look at the file that is being used to power that integration test.
I open up my travis.yml file and
I see that here I have a bunch of commands that are used to tell the Travis
server what to do both with Travis commands and with sfdx commands.
So at the top I encrypt my key and
then I install a whole bunch of different plugins I need to, sfdx updates.
And now down here after I've done some of that setup,
I get into the meat of the test script itself with the sfdx commands.
The first command here you see is force auth jwt grant,
which does an authentication for
my headless process into the connected app that's in my hub org.
The next thing that I do in my script is I do an org create,
same command I would run at the command line using my Scratch definition.
And I call it ciorg.
Then I push the source from my repository into that org.
I run tests.
And then I'm going to be a good citizen.
I'm going to clean up by deleting that ciorg when the tests are done.
Now you may notice this is the same set of steps that I went through when I
was in the IDE.
I already created the org in advance, and I already authenticated.
But I pushed the source, the changes that I made, and I ran some tests and
saw the results in the IDE.
Now the automated continuous integration process will mirror those same steps but
do it in the most recent version of the code
with all the changes by everybody on my team.
And this will ensure that whatever changes I've made
do not conflict with everybody else on my team.
So now I can pop over here into Travis and
see what has happened in the running of the script.
It shows me all the output of the creation of the environments that it's using,
setting up the Scratch org.
Pushing the source, you see the same output you would see at the command line,
all the files being pushed into the Scratch org.
And then you see the Apex test run being executed and
all of the different test results here are all going to show up with a pass.
And when they do all show up with a pass,
we will at the end find an exit code of 0, which will be a successful test run.
Now looking back at my build screen, we'll see this test is passed.
I can come back into my repository, refresh the screen and
see that all checks have passed.
I'm now ready to merge the changes that I have made to my local personal developer
version of the application, merge those in with rest of the team.
And I now know that I can safely do this because of the automation setup
with continuous integration.
You, too, can become on expert on how to use Travis and
continuous integration by going to the wonderful modules we have on Trailhead.
In fact, most of what I've shown you now is coming directly from the continuous
integration using Salesforce DX Module, which I encourage you all to go visit and
try out today.
The rest of these modules will get you up to speed on how to
use all of the wonderful features that we've put into Salesforce DX.
>> Josh Kaplan: Thank you very much and happy coding.