The idea is simple: the more often you release your
software, the more chances are you won’t bump into deployment issues (ie: problems during the release).
While setting up CI
and CD in VSTS is not rocket science, it helps to know some basic concepts
before starting.
To start setting up Continuous
Integration, you need to access the Build
& Release tab in your VSTS instance.
NOTE: One important thing to keep in mind is that Build and Release are separate activities, and to have a full CI you need to configure them both
individually.
Here you will be able to manage all your Build Definitions, as shown here; if no
definition is present, you can easily create one.
Once you click on an existing Build Definition, you will see the log of your previous builds,
with their version, status, code branch, etc.
If you click on the Edit
button on the top right of this page, you will open the Build Definition in Edit
Mode, so you can configure its steps (or Tasks).
Here, as you can see, you can configure common Tasks, such as Get source (from Git or
other repositories), NuGet restore,
and several other common Build Tasks.
Setting up those Tasks
is straightforward; you just need to specify the configuration details based on
your application.
NOTE: The Publish
part of the Build Definition could
be misleading at first, as everything that gets “published” is placed within
VSO for the subsequent Release Definition to pick it up.
Basically Build
creates the Artifacts within the $(build.artifactstagingdirectory)
folder of VSTS, and Release will pick them up from there,
and deploy them to the final environment.
So, once the Build
is properly configured you can run it and verify that everything works fine (the
Get sources Task will guarantee that a Build
is automatically triggered whenever there is a Commit in Source Control
for the selected code branch, or you can always Queue a new build manually).
You can see the progress of each build by opening its page,
as shown here.
Next step is to configure the Release Definition.
By clicking on the Releases
tab on the top of VSTS, you open the
list of Release Definitions.
If no Release Definition
is present, you can create one, and then you start by adding an Environment where you want to deploy
your application, and then configure Tasks
similarly to what you did in the Build
Definition.
Here also you have plenty of common Tasks used for
deployment, such as Configuring an Azure
App Service or Slot App Settings,
Deploy, etc.
When the Release
Definition is configured properly, after each successful Build, a Release will be automatically triggered, and if all Tasks are successful your application
will be deployed to your environment.
And that’s it, now you can enjoy your CI and CD on VSTS!
