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 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.
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. Our situation is the following: You want to execute a test which starts your backend application and fires against it from the outside.
Marcus Held