My opinion on the « Best-so-far » architecture

This post is not to talk about something I have made, but to talk about something I have lived with.

First, what is it ?

« Best-so-far » (or BSF) means to work with the latest pieces of software each and every day.

It relies on several IT infrastructure components : a software factory, a source code management, a build scheduler and an integration monitoring.

The software factory

It is a software whose role is to collect all the libraries across a company and to release the binaries for the employees, partners and customers.
It can be implemented by a storage access on a platform, or a machine, or a shared drive.
It also contains archived binaries of the previous versions of each component (for redundancy purposes), but is mostly focused on providing the latest framework chunks, with the latest features and the latest bugfixes.
All of these binaries can be used dynamically to build and release other binaries, and so on…

The SCM (source code management)

It is a set of tools to optimize the branches code management in a team (allowing several users to commit on the same project with the least possible conflicts).
Most of the teams appreciate to use standard tools like git, svn, mercurial, cvs, ClearCase, perforce, bazaar. Some others wanted to create their own scm tool (thinking of adl, http://www.maruf.ca/files/caadoc/CAAWsmQuickRefs/).
It is often managed by having one single integration branch where every team member has to merge in after finishing a task.

The build scheduler

It has two modules : a batch whose role is to execute some actions on some files, and an UI to help the users to administrate the jobs to be run each day.
It uses the latest version from « the SCM » to build it and install the packages on « The software factory ». It also contains some details about the errors found while trying to build or release something.

The integration monitoring

It is a UI tool with red and green lights to inform all of the employees that a build failed or suceeded. The most common standard software existing are Jenkins, Bamboo, CircleCI, CruiseControl, or Drone. Some companies prefer to create their own, with better or worse usability (thinking of ReleaseWork). The integration monitoring collects data from « the SCM », « the build scheduler » and « The software factory » to gives an insight of what is working and what is not.

2. Why do we use it ?

The thinking behind this implementation is to wonder how different dev teams can work across a company on the same product without suffering from waiting for each other. The expectation is to « break the silos », and to get the teams in a rhythm.
Letting a dev team beneath another in terms of software dependencies will help the dependent team to update the subsequent code as soon as possible. For example, a team building a polygon extrusion lib will update every day the dependencies to benefit from the work of the maths library. As a consequence, each lib will get the « Best-so-far » state of each lib when it comes to releasing to the employees, partners, customers. And so on…

3. Is it good ? I don’t know. Is it easy ? NO, it is NOT.

This is where I will express opinions of that practice.
I have worked for a company using that practice since birth. The « break the silos » fantasy is far away from reality.
I have never worked in such a partitioned way of thinking company.
The thing that turned wrong is that the work streams who managed the frameworks were separated from those who managed the BSF architecture.
As a result, a lot of improvements in this architecture landed in a total contradiction of the dev teams practices :
– The team handling the integration monitoring is pressured to release the build. The team members try to identify who is late by seeing who has worked on « the SCM ». They identify some culprits, without any consideration about the team responsibility. This team is not appreciated because it is seen like a toilet lady to the developers. « Have you fixed your issue ? The next release must be submitted by noon. I won’t leave the office until it is fixed and working »
– The team working for « the SCM » delivers some features that are useful for some users. Not all. All the other teams are forced to work on ONE SCM that does not fit their needs (if the company uses cvs instead of git, no one is allowed to work with git, and the Internet proxy must forbid any request sent to github or bitbucket).
– « The software factory » uses a common repository which can work with any kind of project lifecycle tool. You must be able to package Java classes, C++ projects or DSL scripts at once and to send them on the same storage access. Do we know a PL tool which is working on anything ? Yes, but it is really primitive. « make » can do the job. That was the most awkard answer I could ever think of. To understand it, just imagine that I work on a Java project but I have to build and to release my software using the « make » C++ tool. And last that not least, just imagine that the choosen storage can be as clever as a Windows share (that is it, samba share) !
– « The build scheduler » is maybe the tool which is the least risky to maintain, because the responsibility lies on the dev teams. It basically consists in launching some tasks and display the logs. Here, no specific tool to an environment. Windows shells are launched, that is all. Neither any JUnit parsing, nor any performance report.

Last but not least,

what is the most disturbing item for developers in the BSF way ?

→ You are not going to believe it, but it is the principle itself. Working on snapshots itself is at once a good, and a bad practice. Imagine that your company makes yogurts. It wants to rely on a single milk provider, which is considered as the most talented milk provider locally. « We don’t need fallback providers, we use the best one, the best-so-far ». Now imagine that a brutal and unexpected disease cause the death of the whole livestock in one night. How the company is going to adapt to that situation ?
So does a company with a « Best-so-far » architecture. You cannot work with any other provider, and you cannot work with older but functional versions of the frameworks.
The activity stops in the hope that the situation gets better in the future. In my opinion, that explains why my previous company decided to release one product version per year at most.