CI and CD With Azure DevOps
CI and CD With Azure DevOps
Pre-requisites:
An account in Azure
Lab Tasks:
Import Source Code into your Azure DevOps Account with Git
Create local git repo from your Azure Repos using a git repo
Set up Service Endpoint in Azure DevOps
Import Continuous Integration Build Definition into Azure Pipelines and kick off a build
Import Continuous Deployment release definition into Azure Pipelines
Export Build and Release Definitions from Azure Pipelines and commit changes to Azure
repo to kick off CI and CD
Confirm successful deployment to Azure
(Optional) Make a change to PartsUnlimited website and see it being reflected back into
Azure
approx. 80 minutes
Task 1: Import Source Code into your Azure DevOps Account with Git
In order to use Build using Azure Pipelines and Azure Repos, you must contain the source code
for the application. For this lab we are using a Git project. The next couple of steps will allow you
to add the PartsUnlimited source to the Git master repository.
Note: You can return and access your project repo files at any time by going
to Repos > Files
Congratulations, your code should now be in Azure DevOps.
There are a number of ways to create a local git repo and there are a number of tools which you
can use.
Firstly you need to install git in your local environment, see the page 1.5 Getting Started -
Installing Git for details on how to install git in your local environment.
The steps we outline below will be based on a Windows installation but you could also perform
similar tasks on linux or mac if you needed using the git bash.
1. Download and Install Git on your local machine by going to https://git-
scm.com/download and following the steps and prompts in the installation wizard.
2. Once installed, create a local folder where you can place the repo files i.e. C:\Repo
3. Open Git cmd window (e.g. in Windows 10, click on the Start menu and search for the
application called Git Bash) and go to the folder where you want to place the git Azure
Repos files i.e. C:\repo by running the command
4. mkdir /c/Repo
5. cd C:\Repo
6. Return to Azure DevOps and in your project go to Repos > Files and then click on Clone.
8. Return to your local git cmd and in the folder where you want to place the repo run the
command. If you are prompted with crendentials, please use the same one you used to
login to Azure DevOps. For Lab users, please continue to use the lab credentials
throughout.
9. git clone <the copied URL for your Azure DevOps repo>
Note: A new folder named with your project name is created in your local repo folder and
you will see your files within that folder. i.e. C:\Repo\PartsUnlimited
10. Go to the local folder and view the files present. You can now modify any of the Azure
DevOps repo files locally and push any changes up to the Azure DevOps repo using the
git commands, or variations on them. In later stages, we will be pushing to the Git repo,
but for your reference, the below git commands would execute a git commit followed by
a push on your git repo:
Before we create a release pipeline, we will need to create a connection between Azure DevOps
and our environment within Azure. This will then allow us to deploy our release pipeline into our
resources over in Azure.
8. Once the import has done, you will need to update some information. Click on
the Pipeline heading under Tasks and under Agent pool select Hosted VS2017 in the
hosted section. If this is already filled in please select the option with the VS logo beside
it.
9. Now go to Get Sources under Tasks and make sure that that the branch that has been
selected is master and it is using this project.
10. Click on Triggers and ensure Enable continous integration is ticked. Afterwards, change
the value of Branch specification to master.
11. Now click Save & queue, and Save & queue again when prompted. This will kick off a
build and you should see a message saying a build has been queued. You can click on the
link provided to view the build progress. It should run and complete successfully, it may
take up to 10 minutes to complete.
Task 5: Import Continuous Deployment release pipeline definition into
Azure DevOps and kick off Continuous deployment
Note: If you already have at least one release definition then skip to step 2, otherwise you are
going to create one very quickly to be able to access the import a release option.
and in the Add an artifact dialogue, select Source Type as Build, and then specify your
the Project i.e. Parts-Unlimted, and specify the Source as your imported build pipeline
i.e. Parts-Unlimited-CI-import, the Source alias will auto populate, and click Add
5. Make sure that the Continuous deployment trigger is enabled, by selecting the
lightning bolt to the top right of the artifact.
7. Go to Tasks > Dev, or click on 1 job, 2 tasks in the pipeline graphical display, and select
the Agent Phase you will see that Agent pool is in red. Select the Hosted
VS2017 option.
Then complete these steps again for the Staging and Prod environments. You can access
these environments by clicking on the Tasks > Staging and Tasks > Prod respectively.
8. Now go back to Tasks > Dev and under the Azure Deployment: Create or Update
Resource Group…. task, you will need to update the Azure subscription to the Service
connection that you specified earlier in Task 3 i.e. Azure SP and the Location, you can
specify the Azure DataCenter nearest to you.This only needs to be done in the Dev Task,
as this task only exists under Dev.
9. Under the Azure App Service Deploy…. task, you will need to update the Azure
subscription , again to the service connection value you created earlier in Task 3, and
the Slot. To show the option of the slot, tick the checkbox Deploy to Slot or App
Service Environment and enter the value Dev.
This needs to also be done for the Staging task and the slot value to use there is Staging task. It
does not need to be done for the Prod task, as leaving that value blank there means it will
deploy to production and not to a slot.
There should now be no more red highlighted section under Tasks
10. Navigate back to the Pipeline and you will see some pre- and post- deployment
conditions where you need to select the approvers for the Staging and Prod steps. Add
your name as an approver to these (for lab users, enter labuserX with X being your lab
number).
11. Select the Variables tab, followed by the Pipeline variables. The red highlighted issues
here are the two Password values. You will need to select the Lock icon next to them and
type in a new one, you can use the password of Pa$$w0rd01 if you wish. For the rest of
the values although not highlighted in Red you must change these also to be unique
value by adding "labuserX" (with X being your lab user number) to the end of them. We
are deploying live web services and this is to ensure naming values rae unique as
required by the services. See the bullet notes below when determining the values
required.
For Lab users, please ensure input the name of the preprovisioned Azure resource group, which
would be PartsUnlimited-WebApp-LabUserX-RG where X is your lab user number.
Note: You just need to add your initials to the end of the current values, but you should be aware
of the following in case it is needed.
The parameter values need to adhere to requirements for the Azure resource they are
deploying. If they do not meet those requirements you may receive an error when
deploying.
In general, if you try to make all values unique, lowercase and between the resource
character limits, i.e. if you stay under 24 characters you should be fine.
You should also not have an underscore or dash in the name, as during deployment
some resources and object names are generated and will append names with other
values with dashes and underscores, and as a result may give errors if used
12. All errors should now have been addressed. Prior to this the Save option was not
available, it was greyed out. However, now that there are no errors present, you can
click Save to save the release.
Note: If you had to define an empty release definition before, then it can be now deleted by
clicking on the dropdown arrow next to the empty definition and selecting Delete if you wish to
do so.
Congratulations, you have imported a release definition successfully.
Task 6: Export Build and Release Pipeline definitions from Azure DevOps
Now that you have configured build and release pipelines specifically for your repository in Azure
DevOps, it’s a good idea to replace the given templates with your own.
This will trigger a download of the build definition in your browser in JSON format.
Click Save as and place this file in the templates\build definitions directory of your
local repository.i.e. C:\Repo\PartsUnlimited\templates\build definitions, you can
append your initials to it if you like or overwrite it, and verify it downloads successfully.
2. Navigate to Pipelines > Releases and click on the elipsis option beside your release
pipeline, i.e. Deployment and select Export.
This will trigger a download of the release definition in JSON format. Click Save as and
place this file in the templates\release definitions directory of your local
repository.i.e. C:\Repo\PartsUnlimited\templates\release definitions, you can append
your initials to it if you like or overwrite it, and verify it downloads successfully.
3. Open the git cmd window and go to your local repo location
i.e. C:\Repo\PartsUnlimited.
5. git add .
Identifies who is making the commit (change X to your lab user number)
6. This uploads commits to the Azure DevOps repository. Go to your Azure DevOps repo
and verify the files have been pushed up to the Azure DevOps repo as expected.
Congratulations, now you can reuse your templates with other projects or lab tasks if you
wish.
The changes you have just committed will trigger a CI build and a deployment to Azure using
your release pipeline.
1. You can view the release pipeline progress by clicking on the release and viewing the
pipeline progress, as per the below screenshots.
Note: You will not see anything in the release pipeline until the build has completed. You can
view the progress of the build by navigating to Pipelines -> Builds. Upon completion, you will
be able to view the deployment under the respective release pipeline.
2. Once the deployment to the dev slot is completed, the pre-approver for
the Staging environment will receive an email notification about the pending
deployment to the staging slot.
3. To approve or cancel the request, In the release pipeline progress progress pane, click on
the Approve or cancel the deployment button (circle with diagonal line through it) and
choosing it again on the approval pane.
Note: The Staging environment also has a post-approver who must confirm that the app
is stable and ready for the production environment. The pre-approver for
the Production environment must also confirm before this final deployment.
Continue the approval processes until the release pipeline completes successfully.
4. In Azure, find your App Service with the name of the web server you specified, and open
its URL (this is the production site).
Note: In the Deployment slots section you can find the dev and staging slots with their
respective URLs.
This step is optional. If you are interested in making change to your live website, you can make a
change to the homepage.
Upon navigating to the App Service URL (as instructed in Task 7, step 4), you will notice there is
an advert stating a 20% off on tires. We will now change this to 40% instead.
4. Upon completion of the build, view the release pipeline and perform the approval
process, identical to what was done in Task 7.
5. Once the release was successful, navigate back to the App Service URL to view the latest
change.
6. Well done!
Summary
In this lab, you have learned how to push new code to Azure DevOps, set up a Git repo, create a
Continuous Integration build that runs when new commits are pushed to the master branch and
create a Continuous Deployment that deploys an application to environments automatically. This
allows you to receive feedback as to whether your changes contain syntactical errors or break
existing tests, as well as saving time by automating the deployment process.
To learn more in-depth information about CI and CD try out these labs:
Documentation for PartsUnlimited
Contact GitHub
Pricing
API
Training
Blog
About