Posts tagged with TeamCity

  • Playing with TeamCity on Azure

    I spent the past two days playing with setting up TeamCity on Azure. This is just a poc more than anything else, but it’s always fun to do something new. I had to fiddle about with some things that didn’t work as expected, so here are some notes to remember what I did.

  • Using AWS ECR as a Docker registry

    In this post, I’ll modify the pipeline from the previous posts to use a Docker registry powered by AWS ECR (Amazon Elastic Container Registry).

  • Adding code coverage with nyc

    In this post, I’ll add code coverage to the build pipeline and configure TeamCity to break the build if the code coverage drops.

  • Adding mocha unit tests

    In this post, I’ll add unit tests to the example application that I’ve been fiddling around with in the recent posts.

  • Adding WebdriverIO tests

    In this post, I’ll add some automated browser tests using PhantomJS and WebdriverIO.

  • Waiting for the correct version after deployment

    In this post, I’ll implement a post deployment check that waits until the application is running with the expected version. The first step is to make the application aware of its version. The easiest way to do that in our setup is with an environment variable. We’ll modify the deployment template of the Helm chart:

  • Removing the image-tag.txt artifact

    Small update on replacing the image-tag.txt artifact with the implicit build.number parameter.
  • Smoke test for a Docker image

    According to Wikipedia, a smoke test is a preliminary test that reveals simple failures severe enough to (for example) reject a prospective software release. The process of smoke testing aims to determine whether the application is so badly broken as to make further immediate testing unnecessary. If we consider our dockerized blog-helm web application, a possible smoke test can be: can we pull the image from the registry? If we run the image, does the container stay alive or does it crash immediately? In this post, I’ll implement this in an extra build configuration in TeamCity with a generic bash script doing the actual work.

  • Build chains in TeamCity

    In a previous post, I had configured a deployment build configuration in TeamCity. I had mentioned back then that it’s possible to set it up in a different way, which makes it is easier to visualize the deployment pipeline across all environments. In this post, I’ll modify that deployment pipeline to use snapshot dependencies and project templates.

  • My local TeamCity setup

    In my recent blog posts I’ve played a lot with TeamCity. Often, when I want to blog about something, I end up doing some irrelevant yak shaving, which sometimes is also interesting. In this post I’ll show how I’m currently setting up TeamCity locally on my laptop.

  • Build configurations as code with TeamCity

    In this post, I’ll show how to setup TeamCity so that your project’s build configurations are stored in your git repository. This allows you to change your build configuration in the same way you change your code, via a pull request. It allows to make changes to the pipeline without affecting other branches. And all that is supported in a way that you don’t have to give up the user friendly way of defining your build via the UI.

  • One script to version all

    This is just a fun hacking post. I put together a script that is able to handle all versioning strategies that I mentioned about in the post about versioning.

  • Semantic versioning with GitVersion

    I recently stumbled upon a tool called GitVersion which takes a different approach on versioning. I already mentioned some options regarding versioning, but all of them require you to actively specify the version somewhere. GitVersion instead is able to calculate it based on the state of your git repository.

  • Fixing root permissions on Docker volume

    In a previous post, we saw how to dockerize the build plan of an application. Typically, you’ll want the build to run tasks like linting and unit tests, and then publish the results of these operations as XML reports that the build server can consume and present in a human friendly way.

  • CD with Helm part 8: DTAP

    In the series so far, we have build a CI pipeline that produces a Docker image and a Helm chart. They are linked together with a unique version, allowing us to use Helm to deploy any feature branch we want. Now we’ll see how to implement a traditional DTAP and use Helm to deploy whatever, wherever.

  • CD with Helm part 7: Docker registry

    In a previous post, we had taken a shortcut: we had TeamCity running inside Kubernetes, sharing its Docker daemon. That trick allowed Kubernetes to access the Docker images produced by our builds. In this post, we’ll setup our own Docker registry and publish Docker images there.

  • CD with Helm part 5: versioned artifacts

    In the previous post we created the Helm chart for our hello world blog-helm application. The Helm chart contains all the information we need to deploy our application to a Kubernetes cluster. But so far, we always deploy the latest version. In a CD setup, we’d like to be able to deploy any version, from any feature branch, at any given point in time, to any environment (DTAP). Let’s start by looking at versioning.

  • How to build a smashing dashboard

    An information dashboard is a way to visualize and share information within a team about things that are important. You can setup a big monitor showing live updates about build statuses, open jira issues, a sprint burndown graph, the health of your applications on production, and so on. Having this information visible is a way to keep it on the back of your head (out of sight, out of mind). It also shows to people outside your team what matters to you.

  • Linting with Checkstyle

    Code is going to be written once but read many times. A consistent coding style across the entire code base is important to increase readability and maintainability. Luckily, there are tools that can help to define and enforce such styling rules. From mere cosmetics up to nasty code smells, static code analysis can help increase the quality of your code. I wrote some posts on static code analysis in JavaScript a bit more than a year ago (which in the JavaScript world means the tools are now different, ESLint instead of JSCS/JSHint). In this post we’ll see the Checkstyle tool in the Java world, how to use it with TeamCity and IntelliJ and finally a few words about SonarQube.

  • Code Coverage with JaCoCo

    Code Coverage is a useful set of metrics that show you how much of your code you’re impacting during testing. It doesn’t say much about the quality of your tests (you can read more in the old post What is code coverage?), but a 30% coverage is definitely worse than 90%. Let’s see how we can use JaCoCo to see our code coverage in the Java world. We’ll check a few options to use it, such as using it manually, using it within a CI, breaking the build with it, etc. The assumption is we’re working with a Maven project.

  • Run dotCover from msbuild and ccnet

    TeamCity is a very nice tool that I use at home. Unfortunately the free license allows up to 20 configurations. That’s why I’m experimenting also with another free tool, CruiseControl. It’s definitely not as easy as TeamCity, you have to edit (which means learn) an XML file that the server picks up. In general, it probably supports what TeamCity supports, but you have to make everything yourself with a lot of work. Then again, it’s completely free.

This site uses third party cookies from Google Analytics and Google AdSense Accept and close popup