Quantcast
Channel: ubuntu – Ayr
Viewing all articles
Browse latest Browse all 4

Blinking lights when the build status change

$
0
0

In Agile methodologies, we learn as good practice to start giving visibility in more efficient ways besides using the typical e-mail method.

For example, a physical kanban board is more suitable for communicating as a digital version. As everyone will see the progress and obstacles as they get close to a team (and, of course, the board should be near the team). The digital version is not bad, but it needs a lot more self-discipline than the physical one.

I will talk more about good practices to give visibility to digital kanbans over the next posts. Today I want to tell a little about how to do this with the continuous integration process.

Throughout continuous integration, we have a distinct scenario because typically only the development team members follow this process, where it is quite common:

  • The build agent starts to send e-mails when someone breaks tests;
  • Developers do not open the mailbox very often throughout the day. Usually, they are focused on making code with due heroic dates that the dev team stipulated themselves (or at least agreed);
  • When devs start to being disturbed by the build agent, they move the related emails to a label and skip the inbox;
  • These emails never will be seen again.

What if we create a physical way to communicate these changes? As the physical kanban, everyone would know what’s going on when they approach the team workspace, instantly.

Here’re some interesting examples:

ci-light01

ci-light02

ci-light03

However, before you start learning basic electronics and buying a bunch of stuff, I would like to teach you a very simple way to get started.

Start small, as people start enjoying it (especially people who sponsor the project), you should starting building complete lights for all your build pipeline.

For my example, I will use this light:

http://www.blynclight.com/products/blync-light?variant=328886579

You will need a machine with a USB port and connectivity to your local network. You could use a Raspberry Pi or a Linux machine that is close to the team.

That parts could be more expensive than buy an Arduino and some lights, however, you will only need 5 minutes to make it work. As the working hours of your team should be more expensive, this will be the cheapest way to get started as start from scratch with the electronic components.

The fun part about this light is a NodeJS library:

https://www.npmjs.com/package/blync

Some examples of usage (finally):

Ayrton, what is the build status?

A video posted by Ayrton Araújo (@ayrtonfreeman) on

How does it work?

First you need add a user to plugdev group and create the 90-libusb.rules inside this path:

/etc/udev/rules.d/

Reload udev rules:

sudo udevadm control --reload-rules

You could test if everything is working fine with the light-cli.coffee:

coffee light-cli.coffee green
coffee light-cli.coffee red
coffee light-cli.coffee white
coffee light-cli.coffee magenta
coffee light-cli.coffee blue
coffee light-cli.coffee cyan 
coffee light-cli.coffee yellow 
coffee light-cli.coffee off

Expose a REST API:

coffee light-api.coffee

You could use forever to keep the API working after system restart.

Getting the things real:

When a build starts, you could call in the job:

curl http://lightmachineIPorDOMAIN:3333/api/v0/yellow

When a build succeed, you could call:

curl http://lightmachineIPorDOMAIN:3333/api/v0/green

If if fails:

curl http://lightmachineIPorDOMAIN:3333/api/v0/red

Now you can use your imagination. I’m color blind. 😀


Viewing all articles
Browse latest Browse all 4

Trending Articles