Binary Management
The application build process is the final piece of the IT compliance puzzle for distributed teams writing Java and Windows applications. Ad hoc build scripts are the roadblock preventing Java and Windows developers from moving forward. Ad hoc build scripts are the most common methods used to manage Java and Windows application builds, yet they don't meet the four essential requirements of IT governance standards:
- Traceability
- Auditability
- Validation
- Separation of workflow duties
To mature the Java and Windows development process, a method for managing binaries must be implemented. Managing binaries is a core component of the build-to-release process. If you cannot manage the process of creating binaries, then your build-to-release process becomes invalid. Similar to SCM, binary management lets you track, trace, and manage the details about the build. Your process of managing binaries lets you control what compile-and-link flags were used to build the deployable objects, restrict the use of debug flags used in production builds, and control the location and version of the compiler and linker used in the build. A wobble in any of these areas can cause drastic differences in build results.
There are four core competencies to a solid binary management process:
- Reduce your dependency on ad hoc build scripts. Both mainframe and legacy UNIX developers had to face this core requirement. At one time, mainframe developers managed their own compile JCL. They would release applications into production by running their compile JCL and creating load libraries right into production. Legacy UNIX developers wrote hundreds of make scripts until they realized that a single well-managed makefile written in a commercial make language such as IBM ClearMake offered them a method of standardizing the creation of binaries across diverse teams. Java developers are overly dependent on open-source languages to perform this critical step. Windows developers often rely on point-and-click processes inside Visual Studio to create the binaries. Neither method allows for a repeatable process that can be turned over to a production control team. As long as you rely on ad hoc build scripts, you will never meet the separation-of-duties requirement.
- Never take binaries from a developer or execute a developer's build scripts. The only reason production control would rely on developers to create binaries or to provide scripts to create the binaries is because there is no repeatable method between development and production. Therefore, all of production control must be done in the development environment. The requirement to never take binaries from a developer is clear, but understanding why production control should not execute the developer scripts is less obvious.
If your production control team is simply executing an automated process to run a build script provided by the developer, the separation-of-duties requirement cannot be met. First, there is no clear understanding where the source code is coming from. Scripts point to directories that are often outside the local build directory. Second, the developer's build-machine configuration may be at higher versions than the production runtime environment. And finally, your production-control team needs the ability to validate if production-level build configurations are turned on/off, such as removing debug flags and adding optimization flags. Yes, it is these steps that mainframe and legacy UNIX applications have understood for years, but Java and Windows teams are completely forgetting. - Identify the files used in the build that were not managed in the SCM repository. If you have gone through the expense of implementing source-code management tools throughout your development process, then it is critical to validate that the managed source code is actually used in the build. It is often critical to identify the components used in the build that are not under SCM control. These components are often critical third-party libraries, database libraries, SOA WSDL objects, and Java runtime libraries. Your process of managing binaries cannot underestimate the importance of these components. They serve to be as critical as any homegrown source module.
- Create a footprint showing which source code and libraries were used to create the final executables.
