Posts tagged with continuous integration

• CI for Visual C++ 6

  Sep 18, 2021

  Some 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.

• GitLab recipes

  Feb 14, 2020

  Another year, another CI tool. Due to work changes, I’m exploring GitLab for the first time. Here are some basic snippets I used recently and my first impression of the tool.

• 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.

• Dockerize the build plan v2.0

  Aug 26, 2018

  Back in 2017, I wrote a series of articles about using Helm for Continuous Deployment. 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.

• 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 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.

• On git branching models

  Sep 23, 2017

  Usually, when you work with a version control system like git, development happens in multiple branches. It’s funny to see people’s faces when you tell them that the author of Continuous Delivery, Dave Farley, advocates “no branches”. I had that same surprised face myself the first time I heard that concept. But, so far, I haven’t really worked somewhere where no branches were used.

• 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.

• Fun project: HipChat integration with AWS Lambda

  Apr 12, 2017

  TL;DR: I made a hobby project that gets the pull requests that still need code reviews from Bitbucket and posts a notification message on HipChat to inform developers. It’s written in JavaScript (nodeJS). Travis CI automatically deploys it to AWS as a Lambda function. AWS CloudWatch is used to trigger the function hourly.

• Publishing my first Maven package with Travis

  Mar 29, 2017

  A little bit more than a month ago, I created an improved Maven archetype project. Similar to the default quickstart archetype, but for Java 8 and with recent jUnit dependency. In order for someone to use it, they’d have to clone the repo, as I had not published it in Maven. After a bit of studying, I figured out what is needed to make the package public. More importantly, I implemented the process in Travis, so that a new version gets published automatically.

• 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.

• Automatic versioning of npm packages

  Aug 20, 2016

  When you are the maintainer of an npm package, you need to do some administrative work around its versioning. When you release a new version, you need to make sure the package.json is updated, the package is correctly uploaded to npm registry, the git repository is tagged accordingly and so on. You shouldn’t be doing these things manually if you can automate them.

• Functional Testing - Dealing with failed tests

  Jul 23, 2016

  In the previous post, we wrote some functional tests and we encountered our first failing test. Let’s see how we can go about investigating these failures, both on a developer machine and during continuous integration.

• JavaScript Static Code Analysis, part 2

  Feb 13, 2016

  In the previous post, I talked about static code analysis and how it can be useful in enforcing and maintaining a consistent coding style, but also in catching subtle bugs and code smells. The focus was on two tools, jscs and jshint. What other tools and techniques can you use?

• JavaScript Static Code Analysis

  Feb 7, 2016

  Reading code is hard. It’s often difficult to understand what the developer was trying to express when he was writing that function. If you keep your old projects around, go ahead and open them. You’ll probably struggle to read even your own code. It might even look as if somebody else wrote it.

• Versioning Deployed Web Applications

  Nov 9, 2013

  In this post, I’m going to discuss the setup I have for deploying an ASP.NET application in Linux.