Introduction

As most software shops, whenever a new application popped up the typical process was to open a ticket to the Build Engineering team to get their branches created (we still worked with a centralized version control system, which meant that every branch had to be pre-approved), Jenkins jobs created and a few shell scripts which ran the actual commands.

The application’s lifecycle also had to fulfill the regulatory requirements, which meant many meetings to ensure everyone was on the same page – getting an application from Proof of Concept to production took an extraordinary amount of time

jenkins

The problem

While already struggling to keep up with the legacy, we were told that we were switching to microservices and about 200 new applications chucknorriswere about to crop up. This meant that the flood of requests was no longer serviceable and the service model had to be rethought.

A big effort was spent on reducing technical debt (standardize branch naming, creating generic build and deployment scripts, …) but the requests kept coming at a faster pace than they were being answered, the new applications still had too many exceptions and there wasn’t enough time to update the old applications to the new model. The pressure in getting it done on time meant that quality started to suffer and both our developers as well as our build engineers were getting frustrated.

The only option was to turn the tables around and we had to transform the build and deployment platform into a service.

“Don’t call us, we’ll call you.”

In software development, there is a relatively known pattern called “Inversion of Control”. The most typical use of that pattern, even if it’s not very obvious at first, is when writing a plugin.

The normal flow when writing a “normal Java application” is you import a set of libraries and your own software tells each of those methods when and how they will be invoked. In contrast, when writing an Eclipse plugin, the IDE itself determines the flow of execution and will call the plugin at the appropriate time (when needed). This means that the plugin isn’t in charge of execution, Eclipse is, and Eclipse will take the liberty of making use of the plugin when it deems necessary.

There is a very decent Wikipedia article on the subject, but the most important part is where it mentions the Hollywood Principle. We had callmemaybe
that “lightbulb” moment – why not apply software patterns into the organization itself?

For the actual implementation, we just looked outside. Taking inspiration from platforms such as travis.ci, we built our own file format customized for our specific environment (some proof of concept code can be found in here). It’s now as simple as creating a yaml file with a few values and the build system will automatically detect the file when the code is pushed into the main repository.

Standing on the shoulders of giants

As a software engineer, nothing gives me more pride than being able to apply principles of software development back into the organization. It might require an open mind and a little “thinking out of the box”, but the same way real world experiences and patterns (such as Lean) may be applied to software development, there is definitely room for cross-pollination.