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?

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.

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.

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.

What happens when developers get the full freedom to work on the things they want with the tools they want? “Get the best people, give them the best tools and get out of their way”. That should work. The reason it doesn’t, it’s because we haven’t defined what “best” people means.

Submodules is an advanced git feature. It allows you to have a folder inside your repository which serves as a link to a different repository. Working with submodules is more complicated and I haven’t had a real need for it so far. Last week I had to deal with a codebase which was doing heavy usage of submodules, but without a good reason, so I got rid of them.

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.

According to my Google search, ergonomics is the study of people’s efficiency in their working environment. The developer’s working environment consists of the physical world but also the virtual world. In the physical world you desire a quiet office, good desk and chair, proper lighting, the best tools your budget can buy, etc. In the virtual world, you have software tools, IDEs, etc. But when writing code, the working environment also consists of the APIs you code against, as well as the code you have written for yourself.

As a Greek developer, I learned early on the importance of character encodings. But even in the age of Unicode, troubles still exist.

In this post I’m setting up a Jenkins server to be able to package and sign Android packages. This is done on a 64bit PC running Ubuntu 14.04 (trusty).