All the code for this blog post is present in the demo GitLab repo. It has GitLab CI Config and also a demo pipeline which shows how it runs. Recently I wrote a blog post about integration tests and some ways to do it. One of the ways talks about using GitLab CI/CD’s Services feature. I realized it deserves a separate blog post, so here it is :D This blog post is meant to create awareness around this feature of GitLab CI/CD and also give a basic introduction.

Today I learned a new thing when someone asked something - “We have two services in docker compose file. How to run one service optionally based on some feature toggle like environment variable or command line option? Is it possible to do this in a single Docker Compose file?” TLDR One way is to control the replica count. If replica count is 0, then it means no instance of the service is running.

TDLR; Following my blog post about Kubernetes DaemonSets, I’m writing this post to talk about Kubernetes Jobs and CronJobs :D In this blog post we will see what’s the use case for Kubernetes Jobs and CronJobs. We try to solve the same use case without these resources, and then see how it compares to Kubernetes Jobs and CronJobs. Longer Version Let’s start with a requirement first “I want to be able to run a task and know if it was successfully completed or not”

Testcontainers is a library that helps you run Docker containers to run components for your integration tests. There’s a Java library and there are libraries in other languages too. I wrote a part 1 blog post about integration tests and an introduction to Testcontainers. It didn’t have any code examples though. A lot of the docs on the websites are really good for you to get started. I’m still writing this and upcoming posts to give a bit more details based on the experience from using Testcontainers in our project.

Note: This post does not cover code examples for Testcontainers. That will be part of part 2. TLDR Sometimes you have some external components in your system - like a data store or cache or message queue and similar. Some examples of external components are - Postgres, Redis, Kafka, RabbitMQ. You might be writing and running integration tests against actual components to ensure the integration works. To run these actual components - you could do it in many ways.

Note: This article assumes you know about Kubernetes basics like Pods and that Pods run on nodes, and that Kubernetes works in a cluster architecture with usually more than one node. TLDR; DaemonSet is a specific name of a resource in Kubernetes in case you haven’t heard of it. I like to call it as “run everywhere thing” when I introduce it to newbies. If you need to run a program / software in every node of the Kubernetes cluster, then this article might be of interest to you.

TLDR Dead code is just unnecessary code that’s lying around. You don’t need it, nobody needs it. Just remove it and make your lives easier by removing unnecessary things :) If you want to take it up to the next level, use automated tools to detect some kinds of dead code to make your lives more easier ;) Use the same automated tools to fail Continuous Integration pipelines when dead code is detected.

TLDR Just get started with that one line in your draft. Just write. Write as a habit! :) Longer version Disclaimer - I have read very few things about writing blogs. I have written only a few blog posts and I’m not some famous blogger (yet? :P). These are just my thoughts / opinions. I have also heard a bit of recommendations and learned from others, so it’s also reiterating some of those recommendations.

TLDR; Try Jabba, an Open Source Tool for managing multiple Java versions in your system. It’s written in Golang. It has been inspired by nvm which manages Node versions Video Version Before going into the post, if you prefer videos over blogs, you can checkout this YouTube video, which has the same information as this blog post. This blog post will be mostly the text version of the video :)

In my current project, we work with Spring Boot. Recently, I was writing a Data Transfer Object (DTO) and we also had to add validations to the fields. Usually, while doing this, we also add tests to ensure that in the future we don’t remove or change the validations by mistake and instead it’s more intentional as we have to also change the tests. Some more context - we are writing Web APIs.