Tracking Source Changes (All Check-Ins)-The Build Process

Tracking Source Changes (All Check-Ins) The Build Process

There's a misconception among software companies that every line of code that they write must be protected like it's gold, but it's time for a reality check: Little source code is patentable or of real intellectual property (IP) value (see the "Richter on .NET Security" sidenote later in this chapter), so you should worry more about securing the source code control process and the build process rather than the individual source files.

Some companies go to extreme lengths to try to secure their source code via physical means, including locking developer machines in a secure development lab. These companies don't allow the developers to carry hardware or bags in or out of the lab. I don't know many developers who can work in that type of environment, though. Also, if you can't trust a developer not to steal your code, how can you trust him to write it?

There's a better way to secure your development:

• Track all check-ins to a secured, locked-down, golden source tree.

• Create triggers to ensure that check-in rules, such as buddy build and code review, have been followed.

• Reject check-ins that do not comply.

• Schedule atomic check-ins from different groups.

• Set up development sponsors at the central and offsite location. These persons are ultimately responsible for the integrity of the code being checked in. This is probably the most critical step.

• Automatically check the developer's user network logon to whatever headcount tracking tool you use. Verify the developer's identity with network logon and machine name.

• Run security checks on check-ins and all sources that are released. You can do this with scripts or tools that search for any known holes in architecture or unsafe API calls.

• Limit access to "new" source code. Some groups or companies allow offsite development teams to work only on hotfixes and service packs, not to develop new features or code.

These suggestions are representative of how we are able to track source code changes back to the original owner and how we are assured that only the changes necessary to fix the bug or add a feature are checked in. If you combine these steps with the VBL process in Chapter 2, "Source Tree Configuration for Multiple Sites and Parallel (Multi-Version) Development Work," you will have an incredibly reliable and dependable system of maintaining your sources and their changes.