A build light indicator is a simple visual indicator used in

Agile software development Agile software development is an umbrella term for approaches to software development, developing software that reflect the values and principles agreed upon by ''The Agile Alliance'', a group of 17 software practitioners, in 2001. As documented ...

to inform a team of software developers about the current status of their project. The actual object used can vary from a

pressure gauge Pressure measurement is the measurement of an applied force by a fluid (liquid or gas) on a surface. Pressure is typically measured in units of force per unit of surface area. Many techniques have been developed for the measurement of press ...

to a lava lamp, but its purpose remains the same: to quickly communicate whether a software process (such as a 'build') is successful or not.

History

The build light indicator originated from CruiseControl, a continuous integration tool created by employees of ThoughtWorks. Though it primarily functioned as a web page dashboard that could report more detailed information about a build, the

software Software consists of computer programs that instruct the Execution (computing), execution of a computer. Software also includes design documents and specifications. The history of software is closely tied to the development of digital comput ...

could also control external devices for simpler reporting.

Use

The traditional use of a build light is to determine the success of a

software build A software build is the process of converting source code files into standalone artifact (software development), software artifact(s) that can be run on a computer, or the result of doing so. In software production, builds optimize software for pe ...

in a

continuous integration Continuous integration (CI) is the practice of integrating source code changes frequently and ensuring that the integrated codebase is in a workable state. Typically, developers Merge (version control), merge changes to an Branching (revisio ...

(CI) system. Different development teams have used different indicators, but a popular choice is the green and red lava lamp – green when the build is successful and red when something is wrong. Build lights may even be remotely accessible through a

webcam A webcam is a video camera which is designed to record or stream to a computer or computer network. They are primarily used in Videotelephony, video telephony, live streaming and social media, and Closed-circuit television, security. Webcams can b ...

or other means. However, since many of the tests in busy development offices will always be in a state of re-test after the latest changes, some indicators have a three state display – ''pass'', ''fail'' and ''being re-tested'', to provide a more nuanced indicator for staff and managers.

Beyond single indicators

With the growth from continuous integration to continuous testing, the number of simultaneous build targets may increase, even for a single codebase. As well as a simple build (i.e. compilation) target, there will now be

unit testing Unit testing, component or module testing, is a form of software testing by which isolated source code is tested to validate expected behavior. Unit testing describes tests that are run at the unit-level to contrast testing at the Integration ...

and various levels of system testing. As extensive tests are slow and it is desirable to keep fast tests running on a fast cycle to give rapid feedback to the developers, the number of build targets may increase to fifty or more. This is too many to show with a simple lava lamp display. Integration servers like Jenkins offer a web-accessible dashboard page and this may be permanently displayed on a wall-mounted flat screen monitor instead. The details of such a dashboard are too small to read across an office, but the colour changes present an overall picture of status. With a methodology of continuous test-driven development, new tests are released before working code is developed to pass them. There is thus a period when some tests are known, and indeed ''required'' to be failing. Failing tests are needed as they demonstrate the capability of the new tests to detect the situation of concern. Once the new code is developed and working, these tests begin to pass. A continuous testing environment into which new tests are released before their code thus requires two build targets: one tracks the latest code and tests, the other 'release candidate' is only updated in increments when all tests are fulfilled by passing code. For the build indicator this also implies that one of those targets will frequently be shown as "failing" its tests. As this anticipated "failure" would be misleading to naive watchers, the build indicator should either hide it or present it distinctly. Where several code targets, such as old product versions, are still supported for CI, but are not under such active development, then a complete dashboard may become dominated by "stale" targets that rarely change. In this case a selected dashboard may be more appropriate, where only those targets that are either failing, or are recently active, are displayed. The full dashboard is available to developer's desktops, but the wall display shows only the significant highlights. Such dashboards are often coded locally by screen-scraping the main dashboard and applying relevant local filters to it, according to local needs. One drawback to a dynamic filtered dashboard, compared to a static dashboard, is that the position of icons for a particular target may shift on the screen, making it hard to read from across an office. In this case, distinctive icons, such as a product logo, may be displayed rather than simple colour blocks.

References

{{Reflist, colwidth=35em Agile software development