Spring Data provides an easy way of keeping track who creates and modifies a persistent entity as well as when the action happened by annotating properties with @CreatedBy, @CreatedDate, @LastModifiedBy and @LastModifiedDate. The properties are automatically provided by an implementation of the AuditAware and DateTimeProvider interface. Beside this common auditing information in my current projects some entities require storing auditing-information about crucial state-changes like soft-deletion. Previously we had to fill the properties ourself:
I work with Jenkins Pipeline for three years now and one pain point is proper isolation of shared functionality between pipelines but even steps. In our repository we defined multiple pipelines and some are that large that we share functionality within it. Jenkins offers the possibility to create shared libraries for that purpose. But unfortunately it’s not possible to load it from the same repository. Since many of the changes in the pipeline are related to a change of the shared library it was tedious to match the branches and versions to be backward compatible.
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.
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.