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.
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.
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
language: csharp dist: trusty sudo: required mono: none dotnet: 1.0.0-preview2-1-003177 branches: only: - master - develop before_script: - chmod a+x ./travis-build.sh - chmod a+x ./run-tests.sh - chmod a+x ./after-success.sh script: - ./travis-build.sh - ./run-tests.sh after_success: - ./after-success.sh notifications: email: on_success: never on_failure: always |
travis_build.sh
1 2 |
dotnet restore dotnet build **/project.json |
run-tests.sh
1 2 |
#!/bin/bash dotnet test ./Warden.Api.Tests |
after-success.sh
1 2 |
#!/bin/bash echo I'll be invoked after the successful build! |
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).
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:
1 2 |
[](https://travis-ci.org/warden-stack/Warden.Api) [](https://travis-ci.org/warden-stack/Warden.Api/branches) |
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.
I have multiple tests libraries, essentially one for each project (I believe it’s a good pattern). How would you run all of them in
run_tests.sh
?Is there something more elegant than using bash or powershell functions to find all test projects and test them?
What you can do in Travis, is to execute your own scripts e.g. to run the tests, therefore you’re forced to do this way (at least AFAIK). I think that you could use e.g. grep to find all the projects that contain “Test” in their name and then run a loop that would execute dotnet test for a given project.
Use Cake http://rehansaeed.com/cross-platform-devops-net-core/
Pingback: .NET Core continuous deployment part I – Travis CI integration - How to Code .NET
Pingback: Dew Drop - March 13, 2017 (#2438) - Morning Dew
Nice guide on setting up CD! You can also see the status of your Travis builds right on the desktop using tools like CatLight – http://bit.ly/2mGwJK7
That seems to be a really cool app, thanks!
Pingback: Who you should care about DevOps | Piotr Gankiewicz
Nice Article. In short description good explanation about the DevOps. Thanks For sharing the informative news.
Thanks, I’m happy that you liked it :).
Thank you for made CI integration simple…
Nice Article
Landmark Multispeciality Hospitals in Hyderabad