So now that we have our API somewhat useful, we are going to create the Continuous integration part of our DevOps pipeline. Basically we are going to:
- package up our code and get it ready for deployment.
- execute our unit tests in azure
- configure our azure infrastructure
all automagically!!! so lets get started, now you could start in VS Code however I prefer to start in the DevOps portal because I Have a terrible memory and the wizard/snippets Microsoft provides are dart.
Now I put my code up into my azure repo so that is what I am going to select
next we have to pick our repository, currently we only have one, but its pretty standard for enterprise level projects to have more than just a few, usually one per micro-service, three for mobile apps then some or web front ends, it can really get out of hand.
but we only have one at this point, poorly named and half complete... just like my life...
next we have to set up our initial configuration, since we are using .net core, just pick that one
next we have to set up our initial configuration, since we are using .net core, just pick that one
and now you have your very own YAML file
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
inputs:
restoreSolution: '$(solution)'
- task: VSBuild@1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: VSTest@2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
But you maybe wondering, what is a YAML file and why do i want one? well in short it is a set of instructions used by the Continuous Integration step in a devops pipeline that does stuff. now that stuff could be displaying a knock joke, or it could as in this case install nuget, install nuget dependencies, build your solution and execute your unit tests. basically it lets you do some cool stuff once you push your code.
but first you may have noticed that the trigger is master, well we renamed our master branch to prod, and we have a dev branch so lets make those changes right off the bat.
trigger:
- dev
- prod
next you may be wondering where in our project is this file, we'll technically its not in your project yet, first we have to save it, placing i in your repo, then we will have to pull it down into our code.
hit save & run
You'll be prompted to check in your new file into your repository
Right after hit Save and run the second time, you will be brought to the pipleines page with our new pipeline executing
Click on the job and this will give us a view into this pipeline execution
Here you can click on any of the steps on the right to get a log of the execution, this will be extremely valuable once you start getting deployment issues for you will be able to view errors here.
Now we have one last thing to do, this has only been checked into our prod branch and is only available in our repo, if you look at our prod branch in vs code you wont see any hint of a yml file
so lets pull it down from our repo.
git pull
and voila
our yml file in our local directory, now lets switch to our dev branch and merge it with the master to get our yml file in both our branches.
notice our dev branch does not have our yml file, but once we execute
git merge prod
we now have our YAML file in both branches
next lets push our dev branch changes up and check out our pipelines
and we have two executions, one from our initial check in on our master branch and one from when we merged prod into dev.
and that is pretty good for today, tomorrow lets configure our Unit tests to be a bit more visible during the CI stage of our DevOps pipeline.
