Continuous reporting

Continuous integration should not carry the burden of reporting since this breaks the single responsibility principle.

At our current project we have six to ten souls constantly pushing changes to the source version control every day which necessarily causes some builds to fail. Since code auditing reports are run in the same CI server’s job they get lacerated by these fails and drops the continuous line report causing statistics to be damaged -specially when it takes more than the next integration attempt to fix the problem.

Finding our statistics broken due to code that failed to integrate automatically smells like the job has more than one purpose, and as code, it shouldn’t. So, the obvious solution is to refactor applying a variation of extract class, called extract job. The mechanics are very simple, remove from the job’s goals the site goal, living the install goal alone, and rename if necessary. Then, add a new job which will run only if the former has completed successfully, even if unstable, with the site goal.

Once responsibilities are separated you’ll enjoy of statistics that aren’t harmed by failing integration jobs.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s