Waiting for the beat to Devop - Part 1
I've read a book. Crazy I know. It's called 'The Phoenix Project' and it's basically a novel about IT DevOps, which basically stands for Development Operations. Not a once upon a time novel, but it's situated in a fictional company whereby no IT DevOps is currently in place. It follows the new IT Operations manager trying to turn things around for this company and really opened my eyes to vast world of devops. So this got me thinking, here at Quaytech we not only build great systems, but we look after and maintain those systems for our clients going forward. Whether that be making changes, adding new features or simply hosting those systems, we handle it all. So I began looking into how can I implement more DevOps into our current setup. So what did I do?
I took the most recent major project the CRM system and thought how can I build confidence into every major release we do of the Web API (Application Programming Interface). We have written unit tests for this project which we can run to check whether the end points are working as expected. But this is still a manual process of clicking buttons. A part of DevOps is about automation, removing the manual tasks that you can get a tool to do for you. I began to look into ways to remove this manual process.
We build the majority of our systems using C# which is a Microsoft Technology, so I started looking into the Continuous Integration side of Azure Devops, which is contains Microsoft's Continuous Integration tool. I watched this video which showed a basic overview of how to create a simple build and release from a checked-in git repository. So with this as my base I looked on how to expand this.
The first thing I looked at was how to remove the need to start the build yourself. So inside my build yml I added the ability for the build script to be triggered when a certain repository was pushed to in git. Using this command:
trigger:- master
Note : Indentation is important in a .yml file
Next I wanted to create a build to make sure the project compiled okay, I used the azure provided Virtual Machines to do this. You can get up to 1800 minutes free using the basic tier. The script below basically says, using a visual studio 2017 on windows server 2016, build a copy of the project specified in this case CIPlaying.csproj in the release mode.
pool:vmImage: 'vs2017-win2016'variables:buildConfiguration: 'Release'steps:- script: dotnet build CIPlaying/CIPlaying.csproj --configuration $(buildConfiguration)displayName: 'dotnet build $(buildConfiguration)'
Next I added the ability to run the unit tests after the build was completed. This code specifies that using the .net core tasks run the test project.
- task: DotNetCoreCLI@2inputs:command: 'test'projects: 'CIUnitTests/CIUnitTests.csproj'
Note: The test results are displayed in a separate test section of azure devops, it provides you with a good overview of which tests have passed and failed and any error messages associated with them.
Next I wanted to build a published version of the API project to release. Done like so:
- task: DotNetCoreCLI@2inputs:command: publishpublishWebProjects: Truearguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'zipAfterPublish: True# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.- task: PublishBuildArtifacts@1inputs:pathtoPublish: '$(Build.ArtifactStagingDirectory)'artifactName: 'CIPlaying'
This created an artifact that I could later pull down in the release pipeline and deploy to my chosen environment. Lastly I needed to create a second artifact this would contain our published api tests. Which would run against the new published version of the API.
- script: dotnet build WebApiTests/WebApiTests.csproj --configuration $(buildConfiguration)displayName: 'dotnet build Web api Tests $(buildConfiguration)'- task: DotNetCoreCLI@2inputs:command: publishpublishWebProjects: falsearguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)/WebApiTests'zipAfterPublish: false- task: PublishBuildArtifacts@1inputs:pathToPublish: $(Build.ArtifactStagingDirectory)/WebApiTestsartifactName: WebApiTests
To make this work I created a build for the Api Test Project and created a release artifact from the build for use in the release Pipeline. In part 2 of this blog I will discuss how I set up the Release Pipeline to pull down these artifacts and release them.