Why You Need a Bill of Materials

In manufacturing, companies are often required to create a Bill of Materials (a BOM) that describes in detail all of the items that are included in a certain deliverable or end product. In the early days of software development these descriptive documents were sometimes required as people attempted to understand what was included in a deliverable software package. While having this information is nice for the end-user, the manual nature of documenting the information combined with an increase in the frequency, size and complexity of software releases, has caused the creation of BOMs to fall out of use.
You may ask, but why do I need a BOM? If your product is web-based, perhaps it does not seem as critical to you to have a BOM. However, many of customers create embedded products that need to be supported, and updateable, for many years. In this instance, if you find that you have to support certain releases for long periods of time, then creating a BOM for your each release could prove a useful experience.
Recreating a Release
At many companies, products are supported for months, years and sometimes decades depending on the industry. When a priority bug fix is needed, it often must be created quickly and the company must assure the customer that only the fix they require is being included, that no other changes have been made. Most companies can identify the source used to create a particular build, but few can identify the tools, libraries, and the environment settings that were used. And even fewer still have the original environment used available to recreate the build.
Also lacking might be the knowledge needed to recreate a particular release, especially if there was turnover in the department creating it.
A Bill of Materials allows Build & Release Engineers to identify the exact versions of all tools needed to recreate a particular release. This will be very useful when trying to recreate a particular product at a later time (such as for an Emergency Bug Fix). Having a descriptive document that contains all of the environment information, tools, and specific branch and version of the software built will allow this to happen quickly and efficiently.
In Electric Commander, the exact environment information, the source paths, and other information such as compiler, linker or libraries used can be retrieved while the build is occurring, and can be stored with the build once it is completed. This convenient and automated process records the information at the time that it is used, ensuring its historical accuracy and providing rich historical content to new members of the team looking for documented knowledge of the build environment.
Electric Commander’s Artifact Manager can be used to store and retrieve the information on all libraries and others components used during any build or build packaging.
Escrow Account
An Escrow Account is a BOM on steroids. Vendors are often required to create Escrow Accounts for their customers, to ensure they will be able to recreate the product if the vendor is no longer able to do so for whatever reason. The Escrow Account will need the information included in the BOM as well as instructions on how to create the product from that raw material (such as your build instructions).
Through Electric Commander’s automation, the Escrow Account can be updated programmatically whenever a release is approved and disseminated (either to the NOC or to internal or external customers). By updating the account automatically, errors are decreased, and it ensures an accurate reflection of the product at release time.

With the advent of Virtual Machine technology, being able to keep environment information through the use of snapshots is invaluable. With the use of Virtual Machines, the ability to quickly recreate a specific environment ensures the ability to recreate any product release build. The snapshots can be stored indefinitely, so that years later, even if tools used to build the product have been upgraded, new tools added, old tools removed, by using the snapshot to recreate the exact environment used at the time of the release allows Release Engineers to ensure that the product can be rebuilt.

The type of information saved in a Bill of Materials can vary based on the type of software being built, the environment used for building, and so forth. At a minimum, the following information should be recorded:

1. The location of the source code and the specific branch and version used for the build

2. The name of snapshot for the build environment(s), and/or the details on the build environment (type of machine, OS information, environment variables, and so on)

3. A list of all tools used to build, including version numbers and location of installation (in case the snapshot is compromised)

4. The instructions to perform the build, location of build scripts, etc.

5. Bonus: the snapshot and description of the testing environments used

For an Escrow Account, a copy of the actual source code will need to be included, as well as any libraries or tools not available in the public domain.

Electric Commander, through its automation and Resource management, can deliver all aspects of the BOM along with the delivery of the product itself. By automating the collection of all of the information, and including that collection in the release process, the company is assured that the information is gathered and properly stored for future needs.
Information on the resources used to build the product (tools, environment settings, and so on) can be stored with the builds themselves, along with the information on the source code used to build. Automation can be created to save the particular resources as snapshots when using Virtual Machines.
When a build is promoted to a release, all of this information can be stored in a format appropriate for each companies needs through automation in Commander itself.

Using the Bill of Materials to track the items needed for creating a particular product release increases the ability to reproduce that product whenever necessary. It also supplies an auditable list of components needed to create that product. This allows businesses to be responsive to customer support needs, and improve the ability to deliver patches and fix releases that address the customer’s requirements.