Recently I’ve been doing a lot of DevOps in order to automate the continuous integration and deployment (CI & CD) of the microservices as much as possible. In this article, I’d like to share with you some of my experiences how to get started with creating your own deployment process and this is going to be the first part of the series of articles related to this process.

I’ll be using one of my open source projects Warden as an example, however, I follow pretty much the same practices in the other projects I’m working on such as e.g. Collectively which is built using similar patterns and practices related to the microservices architecture. By the way, I’d be grateful if you could take a look at the first concepts of the new Warden Web UI shown here and share your thoughts whether you like it or not (but that’s off the topic).

The first thing that you need to do, is to sign in to the Travis CI build server, which can be done using the GitHub account. And once you set the required permissions, you shall see the list of your repositories and organizations (if you’re a member of any). Here, you can easily toggle which repositories should take part in the build process.

Sign in to the Travis CI and select repositories.

Alright then, the next step is to setup the build configuration file, thus let’s take a look at the basic structure of the project directory containing a .NET Core application.

.NET Core service project structure.

As you can see, I have multiple services and all of them follow the same directory structure.
I’d have the actual service e.g. Warden.Api and another 2 test projects. However, you can have much more projects containing additional layers or so. Just keep them in the same root directory if possible. Let’s go one step further and take a look at the actual .travis.yml file which holds the configuration being used by the Travis CI build server.

travis_build.sh

run-tests.sh

after-success.sh

There might seem to be a lot of going on, but it’s actually quite simple, so let’s discuss this particular configuration. We want to build a csharp project, and we need to have the sudo privileges e.g. in order to correctly restore the packages via dotnet restore command. Next, we want to use one of the latest versions of the dotnet framework being 1.0.0-preview2-1-003177 in that case (which does support project.json RIP [*]), however I’m pretty sure that by now there’s already a new version available that works with this ugly .csproj files.

Next, we do care only about master and develop branches – if you leave this option empty, the Travis CI will run build for any branch in your repository (including the feature ones that might be temporarily broken or so). And now we’re getting into some tricky parts – before_script means that we want to set the proper file access in order to execute the bash scripts that are included inside them. In the script part we’re saying what scripts should be executed during the build phase (the order does matter), and later on, we want to run some additional script(s) once the built was successful.

Eventually, we’re stating that we do not want to receive spam after each successful build, so let’s send an email only on_failure. And this is what you will get to see once everything was set up correctly (like I do here and here).

Successful Travis CI build.

Moreover, you can add a graphical status e.g. your repository, simply by fetching the image file from the following URL: https://api.travis-ci.org/{repository}/{project}.svg?branch={branch}.
For the Warden.Api repository the markdown code looks like this:

Travis CI build status.

And that’s it for now, I really enjoy using Travis CI as it works fast, provides a lot of configuration options and is very easy to get up and running quickly. In the future posts, I’ll talk about integrating the build system with Docker Hub registry, MyGet packaging service and other useful tools.