>> Hello and welcome
to this video in which
I will introduce the concept
of source code management,
and how you can use it for
development projects from
Microsoft Dynamics
365 Business Central,
using Visual Studio Code
and get to repositories.
My name is Daniel Rimmelzwaan and
I'm a partner with
Cloud Ready Software,
one of the ISV
development centers.
We can help you with
just about anything related to
Microsoft Dynamics
365 Business Central.
Here are the objectives
for this video.
First I will introduce
the concept of
source code management
in Visual Studio code.
To make this work,
you have to install
Git itself first
and prepare your Visual Studio
Code environment.
Next, I will explain how you can
initialize and use
Git repositories.
In this section I
will show you how to
create a repo in
GitHub as well as in
Visual Studio
Team Services also known
as VSTS or Visual Studio online.
In the last section, I will
talk about how you
can use Git for
your VSCode development
project for Business Central.
You can get quite fancy
and sophisticated,
but I will keep things relatively
simple for this video.
Let's get started.
In the overview section,
I'll start by introducing
the concept of
source code management and how
that integrates in
Visual Studio code.
Source code management is
an integrated feature
of Visual Studio Code.
There are many
different protocols
that are used for source control
and one of the most popular ones
is a protocol called Git.
Git was selected as
the preferred source
control protocol and
VSCode was designed to have
native support for it.
This means that VSCode
integrates with Git
out of the box.
You first have to
install it though
which I will talk about
in a few minutes.
Other SCM providers are
available for many
additional technologies.
The difference with Git is that
to support those other protocols,
you will need to install
the appropriate VSCode extension
to be able to use them.
Some of the most
common ones are VSTS,
Mercurial, SVN, and Perforce.
I will show you how you
can find them in VSCode.
Since multiple extensions
can be installed and
activated at
the same time in VSCode,
multiple SCM providers could
be active at the same time.
One provider can handle
source code changes.
Another provider can handle
documentation on
the same project.
Each provider has
separate filters for including
files and therefore allows
finer control of what
is being managed.
In Business Central
project for instance,
you could put
different providers to
use for a different
project areas.
You could handle report layout
separately from AI development.
You could handle upgrade code
separately from
business logic development.
You could even
handle profiles and
personalization separately
from UI development.
All these different types
of things could be
tracked using different source
control providers.
For this video though
we will keep it
simple and we'll
stick to just Git.
I will show you how to create
a new repository in GitHub and
also in Visual Studio Team
Services also known as VSTS.
I will also show you how you
can link code changes to
work items in VSTS which
is a very useful feature.
The Git protocol operates on
a local file system level.
From VSCode, Git commands
are forwarded to
the OS and actually handled
by the protocol itself.
The commands are
issued from VSCode
but they are executed
on a local file level.
In order for VSCode to
be able to do this,
you must first
install Git itself on
the same machine that
you're running VSCode.
This is an essential first step
to make Git for work.
In this next section,
I'll show you how to
install Git and how to
set it up for use in
Visual Studio Code.
As I've mentioned before Git is
a source control protocol
and there are a number
of ways to install it.
The recommended way to
do this is to download
the program from Git-scm.com.
Every time that you start VSCode,
it will check whether Git is
installed and if it can't
find it it will show
you a message about it.
This warning message then has
a button that takes you
straight to the download page.
Installation process
itself is extremely easy,
just accept all the default
installation settings
and you'll be set.
After the protocol has been
installed you need to set
some global settings to identify
yourself to the system.
Those settings will be used
when working with
your repositories.
Let's go to the
development environment
and let me show you
how to do all that.
We are back in the Azure VM.
Where I have Visual Studio Code
installed where I have
my NAV server container.
So, when I open
Visual Studio Code,
you will see that it's
going to check for
Git and when it doesn't find it,
I'll get a warning message.
So, here it says Git
not found install it or
configure it using
the git.path setting.
I can do this all
manually but the easiest
thing to do is to
just click this
Download Git button
and it'll take you straight
to the download page.
We'll do that in a minute
but I just want to show you
first that Git really
is not installed.
So, when I go into
the command palette and
I type in a Git command.
For instance, Git clone
as soon as I issue it,
the system will tell me command
Git up clone is not found.
The reason for that is that
the underlying protocol has
not been installed yet.
One other thing I want to show
you is that you can go into
the extensions and when
you search for a category,
SCM providers, you
will see a number of
different providers that you can
install for Visual Studio Code.
So, here you can see
Perforce, there's SVN,
there's Visual Studio
Team Services which we
will install in a little while.
But I just wanted to show you
that this is where you can
find other SCM providers
from the marketplace.
So, let's now click
on Download Git.
When you click on that,
it will go straight to
git-scm.com and there's the link
to download for Windows.
Then from here you
just run it straight.
Download it, security scan and
then it opens the setup wizard.
Soon as this starts you can close
the website we don't
need that anymore.
Now we just click next nine
times one, two, three, four,
five, six, seven, eight,
nine and then you hit install.
And that will install
the protocol.
That's how easy it is,
that's how quickly it goes.
Let me just pause the video for a
second to compress
the time a little bit.
When the Wizard is complete
you'll get the finish screen,
uncheck view release notes,
we're not interested in those.
Click "finish" and
all you need to
do is restart Visual Studio Code.
You'll see that it'll check
for Git and it will find it.
In the output window you'll
see that it's using it.
So now, when I go into
the command palette,
now you should Git dot clone.
It'll ask for a repository URL.
So, since the protocol has
been loaded right now,
you can use it and
use the Git commands from
the command palette.
We just mentioned
some Git terminology
that's important to know.
When you hear a developer
talk about a repo,
what they mean is a repository.
Now repository means it's
a project folder that contains
all the files that belong to
an individual project and so Git,
just like VSCode,
looks at a folder as
a repository and so
the same folder can be
a workspace for Visual Studio
Code and at the same time,
it can also be a repository
for source control.
So two systems look at
the same folder from
different angles.
The second term is a remote and
a remote is a version
of the project that is
hosted on a remote server that
can then be synced with
a local repository.
What it does is it creates
a copy of the remote on
your local drive and so you have
a local repository and
a remote repository.
The clone is the name
for the local copy
of a remote repository that
allows you to work offline.
So, when you're doing your work
in a decentralized manner,
which means that you have
your own environment
as a developer,
you are working on
a local copy of
the remote repository and
the word for that is clone.
Push and pull are
sending and retrieving
committed changes from
a local repository
to remote or vice versa.
So you push a,
commit a change from
local to remote and you
pull a change from remote
back to the local repository.
Fetch is the same as pull
without merging the change.
This can then be
done manually later.
Then another important concept
which we won't talk
a lot about in
this video is branching.
A branch use a version of
a repository that is
different than master,
which allows you to
work without disrupting
the "live" for version
or the master version.
So, you can imagine you have
a master version
of the repository.
You want to work on
a certain feature without
being disrupted by the work
of other developers.
You can then create
your own branch,
do your work on your own branch
at the same time that
other people are
working in other branches
and when each developer is done,
those changes are
then merged from
the branch into
the master branch and
so that process of
applying the changes
done in one branch
into another branch,
that's called merging
and so most commonly,
changes are merged from
a developer branch or
a feature branch or
a release branch or
however you want to set
up your development
project in branches,
however you want to define that.
But at some point, the work
inside of a branch
will have to be
merged into the master branch
and that process
is called merging.
Before I move on to
the next section,
I want to show you
a very interesting post on the
NAV team development blog.
The NAV team has
written a blog about how
they use branching and
essentially this is an
illustration of how you can use
source control to manage
different types of
development tracks.
So this is an article that
was written back
in May this year,
and this was to explain how
the developer preview branch and
the NAV 2018 branch
and then after that
the Business Central
branch relate
to each other in relation
to the main branch.
So if you can see here,
this is about the AL development,
and so here you
can see a picture,
where you have the main branch in
the middle and then
on the bottom here,
you see another branch that
follows the GitHub issues.
In that branch, GitHub issues
are developed and fixed
and then those changes are
pushed into the main branch and
from the main branch then
the September update
was released.
Some new fixes were made.
Then the October update
was released,
some new fixes and
then Novembere etc.,
and at some point,
they introduced Dynamics
NAV 2018 which from
the main branch was released
into a different branch and from
that branch NAV 2018
was released and after
a month CU1 was released
and after month CU2 was released.
So you can see that
the branch from which
NAV 2018 was developed
is a different branch
from the main branch,
but they both have
the same code base.
So, it's like
a simultaneous track
that goes on at
the same time where
certain issues are fixed and
put into the main branch and
not all of them are put into
the product early spring.
So from the product
release branch,
at some point, Business
Central was released.
So, all these fixes go
into the main branch,
at some point, that gets
released into Business Central.
So, Business Central still has
the same code base as NAV 2018.
At some point, you get
another major release.
Certain things are moved
from the main branch
into the product branching
in case of hot fixes.
Anyway, I just wanted to show
you as an illustration of
different branches being
part of the same product,
the same development code base,
where you have the same product,
you have the same features,
the same functionality,
the same objects.
They're just in a different stage
chronologically in relation
to the main branch.
This is just one example
of how you can do it.
You can of course do it
your own way entirely and
make up what works for you.
So, that was that part.
Let's go on to the next section,
which is called
Managing Repositories.
As described, repositories are
folders and folders are objects.
Those objects are represented by
files and just like
the difference between
Visual Studio Code,
where it looks at it
from a workspace point
of view from which
the app file is created and
deployed to the service tier,
source control looks at
a folder from
the point of view of
tracking the changes
in those files
and keeping different versions
in the repository.
There are two ways to
initialize a local repository.
So, a folder, a project folder,
a workspace is first has to
be recognized by source
control that it is
a repository in the first place
and in order to do that you
have to initialize that
workspace as a repositories.
So there are two ways to
initialize a local
repository for Git.
The difficult way is to take
an existing folder and then
apply the Git commands to
that folder initialize
it as a Git repository,
and then that would create
the local folder as a repository,
which you then have
to push to a remote,
and the easy way is to clone
an existing Git repository from
a remote because, usually,
the repository management
system like GitHub or
BitBucket or Visual Studio
team services have
very easy ways to create
a new empty repository.
Often they have little things
like creating a Git Ignore file,
putting some template
files in there
that sort of thing and
then when that is done,
it will provide you
a link to clone
that remote repository down
to your local file system.
So, that's the easy way to do it.
Open Visual Studio Code,
you access the command palettes
and you enter "Git: Clone".
I've already shown
you that command,
then it asks for a URL for
the Git remote then you point to
a local parent folder
and then it will
download the cloned repository
from the remote into
your local folder,
and it will create
a project folder inside of
that parent folder that
you've pointed at.
Then Visual Studio
Code will ask you,
"Do you want to open
the repository?"
You click the button and from
that point on, you're in.
The less easy way, we say
less easy because once
you know how to do it,
it's really simple is you
initialize local repository and
then you push it to a remote.
First, you open
Visual Studio Code
then you create a logo workspace.
You access the command
pallets and you run
"Git: Initialize Repository" and
then the terminal
window you would set
the origin to a Git
remote and then you
hit synchronize and that
pushes that into the remote.
Both methods are easy to run.
Personally, I like the Git Clone
but that's because I'm lazy.
So, how do you choose?
Clone is when you have
an existing repository.
So, the remote already exist.
This happens when you join
a development project
that's already
underway or when you join
one of our workshops.
We have some repositories that we
pull for lab work and
that sort of thing.
So, you're configuring
a new environment to connect to
an existing project is
essentially what that is.
You want to form
an existing project
that you want to spin off,
so it's easy to
create a clone and
copy some of those files
into a new workspace.
If you want to use source control
but you don't want
to have a remote,
you can do all your source
control locally
only in that case you would
initialize the Git repository
locally without pushing
it to a remote.
So you can even do
that without even
initializing or
setting the remote.
Git will work locally only.
Keep your mind you can initialize
a local repository over
an already existing
folder that has files.
So you can do a lot of
development already.
You have a full workspace.
In the workspace,
you have hundreds of
objects and then at some point,
you decide to put that
into source control.
You can initialize
that workspace as
a Git repository and it will
pick all those files up.
All you need to do
is commit them to
your repository and you're set.
Let's go back into the Azure VM,
and I'll show you how to
initialize some repositories.
So first what I want to do is
create a new AL workspace.
So we'll use AL.go.
We'll just accept
ALProject1 as the name,
use our own local server,
which creates the launch.json,
and we'll just escape
out of this one.
So now we have a completely
empty AL workspace.
So if I browse to that folder,
you can actually see
what's in there.
If you've already done
the development videos
or if you've
already worked with AL files,
you know that this is
a properly configured workspace.
Now for the less easy way,
what you would do
is you would issue
a get initialize
repository command here.
You would then go to
the server prompt
to set the remote
and then you would
sink to get this into
your repository. I'm lazy.
I want to go the easy route,
and so what I'm going
to show you is how
to clone an already
existing repository.
Before we do that though,
we have to set
some global variables in
the system so that
Git knows who we are.
So for that, we go into
the terminal and
inside the terminal,
we have to issue
a few Git commands.
So for a Git config --global,
and then we set the
user.email and then you
set it to you@example.com.
Git global user.name,
Daniel Rimmelzwaan.
So with these settings,
Git can now identify
who you are, right?
So the source control
management part
is to keep track of
all the changes.
You need to know what
the changes are,
and you need to know
who made those changes.
So then we go to GitHub
and for this I've
created a sample repository.
So on my GitHub page,
you see that I have a number of
repositories and one of
the repository is
the GitHub demo.
This GitHub demo is
a completely empty workspace,
and this completely
empty workspace
is based on a template.
I like to have a gitignore file
and I'll explain in
a minute what that does.
When we clone this repo,
you'll see how that
comes through in
the folder and I'll show
you how that looks.
So first thing you
do is you go to
the "Clone or Download" link
and then you copy this URL,
then you go back to
Visual Studio Code.
We hit control shift P and then
we select the git clone command,
we paste the repository URL
into the box here,
you hit Enter and then let's
just select a folder that
we've been using for the
location of our AL workspaces.
So we select that as
a repository link and now it
downloads that folder down
into the local folder.
So just to show you that
this is actually working,
I have a GitHub demo folder in
my AL folder now and if
I open that you will see
a hidden folder called git and
a gitignore file and so that
corresponds with what
we've seen in GitHub.
Right? In GitHub,
the only thing in
the repository is a gitignore
and for Git to recognize that
this is a Git repository,
you need this hidden folder.
So back in Visual Studio Code,
you can now open the repository
and that opens up
folder and you can take a look
at gitignore immediately.
Now you see that there was
like a little icon here,
and in the bottom,
you see that now I am looking
at the master branch of
my repository and
some other icons
are available in
the status bar as well.
So let's go into gitignore
and select everything
and delete yourself
some room and what I
am going to do is I
am going to add something
versus a comment,
"unnecessary to track"
the *.app file,
because app files are generated
by my development work.
I don't want to track
this in source control.
So now if I hit control S or
save, watch what happens.
Now you see in the source
control that there is a number,
and in there I can see that
gitignore has been changed.
If I click on that,
it'll show me
both versions of the file.
So on the left-hand side,
I see the old version
of the file.
On the right-hand side,
I see the new version of
the file and all the way
on the right here,
you see what's called
the gutter indicators.
So in here because
we don't have a lot
in there all the code
fits in there.
But you can imagine if you have
an object that is
pages and pages long,
it's very useful to have
an indicator like
that because you can
click on it and it'll take
the cursor to the edge.
So all I need to do now because
this is set has a change,
it's not set for commit yet.
The next step is to
stage the change.
That prepares it for coming
into the local repository.
So then if you want you can add
a message modified gitignore.
It's a meaningless message
because you can see
that gitignore is
the only change
but I just want to
show you an example of
what this looks like.
So at the bottom,
now you see there is a command at
change number one with
an up arrow ready ready
to be synchronized.
So if I click on this guy,
you will see this action
will push and pull commits
to and from origin into master.
Okay. Don't show
again I know what
that button does and
now it's going to
reach out to the remote and it's
going to push the commit a change
from my local repository
into the remote repository.
GitHub only wants to let
people in that it knows.
So my email address for
GitHub is password of
course and you click
login and now it's going
to go out there and
it's going to push that commit
into the repository.
Do you like to do fetch?
Let's not do that,
but this is an example of I
have a little repository.
I made a little bit
of a change and now,
if I go back in here
and I refresh this guy,
I should have two commits and so,
the first commit is
when I created this workspace
or this repository,
and I can click on this guy,
and I can actually see
the changes that are
part of this commit.
So this on GitHub is the remote.
What we're looking at here
is the local repository,
and this is how it
works in GitHub.
I have also prepared
a demo in team services,
and if I go there,
you will see that there is also
a link for cloning the project.
So, you can copy this,
copy, go back to
Visual Studio Code,
it can show control shift
P. Go to Git: Clone,
paste the link to that VSTSDemo
in the repository URL and then,
it's going to ask for
the same kind of thing.
So we select AL as
the repository location,
and now it's going to clone
that git repository from
visualstudio.com is going
to ask me for credentials.
Sign-in and now,
it has created the same kind
of repository locally,
and I can choose
"Open Repository".
So now, I have another demo
for which I have folder so,
if I go into the AL folder,
now I also have a folder
VSTSDemo and as you can see,
there's also
a git folder in there.
So, one of the things I
would like to do is I would
like to copy my gitignore file
into my VSTSDemo.
Copy the file. Now you can
see that that's a green file,
and it shows up as a change.
Create gitignore, put
that as a staged change.
Hit "source" or hit
"commit" and now,
it should say publish changes.
So, slightly different but
still it's supposed to be able
to identify the change and
push it into the remote.
So now, that should
be completely done.
I should be able to go into code,
and inside my code,
I can see I have a gitignore
that was not there before.
I can go into the commits,
and I can see that in my commits,
I have a commit
with a message create gitignore
and if I click on that,
I can see the change that
was part of the commit.
That's really it. That's how
you initialize a repository.
In the next section,
I'll talk a little bit about
how to work with
Git and I will also
show you how you can connect to
the actual project in the VSTS,
and how you can connect a
change that you're making
to the work items that
are part of the project.
So let's go back to
the presentation,
and go back to the next section
which is called Working with Git.
In this section, I'll talk
a little bit about how to
work with Visual Studio
Code and Git,
and what it's like,
and how the process works.
So, let's get started.
Git automatically tracks to
the changes and shows
the information
about those changes,
and the status onscreen.
So, in Visual Studio Code,
you can just do your work and
just develop like
nothing's happening,
and as soon as you save the file,
Git will recognize that
you've made a change.
So, in this screenshot,
you see that I am in
the CustomerCardExtension,
I have just saved it.
Made a change and
saved it and now
on the left-hand side
in the activity bar,
you see this little token
here that says a number one.
So, in source control management,
it recognizes that there is a
change to one of the files.
The bottom you can
see that I'm in
the master branch
of a repository,
and I have to
committed changes waiting to
be pulled from the remote,
and I have one commit
a change to be
pushed to the remote and so,
that's like an indicator
of the stuff that is
happening in your source
control management.
So, these indicator shows
the number of change files.
If I have more than one object
that is changed,
it will show the number of
the files that have changed.
Current branch.
Dirtiness of
the current branch means
this little asterisk means
that my branch is not updated.
It's out-of-date, out
of tune, out of touch.
We need to update that,
and you can do that by clicking
this little button
in the status bar.
Also, shown you on
the right-hand side,
you have the gutter indicators.
These are those colored blocks
in the scroll bar so,
on the right-hand side,
there is like a representation
of the file that I'm
currently working in,
and most of the stuff that
is in that current file
fits in the screen so this is
a fairly small file that is
currently in the screenshot.
But if this object is
pages and pages long,
you would see a section
highlighted in here,
and you can interact with
that gutter indicator as well.
So, you click in the middle
below the currently
highlighted that will put
the cursor right into that block.
It's very useful especially
when working with larger objects.
That also works in
the compare part in
the source control part.
So, at this point,
I have the customer card
extension working tree which is
what shows in
this source control pane
when there is a
change of objects.
So, on the left-hand side,
you see the old version
of the object,
on the right-hand side,
you see the new version of
the object and this
is an example where
the gutter indicator
highlights this part of
the object file which is
currently in the screen,
and above my current selection,
so that's up here.
There are some other things
that were done to
the file and so,
you could could click on that and
that would put the cursor
right in that part,
and the cool thing about this is
these are both editors and so,
in the current version
of the file,
you can actually make a change.
So, if you see that
a change that you've
made is not correct,
this is a final way to
do a coder [inaudible].
So, these are actual editors.
Then the next step,
when you save a file,
it is changed but it is not
recognized yet by
the repository and so,
to get that change
into your repository,
you have to do what is
called a commit and so,
to be able to commit,
you can actually select
the changes that
you want to commit.
So, if you've made a
change to five files,
you can select just three of
them and make
that part of a commit,
and that's what I've
shown you before that's
where you stage
the change and so,
you'll see five modified files
in the source control pane,
you click the plus
on three of them
that puts it into
the staged changes,
you can then add
a commit message.
Click on the check mark and
that takes those
changes and puts them,
commits them to the
local repository.
So, that's the
second bullet point.
After the work on
the code is done,
changes are first
staged and then,
commit it, and so,
both staging and
committing, our local actions.
We've only made those changes to
the local version of
the repository and then finally,
to get that from
the local repository to
the remote repository
if you're the only one,
all you need to do is push
those changes into the remote.
If you're part of a team
which most of us are,
you might see other changes
that are already in
the remote that need to be
pulled and in that case,
you hit sync and usually,
on the status bar, it's
just a single button.
You click on
that button, and then,
Git takes care of
all the changes for you.
I've gone into
branches a little bit,
and I really want to
leave it at that.
I could talk about branches
for a very long time.
These are the commands
that you can use
to work with branches,
Git: Create Branch,
Git: Delete Branch,
Merge and Publish Branch.
Publish Branch is if you
create a branch locally,
you can say publish this branch,
and that puts your local branch
into the remote.
What you could do though is pull
the master branch down to
your local repository,
then create a local branch,
a temporary branch, do your work,
then merge that branch back
into your local repository,
and then push that commit
into the remote,
and then the remote will
never see your local branch.
That's one way to do it.
There are many, many,
many different ways
to do branching.
If you are just about to get
started with source control,
don't bother about
branches just yet.
Unless you're part of
a company that already
has a branching method in place,
then you can go to a senior or
something to get an explanation.
That's about it that I want
to share about branches.
Synchronizing changes
is where you pull
the pending incoming pulls
and push all the pending
outgoing pushes.
Merge is performed in
the same operation.
So, if you do a synchronize that
pushes and pulls and
merges in one action,
and so the push is pending
outgoing pushes to a remote,
so if you have local commits
that have not yet been
put onto the remote,
you push them into the remote.
If somebody else has
made some changes to
the remote that you don't
have yet, you do pull,
and that pulls
all pending commitments
from the remote into
your local version.
Merging conflict
happens when there is
a change on the
remote that conflicts
with the change that you
are about to push
into the remote or
if you've made a change
to your local and
you pull a change from
the remote that
conflicts with what
you've had with what
you have locally.
Either way, it will be
presented to you as a conflict.
You can click on that conflict,
and you'll have to
resolve that on
your local copy before you can do
a new synchronization
to the remote.
So, this is what that looks like.
You'll see there's two messages
made in the same place.
There are two
differences in there.
As you can see, there are
these little actions
that you can take.
You can say, "Accept
the current change,
accept the incoming change,
accept both changes,
compare changes."
Those are also actions
that you can click
on in Visual Studio.
You can then address
that in the editor,
and you can decide what to
do about those changes.
But the general rule of thumb
is whatever is on the
remote should win.
So, whatever is on the remote
is what you should accept,
and then you should redo
the work that you've done but in
a way that does not conflict with
the changes that are
coming from remote.
For NAV development, that
might be fields, right?
So, somebody else has added
a field with the same
field number for instance.
The way to resolve that is to
change the field number
on your local version
because chances are that
the one on the remote has
already been published.
So, you have to be
careful how to do that.
So, you have rules and
agreements amongst
your team members on how to
resolve these conflicts.
That was it for
the presentation part.
As promised, I'm going to show
you how you can link changes that
you've made encode to
a work item in Visual Studio
Team Services.
So, VSTS is more than just a
source code management tool.
You can also actually manage
project work into work items
like Product Backlog,
items, features, epics, bugs.
You can do testing.
You can do build. I'm not
going to cover all of that.
All I'm going to do
is I'm going to show
you how you can
connect to a project
with VSTS and how you can assign
a committed change to
a work item in the VSTS.
So let's go to the Azure VM,
and let's get started.
First, what we need to do
is we need to look for
the Visual Studio Team
Services extension for VSCode.
You click on "Install".
When it completes installation,
you reload Visual Studio Code.
At that point, you can see
that it has been installed.
Now you're going
to get a message,
"Welcome to the Team version."
Let's just click this guy away.
First thing that we need to
do is we need to connect.
Now it's trying to
connect to Team Services,
but it's not connected yet.
So, now we can go to
Control-Shift-P,
the command palette.
In the command palette,
we can select "Team: Signin",
and then we can
authenticate and get an access
token automatically.
This is very handy.
You just copy this guy
and then you hit enter,
and that opens
the login screen for VSTS.
In this login page,
you then paste the code
that we've just done.
You see different code here
because the previous one failed.
So, I skip to the next
part in the video.
Then you hit continue.
You have to select an account
and probably login with that.
Sign in, I've already done
that before, so it knows.
Now, it should have
authenticated my access
to Visual Studio
Team Services in my device.
So, as you can see
now, it has VSTSDemo,
more information on
the Team Services part
that I had before.
So let me just go back into
the project on the VSTS.
I will show you
the parts that I've already
prepared for this demo.
In my VSTSDemo, I had the code.
Inside the code, we had
the commits that I've
already shown you,
but I also have
something called Work.
Inside the Works, I have
something called a Backlog.
This project was created
using the Scrum Template.
In Scrum terminology,
you have something
called an Epic and
then you have something
called a Feature.
Underneath Features,
you have things
called Product Backlog Items.
So, I have an Epic App Example,
I have a Main Feature,
and I have a Product Backlog
called Initialize Repo.
In there, I'm going
to create task.
This is Initialize Workspace.
I'm going to assign
this to myself.
"Save and Close", and now I have
a task that I have
linked to myself in
Visual Studio Code.
Now, there's a lot
to learn about VSTS.
I'm not going to go
into all of that,
but just I wanted to show you
that you can have all these tasks
and you can of course create
a list of Epics, and Features,
and Product Backlog
Items, and Tasks,
and all that stuff and
assign it to Sprints and
all that good stuff and
plan your way out there.
Now, I'll leave that
out of this video,
but I do want to show you how
you can then take the code
that you're creating
and link it to
a task that's outstanding
in that projecting VSTS.
So, for that, I
have another thing,
so that ALProjects that
we've created before.
That was that simple.
I'm just going to copy
that into my VSTSDemo.
When I paste that in there,
I can go into my Editors.
In my Editor, I can see that
I have the launch.json,
and app.json, and
then HelloWorld,
and everything in there.
So, it recognizes those
changes in source control.
Let's say we're going to
stage all those changes.
Now, because I'm connected
to my project and VSTS,
I am able to say,
I'm going to associate
work item to my change.
So, I have a Task and
a Product Backlog Item.
I want to say, I
want to link this to
the Task Initialize Workspace.
So, the file 22
is the way that you can
link to work items.
Of course, I'm just not
going to just default
to the title,
but I copied AL workspace files.
Now I commit, which puts it
into the local repository,
and now that shows up as
a committed change that
needs to be synchronized.
So, when I click on that,
it'll synchronize that piece
into the VSTS system,
and now that's done.
When I go back into
my VSTS project,
I can now click on
the Task Initialize Workspace.
As you will notice, that there
is a tab here for links.
When I click on that,
I can see that there's a parent
Initialized Repo
Product Backlog Item,
and this is the commit that I
just synchronized from
Visual Studio Code.
That takes me back into
that commit and it
shows me all the changes
that were made.
So, now I have, in
my VSTS project,
I have an overview
of all the tasks and
all the work items
that are in there,
and I have commits in
source management,
as a source control management,
and now I can actually
see and connect
everything together.
So, you can imagine that you can
have a development
project that has tasks,
and project management,
and work items,
and all those types of things.
You can go to Visual Studio Code.
All your work is being tracked.
You can link it to work items,
and this becomes
something that you can
really benefit from as a team.
So you can go into
the project in the VSTS.
There are tons of
additional extensions
in VSCode as well,
Git extensions where you can see.
One is called Git Blame.
So you can hover over a piece
of code in one of the objects,
and it will show you who made
the change at what point.
I don't have that
particular extension
installed at this point,
but you can imagine.
There's a lot of stuff
that you can add to
Visual Studio Code and
that sort of thing.
VSTS, by the way,
has build and release.
It has automated testing.
It has all sorts of goodies
that you can really
use in your development work.
That was it all that I wanted
to show you for this video.
If you want to learn more
about Business Central Apps,
go to the link on your screen.
That leaves me to say thank
you so much for listening to me.
I hope you have some value
out of this video.
I wish you a pleasant
rest of your day.
