When you look at how a given organization develops software over time, it’s not uncommon to spot evolutionary patterns that mimic what we see in nature. Particularly where micro services are involved, you might well be able to deduce which services came first, and which were developed later in time, by looking at various subtle variations in project structure, tools, dependencies, build pipelines and deployment descriptors. Later services copy elements from the initial template services, apply variations to fit their needs, and successful variations are again used in future services, or even applied in the original template services.

Variations from service to service are essential to maintaining a vibrant engineering culture, with room for experimentation within appropriate boundaries. Over time however, all the subtle variations can make it harder to reason across services, particularly when you want to apply broader changes.

In this blogpost I’ll outline, and provide various samples of, how I harmonize such diverse micro service landscapes, and the scripts I use to reduce the accidental complexity in maintaining the various variations.

The Maven Release plugin allows you to easily craft releases of your own libraries, to share code between projects. When combined with Semantic Versioning you can communicate clearly to your library users which changes are minor, or potentially breaking. The plugin will trim off the -SNAPSHOT suffix of your artifact version, run through all the stages to create your build artifacts, and push those artifacts to a remote registry such as Artifactory. It will also push a Git tag to your code repository, as well as increment your artifact version to prepare for further development.

This blogpost will run you through the steps to authenticate with both GitLab and Artifactory when running a Maven Release from GitLab CI.

As a consultant I find myself alternating between GitLab and GitHub about once a year, depending on the assignment. While I like GitLab a lot, there’s one thing I had sorely missed whenever I switch back from GitHub: Dependabot. Dependabot scans your project dependencies, and creates merge requests whenever updates are found. This provides you with an easy way to keep up to date on dependencies, and notifies you early if there are any incompatibilities.

Even though there are alternatives such as snyk.io and even GitLab’s own Dependency Scanning, those don’t always support enterprise or partner installations of GitLab, require GitLab Ultimate, or don’t support the full range of package managers that Dependabot supports.

Luckily though, there’s now a Dependabot for GitLab project. This project is based on the same Open Source Dependabot Core, so you can get the exact same automated dependency updates on both platforms.

In this blogpost I’ll walk you through how you can quickly roll out Dependabot on an existing GitLab installation, so you can start updating your dependencies automatically.

When you maintain a large Java project for a longer period, the moments where you’re finally able to remove unused code can be very satisfying. No more upkeep, library version migrations or dark corners to maintain, for code that’s no longer being used. But finding out which parts of the code base can be removed can be a challenge, and tooling in this space seems not to have kept pace with recent development practices in Java. In this post we’ll outline an approach to find unreferenced code with ArchUnit, which allows you to iteratively detect & delete unused code from your Java projects.

As more and more teams and companies adopt Apache Kafka, you can find yourself wanting to share data via replication of one or more topics from one cluster to another. While replication of an entire cluster with all of it’s topics as a means of failover can be achieved with tools such as Mirror Maker and Confluent Replicator, for replication of a single topic there are fewer examples. Even more so when the source topic is serialized with Avro, with the schema stored in Confluent Schema Registry.

Here we present a minimal consumer that replicates a single Avro serialized Kafka topic from one cluster to another, while ensuring (only) the necessary Avro schema is registered in the target cluster Schema Registry.

The December 2019 release of Apache Kafka 2.4.0 saw usability improvements in TopologyTestDriver, with the addition of new TestInputTopic and TestOutputTopic classes. These offer typesafe methods to easily produce and consume messages for your Kafka Streams tests. In this post we’ll explore these new classes in the context of Avro messages, which requires a small trick to get working.

Adding Spring Security to an existing application can be quite a daunting prospect. Merely adding the required dependencies to your project sets off a chain of events which can break your application and tests.

Maybe you’re suddenly shown a login prompt which expects a generated password logged on startup.
Maybe your tests now get the dreaded 401 Unauthorized, or a subsequently a 403 Forbidden.
Maybe you get a ClassCastException when trying to use your Authentication#getPrincipal().
Either way, this post is here to help!

When combined with Spring Security 5.2+ and an OpenID Provider such as Keycloak, one can rapidly setup and secure Spring Cloud Gateway for OAuth2 resource servers.

We consider this combination a promising standards-based gateway solution, with desirable characteristics such as hiding tokens from the client, while keeping complexity to a minimum.

You might have a need for a custom access decision voter when security decisions are made based on who is accessing what domain object. Luckily Spring Security has quite a few options for such implement such access control list (ACL) constraints.

This post is part of a series of blog posts on Spring Security; the code can be found on GitHub.

Often you’ll find access decisions move beyond simplistic ownership or having a certain role, for instance when users share domain objects with other users. In such cases it’s common to separate permission to view an instance from being able to make changes to the same instance. When your access rules are relatively straightforward, Spring Security offers the PermissionEvaluator interface to secure instance access.

This post is part of a series of blog posts on Spring Security; the code can be found on GitHub.

Spring Data repositories allow you to easily query your entities with method names such as findByUserName(String name). However, it can get cumbersome to always retrieve, pass and match on the active user. Luckily Spring Security integrates well with Spring Data to minimize the overhead.

This post is part of a series of blog posts on Spring Security; the code can be found on GitHub.

Spring Data enables you track who modified an entity and when, with just a few annotations. When combined with Spring Security, you can set this metadata based on the active user.

This post is part of a series of blog posts on Spring Security; the code can be found on GitHub.