There are many different viewpoints one can take when asked to secure one’s Development Assets. The following is a short and very incomplete list of viewpoints:
- Securing against the concurrent use of multiple versions or releases
- Securing against obsolescence
- Securing against license expiration
- Securing against loss of Intellectual Property rights
- Securing against inadvertent change to working Development Processes
- Securing against the loss of “Development” source
- Securing against the inability to reproduce deliverables
- Securing against the loss of the ability to data mine completed projects
- Securing against the loss of critical resources, either hard, soft or wet
Like almost everything else in the CM arena, only one or two of these really garner any attention from Development Management. At the Enterprise level, maybe up to 5 of these are of concern. We have to worry about all of them if we hope to do our job to the fullest extent.
Let’s take the most common of these, securing the source base. We keep the source in a versioned repository using one of the many tools available to us, but it is a project level decision as to what constitutes “source.” To some, it is just the code. To others, it includes not only code, but deliverable documentation. And to a few, it includes all documentation, requirements, specifications, designs, control documents, project schedules, metrics reports, status reports, reviews, Unit Test reports, change control documentation, defect and issue reports, test plans and data, test reports, signoff/approval forms, build scripts, build logs, database schema definitions and data dictionaries, seed and static data, and of course the code.
It may take more than one Versioning tool to keep up with all of the data types represented above. It also requires that appropriate repository backups be performed at periodic intervals and that there is a retrieval mechanism in place to allow the repositories to be restored fully or selectively. This means that any “archived” repositories must be brought current with whatever recovery tools are in place.
There also needs to be some secure method of preventing unauthorized changes to the source base. This starts at keeping unauthorized users from accessing the repository. It can also include keeping all or part of a repository locked from normal user access, while allowing full access to other parts of the repository. This could include such common actions as locking branches, labels and/or directory trees. Keep in mind that there are normally autonomous agents (scripts, processes, integrations, etc.) that scan, export, import, and change not only repository contents, but repository metadata as well. These need to be treated with the same care and diligence as users do.
Whew, that takes care of the code. I think. For now. Maybe. Source by itself, however, is useless. Its purpose is to allow some transformation mechanism (tools) to convert it into deliverables. While it makes sense that different releases of a tool will produce different output, one really wants to be able to reproduce the same results when rebuilding a past deliverable. What this means is that the tool-chains themselves must also be controlled. This control may actually be “owned” by IT and not the Build Management portion of CM.
Controlling tool-chains is not as easy as source for a variety of reasons:
- Each tool is dependent on the environment it runs in
- Each tool may have an expiration date built in
- Many tools only allow one of each release level (or even more extreme, one per type) to exist in an environment
- The way the same tool is installed may vary from time to time
- The “settings” and “preferences” selected for a tool’s installation and/or configuration may well vary widely.
 I have seen two mechanisms used successfully to foster tool-chain reproducibility. The first is to have multiple removable system drives, each with its own complete operating system, set of tool-chains, etc. This is most common with Windows-based systems. The other approach is to use virtual systems such as VMware or User Mode Linux to encapsulate each tool-chain into a discrete and unchangingenvironment. This mechanism is most common with Linux or multi-platform heterogeneous cross-generated systems. Of course, neither of these takes into account license volatility.
The capture of the build environments, including tool-chains, as well as the source repositories themselves is also necessary for disaster recovery. In this case, backups are your friend, offsite backups outside your geographic are good friends and secure online backups outside your geographic area are your best friends. Of course, test the backups every now and then!
If it sounds like I am saying, “Be paranoid!” it is because I am. The hardest thing to prevent is license expiration. Virtual machines with back-dated clocks are one way around this, but it really causes confusion when you release a brand new update with a 1999 date. Some times there is nothing you can do. Some times you have to take small bites and work toward a better solution down the road – incremental improvement.
Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis using a combination of CVS and custom tools to support a modified Agile-SCRUM development methodology. He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), NTLUG (North Texas Linux Users Group), and PLUG (Phoenix Linux Users Group).
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Subscribe to this comment's feed