Code-Held

In this post we’ll go through an example application and see which methods and principles we can apply to build a robust application that is easy to maintain, extend, understand and use. In general, this is a subject with a much larger scope than a simple blog post can provide, so the content is neither complete nor exhaustive, but a selection of topics that I visited recently. We use an arbitrary business case where we can buy and sell resources on a market. Our example is implemented with Java using Spring Shell for a simple frontend representation. However, please keep in mind, even if technology you use operates differently, the principles stated in this post remain true for every language. Without further hesitation let’s start with an example of how our application works:

At some point it hits everyone. Your precious work of several hours is vanished because of a hardware failure. For that the industry came up with several solutions like the idea of version control systems. But recently I was dumb enough to not do any commit for several hours - just to leave the history clean. Big mistake… But did you think about automating that? How about committing every couple of minutes automatically? In this post I’ll explain this - on the first sight - weird workflow.

In my current project I focus on the development of a highly available, scalable system that can handle millions of players worldwide. In order to test and ensure that this is actually the case we need to do regular performance and integration tests. While - for a long time - I explicitly separated both, I choose a new direction in this project by writing the JMeter performance test in a way that it can be used as an integration test as well.

Another month, another git alias (But don’t think that this will become a regularity now ;-) ). I had the issue that I lost track of the branches that were already in master a couple of times on one of my projects and after a while I had a lot of unnecessary jobs in Jenkins because we use the Jenkins multibranch plugin. So I sat down and created a git alias that does the cleanup for you with a bit of user-friendly output.

Usually you have a lot of “intermediate” commits while developing on a feature branch like WIP, Review changes, Some cleanup, Fix jenkins. These commits are neither atomic nor does it help to read them in the history. They purely serve the purpose to persist the current work, trigger another build on your buildmachine or doing some fixes you discovered while testing. So before I rebase my changes to master I’d like to squash all commits that i’ve done to a single one. Usually I use interactive rebase for this purpose but since I need to actively tell every commit that I want to squash it I found it tedious. Also its easier, most of the time, to rebase onto master since you only apply conflicting changes to the end-result of your work without the intermediate steps you had to take. So I came up with my own git alias that solves this for me. Introducing: git squash <Commit/Branch> <Message>

A common problem when doing end-to-end tests is colliding ports on you buildmachine with parallel execution. With the technology stack of Docker, Jenkins and Gradle I’ll demonstrate one solution I use in my current project to start the backend with a random port and use it in the test execution afterwards.