- Hi everyone.
I'm excited to be here today
to be demoing our new DevOps Center,
which is the central
application to be delivered
with our new DevOps solution.
This first version of the DevOps center
will provide an improved
UI-based experience around change
and release management,
that will not only deliver a modern
and robust experience for
declarative developers and admins,
but will also allow for collaboration
between declarative and
programmatic developers
throughout the DevOps process.
What you're looking at here
is the Work Items tab of DevOps center.
Here, you can see a list of work items,
which are like tickets that
define the requirements
of the changes to be made.
The work item is a central
object in the flow,
as it's what the actual
changes are tied to,
and tracked against, as they move
through the release process.
To start the development process,
we'll select the work item
that defines the change
that we'll be making.
In this case, it's the work item entitled:
Add Days on Market component
to Property Explorer page.
We now see that the work item status
is shown as In progress.
And we can start making our changes
by clicking on the Launch
Dev Environment button.
This will open up a developer sandbox
where we can do our development.
The sandbox is synchronized
with the source
from our connected
source control repository
to ensure that we're developing against
the latest source of truth.
We're developing against
a real estate application
called," Dreamhouse".
This is one of the sample designs
that we provide in our
sample design gallery.
Now, recall that
the change that was
defined in the work item
was to add a Days on the Market component
to the Property Explorer page.
So we'll open up the
Property Explorer page
in the application,
and then select Edit
Page from the Setup menu.
This will open up the
Lightning App Builder,
where we can see the Days on Market
lightning web component,
which we'll drag onto the lower
right section of the page.
Well then click Save and then back
to go back to the property Explorer page
to verify the change that we just made.
We can now see the Days
on Market component
on our Property Explorer page.
And when we select one
of the property cards,
we can see that the component
updates as we'd expect.
So at this point we're done making
and verifying our change.
And so we're ready to proceed
with moving the changes
along in the release process.
So to do this, we'll go
back to the DevOps Center
to continue with the change
and release management process.
Now that we're back in the DevOps Center
and still looking at our work item,
we can select Pull Changes
to pull the changes that we just made
and the developer sandbox.
This is super handy as we don't need
to manually keep track of the changes
as we're making them,
nor do we need to sift
through lists of components
to find the components
that we want to migrate.
Now, once our changes have all been pulled
and shown to us in this UI,
we still have the ability to decide
which of these files we really want
to migrate forward in the process.
In some cases, we may not
want to migrate all the files
that have changed.
For instance, we may choose
to not migrate profiles
or other components that maybe we changed
as we were trying things in the org,
but that didn't end up being
part of the final change.
In this case,
we do see that a profile
component was modified
and we're going to choose
to not migrate that as part
of this work item.
So all we need to do
is simply click Ignore
next to the component to remove it
from the list of changes
that we're tracking here.
So now that we've got our list of changes
that we want to move
forward in the process,
we can proceed with the next step,
which is to submit the changes.
Now, before we actually click Submit,
we'll add a description
and a comment describing
the change that we made to help document
and track the change.
And then we'll click the
Submit Changes button
to submit these changes to
the next stage of the flow.
We can now see that the work item reflects
that it's in the In
Review stage of the flow.
And we can see a history
of the change submissions
that we've made now for this work item.
So let's talk about what
actually just happened
when we submitted those changes.
Behind the scenes,
the tool committed and pushed
the metadata source files into a branch
and our connected GitHub repository,
and also created a pull request.
We haven't had to run any GitHub commands
or really even know anything about GitHub,
to be able to push these changes into
the source control system,
to facilitate synchronization
and collaboration with other team members
and backup our source files.
So this is pretty cool.
And so if we click on view in GitHub,
we can see the new branch
that's been created
for this work item and the
pull request in GitHub.
Now, at this point we're going
to shift into a programmatic
developer persona
who will review these changes
and deploy them to the downstream org.
We will eventually support
the full end to end flow
in the UI based DevOps Center.
But in this first iteration,
the process of deploying the changes
is done through a programmatic interface,
which we'll go through next.
Now we're logged into
GitHub as a different user
acting as another team member
who will review our change.
We can take a look at the
change file to review it,
then add a review comment,
and finally merge the changes from
this branch into the master branch.
Now we'll go to the CLI
where we've already cloned
the project's GitHub repository,
and we'll pull the source files out of
the master branch that
we just merged to into
the local directory here,
to prepare to deploy to
the production environment.
Once we have the source files
in our local project directory,
we can then deploy them to our production
or using the source deploy command.
So through this demo,
we've just shown how we can go through
the full process of
starting with a work item
in the DevOps Center,
making the change in a developer sandbox,
identifying and managing the change,
submitting the change to
GitHub via the DevOps Center,
then reviewing and merging the change,
and ultimately deploying the change
to our production environment.
And with that, I thank
you very much for watching
and I hope this gets you excited
for what we have coming in
the area of Salesforce DevOps.
