IT Compliance and Build Management

The most important feature that a build management solution can offer to meet IT Compliance audit requirements is the ability to match source code to executables for development builds, testing builds and production builds.  Meister Insight reports on the link between production binaries and matching source code through Build Audit Reporting, Footprinting and Impact Analysis.

The second is the ability to re-build a change to support and emergency release while ensuring that no un-approved source code has been introduced by the emergency build.   And finally, the ability to allow for a separation of the build duties between development and IT Operations is essential.  OpenMake Meister addresses these problems using a very transparent and unique approach. 

Meister Insight Build Audit Reporting vs. Bill of Material Reporting 

Auditing builds is a key requirement for meeting IT compliance.  Some tools that claim to be "build management" solutions will tout the use of a "Bill of Material" report to solve this problem.  What they do not tell you is that the "Bill of Material" report is generated not from their build management solution, but it instead comes from your SCM solution.  A "Bill of Material" report is a listing of all files checked out of the SCM tool and placed in the local build directory.  A "Bill of Material" report does not provide a build audit or a footprint showing what objects  the compilers and linkers actually used when the build executed. 

Auditing Builds can be difficult if you have only the ad hoc scripts to rely on.  Meister solves this problem by managing the builds at the build engine level, such as MSBuild and Ant.  The Build Audit report shows a full listing of the machine configuration during the build as well as a full listing of every artifact called by the compiler and traced by Meister, even when the source code was not found in the SCM repository.    Below is an example of Meister's  Build Audit Reports.  Notice that the file "rt.jar" was not stored in the ClearCase repository, but identified by Meister's deep dependency discovery and build forensics.  This information cannot be supplied in a "Bill of Material" Report. 

Repeatable Builds from Development to Emergency Release

OpenMake Meister can be configured to restrict where source code and library objects are found during the compile process.  This means that a build can be executed that precisley points to the source code that needs to be used in the build.  The use of a dependency directory listing allows for the re-building of the production systems with a carefully managed "delta" directory that contains only the emergency fix.  This provides a full audit trail, prior to the build even running, of what source is to be included in any build at any stage of the lifecycle. 

Separating Duties between development and IT Operations

With Meister, full control of the build process can be handed to the Production Control or SCM teams, without the heavy load of thousands of make and ant scripts.  All details of builds can be easily reviewed such as turning off debug flags, turning on optimization flags and the use of approved source code and third party libraries to ensure production compatibility.  This critical data is hidden in ad hoc scripts and is far from transparent. With Meister, the tools for managing these components are provided to you outside of the manual scripts that developers write to support their development builds.  This information is stored on the community developed knowledge base and is exposed to all members of the development and IT operations teams.  With this information, the IT operations team can easily rebuild any application that the development team built.