Changes between Version 2 and Version 3 of White Paper

Timestamp:

Nov 25, 2005, 5:46:36 PM (18 years ago)

Author:

Bruce Christensen <trac@…>

Comment:

Minor spelling/grammar fixes

White Paper

@@ -25 +25 @@
 == Main Objectives ==
 
-The goal of this work is to design and implementat of a distributed system for automated builds and continuous integration that allows the central collection and storage of software metrics generated during the build. The information collected this way needs to be structured and available in a machine-readable format, so that it can 
-be analyzed, aggregated/correlated and presented after the build itself has completed. The system is required to meet the constraint of neutrality towards programming languages and tool chains: at its core, it must not assume that any particular language or build tool is in use by a project. Rather, it should provide a generic framework for the execution of builds, and collection of data from builds, and for persisting this information in a central location to make it available for various kinds of reports. The system needs be extensible to support various specific languages and tool-chains in a meaningful manner.
+The goal of this work is to design and implement a distributed system for automated builds and continuous integration that allows the central collection and storage of software metrics generated during the build. The information collected this way needs to be structured and available in a machine-readable format, so that it can be analyzed, aggregated/correlated and presented after the build itself has completed. The system is required to meet the constraint of neutrality towards programming languages and tool chains: at its core, it must not assume that any particular language or build tool is in use by a project. Rather, it should provide a generic framework for the execution of builds, and collection of data from builds, and for persisting this information in a central location to make it available for various kinds of reports. The system needs be extensible to support various specific languages and tool-chains in a meaningful manner.
 
 This system will be built on top of [http://trac.edgewall.com/ Trac], a simple web-based application for managing software development projects, written in [http://www.python.org/ Python]. Trac provides a view of the projects version control repository, a wiki for collaborative documentation and an issue tracker for managing defects and tasks. All of this is held together by a simple wiki syntax that can be used everywhere for linking to any kind of object (for example wiki pages, changesets and tickets), a “timeline” view that shows recent activity in all of those areas, and a generic search facility. 
@@ -34 +33 @@
 The design of the system will be based on distributed CI systems such as [http://www.mozilla.org/tinderbox.html Tinderbox] and [http://buildbot.sourceforge.net/ BuildBot]: a central build orchestrator (or build master) is responsible for the coordination of several build slaves that do the actual work of executing builds. The orchestrator is a daemon that knows what to build and how to build it; it provides this knowledge as a build recipe to the build slaves, which report their status and results back to the orchestrator after the build – or parts of the build – have completed.
 
-A [wiki:BuildRecipes build recipe] is declarative; a configuration file determining what commands to execute, and where certain artificacts and reports can be found after a command has completed.
+A [wiki:BuildRecipes build recipe] is declarative; a configuration file determines what commands to execute, and where certain artifacts and reports can be found after a command has completed.
 
 [[Image(layers.png)]]
@@ -42 +41 @@
  Data conversion:: There is a large variety of different tools that generate data in different formats, including the build system itself, as well as any additional tools integrated with the build, such as unit testing frameworks, code coverage analyzers or style checkers. The data produced by these tools needs to parsed and converted so that it can be handled appropriately. This conversion is done by both the build slave (mainly to prepare the data for transmission to the master) and by the build master (to convert the data into a format suitable for storage and analysis.) 
 
- Data collection:: The build master collects all the data reported back by the individual build slaves and writes that data to some kind of persistent store, for example a relational database. The way it is stored needs to be oriented towards the requirements of providing flexible reporting capabilities. All collected data is always tagged with the revision against which the build was made so that it ́s possible to correlate the information with other data such as repository activitity.
+ Data collection:: The build master collects all the data reported back by the individual build slaves and writes that data to some kind of persistent store, for example a relational database. The way it is stored needs to be oriented towards the requirements of providing flexible reporting capabilities. All collected data is always tagged with the revision against which the build was made so that it's possible to correlate the information with other data such as repository activitity.
 
  Data presentation:: Presentation of the collected data is handled by a Trac plug-in. This plug-in has access to the database maintained by the build master and provides means to visualize the data or make it otherwise accessible through the web interface. Trac itself will be extended to expose additional extension points where necessary, for example to integrate software metrics and stastistics in various places, such as the timeline and the repository browser.