Jenkins .Net and Docker?

Question

I'm absolutlly a newbie on CI (Continuous integration), Docker and Vagrant.

I want to use jenkins in order to build my .Net projects build system, connected to a BitBucket repository, using a webhook.

I've seen that Docker has an image for Jenkins, but I don't know how can I use Jenkins in a Docker image in order to build my .Net projects. So, .Net projects are going to perform msbuild scripts, and I figure out it requires some kind of .NEt framework installation. Is it possible to run msbuild scripts on a vagrant image?

What about Vagrant in the middle of this behavior? I hope to have been clear enough.

Answer 1

There are a few things in the question that may require some clarification but I'll attempt an answer

A CI process is where you continuously verify your codebase when it is committed to a version control system. This could be as simple as compiling the code and verifying that it builds successfully. In addition you might run a suite of unit tests, deploy the code to an environment and run integration tests or even run User Acceptance tests. It's best to start simple and add layers rather than trying to do everything in one go especially if you're new to CI.

A CI process provides fast feedback (did the thing I just changed break something) this increases confidence that your codebase is stable and release worthy. The more automated testing you do, the more confidence you have that your change is sound and didn't have unintended side effects. CI builds should be as quick as possible. The idea is to get fast feedback, so if your build takes 90 seconds, that's awesome. A developer doesn't have to wait very long to find out if they broke something. If it takes 90 minutes then the developer isn't getting timely feedback, and has probably moved on to another task (or is sat around waiting for the build to complete). This means that they could be making changes to a broken codebase. Some people use the coffee test. i.e. if the build takes longer than the time it takes for a developer to go make a cup of coffee and get back to their desk then it's taking too long.

You can use Jenkins to implement CI, it's a good choice as it has many plugins available to help you add layers to your CI process. It's also has a big community around it so new tools and technologies are added regularly and there are lots of knowledgeable people out there to help out if you have questions.

To run a CI server like Jenkins you need to install it somewhere. Typically this is on a dedicated server. If you want to build .net code this will be a windows server. (whilst .net core is now OSS and runs on Linux it's unlikely at the moment that existing .net apps will compile on Linux without some effort, this may change as .net core evolves and becomes more feature complete)

Here is a good "getting started" guide to install Jenkins and set it up to build .net applications.

The Docker container you mention would be a way of easily deploying a Jenkins server on a Linux based environment. As ZeissS mentions, container support isn't ready yet on windows.

Having said that, if you have Linux infrastructure available, then you could use docker to set up the server and have windows based agents or slaves to perform the actual builds. Using slaves is good as you can perform multiple builds simultaneously. If you have multiple solutions and / or a large development team then you'll probably want to utilise them even if you use windows for your Jenkins server.

Vagrant allows you to create virtual machines based on a template. This means that the machines are consistent.

It could be used in a number of places. For example you could use it to create the slave machines for your build process, or to spin up an environment to run your integration / user acceptance tests. Remember though that CI is about fast feedback so if you're thinking about using disposable machines for either slaves or environments then you need to consider the time it takes vagrant to create a new machine. I've found that a good use is to create a template used to build a VM running on the devs workstation for local testing before changes are committed. You might also use it to create environments for a longer running build (nightly) where you run a fuller more comprehensive set of tests or build the full codebase for you application rather than the just the components that have been changed by the commit.

Finally I'd say that whilst you can use Jenkins or any other CI server to handle deployment of your code to an environment. I prefer to use a Release Management tool like Octopus Deploy you can trigger it from Jenkins and it will handle a lot of your deployment needs out of the box (pushing code to remote machines, configuring app pools / windows services etc) It's entirely optional but something to consider.