Continuous Delivery

Continuous integration, delivery pipelines, custom tooling.

  • Terraform secrets part 2 - Randomize it

    Nov 4, 2018

    In a previous post, I used Terraform and Helm to pass the connection string of an Azure CosmosDB database to the service that needs it without storing it anywhere in between. In this post, I’ll do something similar for a PostgreSQL database and beef up the security a bit.

  • Merging Swagger files

    Oct 28, 2018

    Consider the following scenario. You have a few microservices and they’re all developed independently: they don’t share code, they don’t share data and they don’t share schema. They’re all exposing their own REST API. To make things a bit simple, their API is defined in a swagger file.

  • Terraform secrets

    Oct 6, 2018

    Since the beginning of this year, I’ve been using Terraform to manage infrastructure. I use it with both AWS and Azure and so far I haven’t encountered any problems. The documentation is quite good and you get that happy feeling when things just work as expected.

  • CI requirements

    Sep 24, 2018

    There are so many programming languages out there and so many frameworks to choose from. From a continuous integration perspective, I think that there a couple of requirements that one should check before jumping onto something brand new.

  • Deploying with Helm v2.0

    Sep 1, 2018

    In the series with Helm and Continuous Delivery nine months ago, I used helm to deploy the application to the kubernetes cluster. To be able to do that from the CI server, I had to make a workaround. I had punched a hole in the cluster with a NodePort service for Tiller. This allows pretty much anyone to reach Tiller (the server side component of Helm) and interact with it. Great for a demo blog post, but not so great for security.

  • Dockerize the build plan v2.0

    Aug 26, 2018

    Back in 2017, I wrote a series of articles about using Helm for Continuous Delivery. One year later, I want to look back on some things I wrote and offer some alternative solutions. The most interesting thing is about the article CD with Helm part 2: Dockerize the build plan.

  • Flyway migrations and Continuous Delivery

    Aug 25, 2018

    Flyway is a tool that allows you to version your database schema changes. In this post I explain a bit how we use it at work (so far), in the context of automated deployments and GitHub Flow branching model.

  • Private NuGet repository with Sonatype Nexus Repository OSS

    Mar 17, 2018

    In this post, I’m setting up a private NuGet repository using Sonatype Nexus Repository OSS.

  • Playing with TeamCity on Azure

    Mar 10, 2018

    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.

  • Build chains in TeamCity

    Dec 27, 2017

    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

    Dec 26, 2017

    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

    Dec 25, 2017

    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.

  • Fixing root permissions on Docker volume

    Dec 16, 2017

    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

    Dec 9, 2017

    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

    Dec 9, 2017

    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 6: networking interlude

    Dec 3, 2017

    Before we continue with setting up the multiple environments that comprise our DTAP, I’d like to take a break and discuss a bit about networks. This way we can understand better what is going on inside and outside of Kubernetes.

  • CD with Helm part 5: versioned artifacts

    Dec 2, 2017

    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.

  • CD with Helm part 4: Helm Intro

    Nov 27, 2017

    In the previous post we had a first look at Kubernetes and deployed our hello world app on a local cluster using the CLI. The simple commands we used are good enough for a first taste. However, the full power of Kubernetes comes with using configuration files. Helm builds on top of that, taking these configuration files to the next level.

  • CD with Helm part 3: Kubernetes Intro

    Nov 25, 2017

    In the previous posts we took the first steps to dockerize our hello world application. This allows us to run the application on any host, as long as it runs Docker. We also dockerized the build plan, which allows us to use any build server, as long as it runs Docker. Now we’re ready to run the application on production. Where should we run it?

  • CD with Helm part 2: Dockerize the build plan

    Nov 18, 2017

    With Docker, we can package our application in a Docker image and we have the assurance that it will run on any machine that has Docker. We can do the same with our build plan. Dockerizing the build environment means that the only dependency we have on the build server is that it supports Docker. This reduces the amount of work needed to manage the build server and enables teams to be more independent.

  • CD with Helm part 1: Dockerize it

    Nov 15, 2017

    In the previous post, we created the hello world application that we’ll be using. Now it’s time to dockerize the app. Dockerizing means to create a Docker image that can be used to run the app.

  • CD with Helm part 0: hello world app

    Nov 13, 2017

    I’d like to start a tutorial series on how to apply CI/CD principles with tools like Kubernetes and Helm. I’m extremely new in these technologies, so this is a learning exercise for me.

  • CD at scale: the success story of a big rewrite

    May 22, 2017

    Back in March, I gave a presentation at the Continuous Delivery Amsterdam meetup. You can watch the video here. The title is “CD at scale: the success story of a big rewrite”. It’s about how we applied CD in a big project that involved complete rewrite of our storefronts at work.

  • npm login credentials on the CI server

    Jan 28, 2017

    In a previous post, I was discussing a way to publish an npm package to the public npm registry. A big prerequisite for that to work is that you have previously logged in to the CI server in order to authenticate against npm. But we can also fix that manual step and integrate it in the build.

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