Modern software development requires that a set of key tools and methods be used to protect intellectual property, produce quality code, and manage operations efficiently. Although large companies can afford a large support staff to maintain tools and enforce the use of specific approaches, small companies do not often have that luxury.
Failing to protect your company's intellectual property is gambling with your company's assets and shareholder value. Intellectual property doesn't just refer to your company's code, it also includes how you build and release your product, your ideas and data, how you track defects (bugs) and the defect data, and what technical documentation you create. A large component of a small company's value consists of intellectual property. If your company is being sold, the purchasing company considers the intellectual property as part of the offer price. If you have poorly maintained your company's intellectual property, then the buyer will see less value and make a lower offer for your company.
To protect your intellectual property, and ultimately your company's value, review your tools and the methods you use in at least the following areas:
Data backup Have a systematic and automatic approach to creating secure secondary backup copies of data on a regular basis.
Document availability Provide an easy method for making available all technical and product documentation for internal use.
Source code control and configuration management Track and archive source code files during and after development, and identify sets of files into defined releases.
Software builds Control how the software source creates the executable code that clients can use.
Bug tracking Use appropriate technology to track defects (bugs) and their repair.
Release method Employ the appropriate methods and technology to release your software.
Consider tools and methods in terms of your overall software development processes and practices throughout software development and support. Figure 7-1 illustrates this interaction. Backup and document communication cover the entire software release cycle. Source code control and software builds apply during code development until development releases the product. Bug tracking tracks problems discovered at any time. The release method describes the process of making the product available to your customers.
This chapter describes the different tools and methods used across the software release cycle, individually and in detail. Although some considerations might seem routine, digging deeper can help you uncover hidden risks and opportunities for improvement.
A backup mechanism provides the first level of protection for your company's intellectual property. Without a backup mechanism in place, all intellectual property can disappear instantly if it resides on your server's disk drives, because disk drives can and do fail for a number of reasons. In addition, without having secure backups, you can lose intellectual property due to a fire, a malicious hacker, or a malevolent employee. A development manager must either ensure that a backup mechanism exists or immediately direct its creation. If a separate IT organization backs up your intellectual property, you should review the organization's backup strategy. Often you will be surprised to find that your important data is not a part of their backup strategy.
Several best practices are recommended for file backup. You can customize these to your company's needs based on costs and staffing requirements:
Full copies of files are stored on permanent media (tape or CD, for example) and are not overwritten.
Full copies are stored on a regular basis in an offsite location.
Users are notified about which parts of the file system are backed up so that they can appropriately store their critical data.
Backup copies are made daily. A company usually can't afford to lose more than a day's data.
Source control and configuration management tools are used and the repository is backed up. To be effective, this requires team discipline, as the team needs to check files into the repository often.
Restoration of files from the backups is tested periodically. Otherwise, system administrators can discover backups that are incomplete or unusable after disaster has struck. Common causes of backup problems are ignored error messages in the backup logs, unexpected mechanical device failures, and the omission of needed files from the backup list. Test your backups at least once a quarter.
Warning
Backup failures discovered after disaster strikes are a common occurrence, so the remedy bears repeating: Regularly test your backups by restoring backed up files to test their viability.
A number of different backup approaches can be used, with different trade-offs for complexity, cost, risk, time to implement, and time to recover data. Your choice will depend on how you determine the relative balance of these needs for your company. Common backup approach considerations include the following:
Amount of disk space to include in the backup
Choice of backup media
Amount of automation in the backup process
Ease of use of the equipment versus associated costs to purchase and staff time
Regularity of the backups
Storage location of backup media
Choice of complete backups or partial backups on a regular basis
Three common approaches to frequency of backup are used:
Daily full backups
Weekly full backups, with daily differential backups from the last full backup
Monthly full backups, with weekly differential backups and daily incremental backups
Companies also use variations on these approaches. Figure 7-2 illustrates these approaches.
These approaches trade off administrator time and backup media space for ease and availability of data recovery. Daily full backups require the most backup media and potentially the most operator time, depending on the equipment used to perform the backup. However, a full backup approach allows you to restore files using a single day's stored backup, while other approaches do not permit this. You should start with this approach. When the backup time starts taking too long, try differential backups.
Weekly full backups plus daily differential backups from the last full backup takes less time during the week than full backups. However, in some cases you might need two sources of backup media to recover multiple files. The extra effort in recovery and the time to recover creates an effort "hill" you'll need to climb to recover files. This extra effort can make the backup administrator slow or reluctant to locate file versions that have been inadvertently lost. This approach works well for companies in the growth stage.
Monthly full backups with weekly differential and daily incremental backups require the fewest number of backup media and administrator efforts over a given month. However, a series of tapes can be required to recover a set of files. Set up each weekly differential to cover all files that changed since the weekly backup (and not the last weekly). Avoid this approach unless you must back up large amounts of data and you have limited backup capabilities, or you are not concerned with time involved for file recovery during normal business operations.
If full or full-plus-incremental backups don't seem right for your situation, you can use other strategies regarding frequency and amount of data for your backups. For example, the backup administrator could modify the approach to conduct full backups every other day. This would save backup time, but it increases the loss risk to two days' work instead of one day's work. Alternatively, the administrator could perform the incremental backups to cover only a single day's changes. An example would be setting Friday's incremental backup to cover only Friday's changed files instead of all the changes that occurred since the last full backup. Recovering the system to Friday's state would require the last full backup media plus all the incremental backups created that week. However, with this approach, the daily backups will take less time during the week. This modification trades administrator time for decreased cost to recover files.
In general, you should choose the simplest backup and recovery approach when you're starting out—probably one of the first two options. As the data grows, look at other strategies and consider changing your backup equipment to minimize administrator effort. However, don't skimp on performing proper backups on important information because the backups take too much time.
Regardless of the backup approach you choose, you should move your backup copies offsite to another location on a regular basis. Your choice of backup schedule reflects the trade-off of effort and risk. On the risk side, consider how many days of development work your company could afford to lose as part of disaster recovery. On the effort side, consider how much time your company can afford to spend making additional copies and moving them offsite.
As tapes can be required to recover lost files, consider the time hit spent creating tapes for shipment offsite. An expensive and time-consuming approach is to create duplicate copies for onsite and offsite copies every night. Most small companies use a simple approach of alternating onsite and offsite storage of their full backup copies. This approach is not very expensive, but it makes file recovery more difficult when you need to recover a file that is stored in an offsite backup.
Some customers might compel you to keep offsite copies of product code. Additionally, some customer contracts can require software escrow (periodic archiving of your source code with a third party). Customers ask for software escrow to minimize their risk; if your company fails, the customer receives a copy of the source code. This requirement forces periodic full backups of parts of your source code in addition to the regular backups.
Most small companies look for simple solutions to offsite backups. If you start with the assumption that a disaster will damage only your physical facility, then moving copies out of the facility will be sufficient. The media should be stored in a commercial backup storage facility or a second building in the same town—not at the administrator's home. Storing backup media in a person's home can be a problem if the person leaves the company (or the country).
To create your offsite backups, you could create an additional copy of each backup daily, but this would double your daily backup time. Instead, take full backups from your regular process offsite. If you need quick access to backup files in your facility, consider making duplicate copies of offsite backup media.
Some system administrators use a dangerous backup practice of making periodic image copies of disk files to another disk, overwriting the last copy. When used as the sole backup mechanism, this method suffers from many weaknesses:
Corrupt source files might corrupt the backup copy and permanent records do not exist.
A disgruntled employee can alter the data. The backup files will store a copy of the problem code as the administrator creates these periodically but does not create a permanent record.
Occasionally, hardware does fail. Although unlikely, both disks could fail, obliterating all your files.
Users can delete files by accident. If you discover a lost file after the administrator makes the backup image, you cannot recover the file.
Disk-to-disk backups are usually done with onsite disks. Consequently, if disaster strikes your building, you will have lost everything.
In general, avoid disk-only backup approaches in which you image your data and then overwrite the image. It will not help if you need to restore a file that was deleted weeks ago. Instead, back up to a permanent or stable medium. A disk-to-disk backup can be cost and time effective only if different images are made and saved regularly and a complete backup is kept on permanent media.