Posts tagged with TeamCity
-
CI for Visual C++ 6
Sep 18, 2021Some time ago, I thought of hacking on some really old C/C++ code I had written. I have a VirtualBox image running Windows 2000 and Visual Studio 6 (yes, that old). However, I also wanted to be able to run the code in modern Visual Studio 2019. Verifying that I haven’t broken anything means I would have to manually build my code on two different IDEs. That’s just boring. Instead, I hacked together a way of running my build for both Visual Studio versions.
-
Playing with TeamCity on Azure
Mar 10, 2018I 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
Dec 30, 2017In 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
Dec 29, 2017In 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
Dec 29, 2017In 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
Dec 29, 2017In this post, I’ll add some automated browser tests using PhantomJS and WebdriverIO.
-
Waiting for the correct version after deployment
Dec 29, 2017In 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
Dec 29, 2017 -
Smoke test for a Docker image
Dec 28, 2017According 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
Dec 27, 2017In 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
Dec 26, 2017In 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
Dec 25, 2017In 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
Dec 20, 2017This 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
Dec 19, 2017I 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
Dec 16, 2017In 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
Dec 9, 2017In 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
Dec 9, 2017In 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
Dec 2, 2017In 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
May 8, 2017An 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
Mar 12, 2017Code 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
Mar 12, 2017Code 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
Sep 2, 2012TeamCity 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.