Bugs in recursion

Lets first talk about Day 24 – “Planet of Discord”. This puzzle reminded me of the fascinating Conway’s Game of Life that dates back to 1970.

Part one was about finding a repeating pattern in the ever-changing constellation of bugs. Now my loop detector that I had prepared earlier on day 12 to solve “The N-Body Problem” came in handy. So this part was quickly resolved. So let’s continue with the typical more advanced part.

In an ideal continuous integration pipeline different levels of testing are involved. Individual software modules are typically validated through unit tests, whereas aggregates of software modules are validated through integration tests. When a continuous integration build tool like Jenkins is used it is natural to define different build steps, each step returning feedback and generating test reports and trend charts for a specific level of testing.

FitNesse is a lightweight testing framework that is meant to implement integration testing in a highly collaborative way, which makes it very suitable to be used within agile software projects. With Jenkins and Maven it is quite easy to trigger the execution of FitNesse integration tests automatically. When properly configured and bootstrapped, Jenkins can treat the FitNesse test results in a very similar way as it treats regular JUnit test results.Read more →

Conceptually Maven distinguishes between snapshot versions and release versions. For top-level Maven projects that are continuously integrated it is unnatural to make this distinction. Especially when having some kind of continuous deployment implemented, it doesn’t make much sense to create and deploy artifacts with a snapshot version at all. Snapshot versions cannot be linked to a unique revision in a version control system and can have ambiguous snapshot dependencies. That is why such artifacts shouldn’t get deployed to a live environment.

Although it is possible to embed version control revision information as metadata into artifacts, for instance via the Manifest file, it is recommended to avoid snapshot versions at all. Only unique release versions should be continuously created and deployed instead. In fact, every single revision can be considered to be a release as will be shown below.

In order to implement this concept of continuous releasing the revision number needs to be made part of the artifact version.Read more →

The essence of creating a pipeline is breaking up a single build process in smaller steps, each having its own responsibility. In this way faster and more specific feedback can be returned. Lets define a true pipeline as being a pipeline that is strictly associated with a single revision within a version control system. This makes sense as ideally we want the build server to return full and accurate feedback for each single revision.

As new revisions can be committed any time it is natural that multiple pipelines actually get executed next to each other. If needed it is even possible to allow concurrent executions of the same build step for different pipelines. However some measurements need to be taken in order to guarantee that all steps executed within one pipeline are actually based on the same revision.

Within a Jenkins build server instance it is possible to create a true pipeline for a Maven based project quite easily and in an efficient way. But in order to establish one we need some extra Jenkins plugins to be provisioned and configured properly as we will see below.Read more →