GitLab CI/CD with .Net Framework
Hello everyone!
As I promissed, in this article I’m going to talk about CI/CD on GitLab for .Net Framework applications.
If you still don’t know what is CI/CD and what it is for, check this: http://bit.ly/what-is-ci-cd.
I appreciate the help given by my friend Milton Rodrigues to be able to gather all the steps presented below!
GitLab Runner
Before we continue, you need to know what GitLab Runner is: “GitLab Runner is the open source project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with GitLab CI, the open-source continuous integration service included with GitLab that coordinates the jobs.”
That definition above and so much more information you can find in https://docs.gitlab.com/runner/.
The Runner is written in Go and runs on any operational system. It’s the one that makes the work of integration and deployment to you when using CI/CD.
For that, you need to download and register (configure) a runner to your application or you need to use a shared runner. If you choose to install it, that can be done in your own machine or in a specific server in your network.
Prerequisites
Well, once we are talking about .NET Framework, we need to make sure some tools are installed in the machine that the runner are going to be configured. Other tools are general, independing on .NET.
So I present you the checklist below:
Windows
Yeah! .NET Framework only works in Windows OS, so the machine you are going to use needs to be using Windows.
Git
Do you think we need Git installed? Alright, that’s a joke, it’s obvious we need git, by the way we are going to use GitLab!
So, make sure you have it installed in the machine you want to use: https://git-scm.com/downloads.
MSBuild
To be able to build and publish our application, we need to have MSBuild installed.
If you have Visual Studio in the machine you probably don’t need to worry with this step, but the more common scenario is to configure the runner in a server that doesn’t necessarily have VS installed.
Check https://visualstudio.microsoft.com/downloads/ and look for “Tools for Visual Studio” and inside it, you download “Build Tools for Visual Studio”:
Install the build tools. In my case I’m using the version 2017 and MSBuild is installed in this path: “C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin”.
VS Web Build
With the same “exe” you installed MSBuild, you also install VS Web Build by running the following command in cmd:
vs_buildtools.exe — add Microsoft.VisualStudio.Workload.WebBuildTools
Nuget
To be able to restore the packages of our application we need to have nuget executable.
Check https://www.nuget.org/downloads and download the recommended latest version. Copy the “exe” file to a folder in your machine, like “C:/Tools/Nuget”.
.NET Framework
Just make sure the machine have the desired version of .NET Framework. Look, it must be the same your application is using.
Configuring the Runner
Wow, finally it reaches this point! Now we need to download and configure the GitLab Runner.
Nothing is better than the official documentation, so follow the steps of: https://docs.gitlab.com/runner/install/windows.html, in the “Installation” section, including the link “4. Register the Runner”.
Look, while registering the runner, when it asks for the Runner executor, use the option “shell”.
After doing all the steps, go to the folder you created to place the runner and edit the file config.toml adding the following line below the “executor” line:
shell = “powershell”
GitLab Settings
Now, if you go to your repository on GitLab, access “Settings > CI/CD” and expand the “Runners settings” you are able to see your runner already assigned to your project.
Beside the “Specific Runners” section, click in “Disable shared Runners”.
Shared runners are other approach of using runners, and you can deep more according to your necessity. For now, just know you need to disable it!
Click on the button with a pencil on the right side of your runner hash to edit its settings. Select the option “Run untagged jobs” and save changes:
Continuous Integration
Now that your runner is configured you can create your application to check if everything is OK!
I created a very simple web application with .NET Framework 4.6.1, with the default theme of VS. And also I added a test project, just to see the test being runned, simulating it.
In my example I used xUnit to test the application. To have it succesfully running in the CI process, you need to add the package “xunit.runner.console” in your test project.
Other information is that I was able to make it work using xUnit up to version 2.3.1.
The project I am talking about you can check in: https://github.com/gabrielfbarros/gitlab-ci-cd-dotnet-framework.
After you have your project created, you need to create a new file in the base folder of your project, called “.gitlab-ci.yml”. Once you have this file in your folder, when you push your code to GitLab it is going to understand that a CI/CD process must to be started, and through the runner you have configured, the steps that you put inside the YML file are going to be executed. Just like magic!
The YML file uses a particular structure, and have some specific words that must be used, and you have a lot of cool things that you can do with it. Check this to more information: https://docs.gitlab.com/ee/ci/yaml/.
At this moment, we want to configure a simple pipeline with CI only. So you need to include the content below in your YML file:
Fast explanations:
variables
Here we define some variables that will be used below in the file. Basically are paths to the nuget.exe that we downloaded, to the msbuild.exe that we installed, to the package “xunit.runner.console” and to the folder where the binaries of test project will be placed after the project is built.
stages
Here we define kind of steps our pipeline will have. For now, they are only build and test.
build_job
A job is basically the “implementation” of a stage that we defined above. The build_job will run only for “branches”, not for “tags” for instance. We can specify a specific branch to a job runs for!
And the script or the steps the job have for now is: restore the packages via “nuget .exe” and build the application using release configuration.
This build_job will generate some artifacts that will be provided to next stages that can need those artifacts. In this case we provide the binaries of test project and the content of the package “xunit.runner.console”. These two artifacts will be used by the test_job.
test_job
This job is for the stage “test” and basically will run the tests.
Look that this job depends on build_job, so if the build process fails, the tests won’t be run!
With this simple configuration, we have Continuous Integration working! That means, any push to GitLab then the code will be integrated with what is in GitLab, the project will be built and the tests will be run, if everything works fine, we should see in “CI/CD > Pipelines” to the repository in GitLab:
Clicking on it you can see more details.
Continuous Deployment
Once we have our code integrated and tested, we can deploy it! That’s the CD part. Remember that CD can also be about continuous delivery, but in this example we are already deploying it.
To be able to deploy the application, you need to create a publish profile to deploy in a folder. So, create a publish profile in your project and make sure “*.pubxml” files aren’t being ignored in your .gitignore file.
In my example, the deployed web site is hosted in the same server where I configured the runner, so that makes things easier. So, configure the IIS with a new site to host your application, already creating the folder on wwwroot, etc.
In your YML file, include a new stage “deploy”.
In the build_job we need to provide a new artifact, that are the binaries published of our web site, so include a new line to the “script” section:
- ‘& “$env:MSBUILD_PATH” src\CiCdExample\CiCdExample.csproj /p:DeployOnBuild=true /p:Configuration=Release /P:PublishProfile=FolderProfile.pubxml’
And a new artifact:
- ‘.\src\CiCdExample\bin\Release\Publish\’
And “implement” the stage deploy, that will copy the files created while publishing the project to the folder used by IIS to host the web site.
Oh, and this last job should depends on build_job and test_job, by the way, you won’t want to deploy your application if the tests fail!
The final version of the YML file is:
So now, when you push the code to your repository, besides the CI process, the website should be updated in IIS as well!
Yeah, very cool! That was exactly the face I got when I saw it working in my machine by the first time.
Conclusion
As you can see above, to configure a runner and also pipelines for GitLab is not a big deal.
.NET Framework brings a bit more of complexity because of several tools you need to have configured as well, but once you did it, it’s done for that runner and project.
Now, I have already mentioned, it there is a lot of more things to learn and try: docker, kubernetes, etc.
This was a very simple example to you start practicing with GitLab CI/CD.
If you have other understanding about this subject, please let us know, leave your notes!
I hope I could help you!
Bye!
