10.5. Cleaning Up Your Environment Part of maintaining a development environment is deciding when to throw things away. Taking out the trash isn't anyone's favorite chore; it usually gets ignored for as long as possible, and the bigger the trashcan, the worse it smells when you do finally take it out. This section discusses how you can make this chore less tedious by carefully planning it beforehand and then automating it as much as possible.  | Before deleting any file that took longer than an hour to generate, it's a good idea to compress and archive such files to CDs, DVDs, or backup tapes. If possible, do this yourself so that it's not a burden on an IT department. Then keep these archives in folders or boxes with something like "Discard after 2006" written on them. |
|
SCM -
The purpose of SCM tools is to store as much information about their contents as possible, so in some sense it's ironic that we have to clean them up. Storage space is finite, though this is rarely a problem unless you have many copies of binary files, or large files that differ greatly from each other. Backups are harder and take longer as repositories become very large, but that too can be dealt with as necessary. The real clutter in an SCM repository is actually dead branches and hundreds of dusty tags on files. This clutter can make it hard for people to see the changes of interest to them. For a medium-sized project producing a few builds per week for testing purposes, some guidelines for removing tags and branches are: Most importantly, never remove a tag for a released version of the product, or a branch for a released version of the product. Remove tags for internal builds older than six builds (or two weeks) that have no bugs filed against them. If no one has used a particular build by then, they probably aren't ever going to. Lock private branches a month after the last change to them, or when their users have finally merged them into another branch. Archive and then delete private branches after two more releases of the productif the changes on the branches haven't been used by then, the product has probably changed too much for those changes to still be useful.
There are projects that periodically remove all revisions of files except for the versions of files that are tagged. This seems extreme to me, since sometimes changes in developing source code are where the mistakes to be avoided in the future are recorded.
Builds -
For internal builds, the ones that are used only for testing, keep the entire build directory with all its object files for the last two or three builds, if space permits. For builds older than that, you can most likely just keep the generated packages or executables and delete the object files and the source code used to produce the build. If an internal build is older than six builds (or two weeks) and has no bugs filed against it, then that build can be removed entirely.
Testing -
Just deleting the actual files related to the build doesn't mean that the build is gone, of course; it still exists as a tag in the SCM tool. Once the tag for a build has been removed, then the test results for that build can also be deleted. Full-time testers quite often have personal storage space or databases allocated to them, and they may well create very large amounts of data while they run tests. The temptation is to keep everything because "the bug might reappear" or "a similar bug might reappear." One useful guideline here is to ask how long it would take to recreate the data if it were needed, and then to delete the largest files that are easiest to reproduce.
Bug tracking systems -
Section 7.3.2 also discusses cleaning up bug tracking systems, but the most common kind of clutter is the labels for all the builds that different bugs appear in. Removing a choice from a drop-down box of builds should not change any bugs that already exist, though it may make it harder to modify existing bugs later on. Periodic scans of bug tracking systems for overly large attachments are also part of maintaining the tool.
Documentation -
Documentation directories seem to be traditional areas where things are never thrown away. Consequently, they come to contain layer upon layer of unusable documents. One way to avoid this quagmire is to keep documents in formats that work well with your SCM tool, and to then store different versions of the documents using the SCM tool. Too many "documentation" files turn out to be copies of other documents, and then the copies diverge and neither can be deleted. Section 11.5 contains some ideas about how to avoid content rot on project web sites, and many of these ideas are applicable to the rest of a project's documentation.
Releases -
The obvious rule for releases is never to delete anything that has ever been distributed to customers. Very old releases should certainly be archived; they should also be made unavailable, or harder to find, on your web site or FTP server. The download statistics for each release package come in handy for checking what is still used. Section 9.7 has more suggestions about what to keep and what to discard from releases. Something else that can take up a great deal of storage is files from customers, especially if the files include core dumps from crashed programs. Even text-based logfiles can be quite large sometimes. The most important thing is to be able to identify a bug or customer issue related to each file. Otherwise, you'll never know whether you can delete these files. Files from customers can also contain sensitive information, so make sure you know who is allowed to access them, or scramble the sensitive parts without affecting the issue. This is another good reason to delete these files and their backed-up copies after a certain time.
People -
Removing a person from a project doesn't mean rewriting history to make it seem that he never existed. Disabling his accounts, stopping access to the various tools in a development environment, removing him from email aliases, and redirecting his email should all be as automated as possible. The details of changes to source files, bugs, test results, and documentation should all keep the person's name, but all uses of his name as a contact within the project should be changed. If it isn't possible to remove the person's account without all references to him being removed too, perhaps his account can be renamed in some consistent way? Be careful to avoid reusing a username, though; for example, if two people named John Smith work on the same project at different times, use different usernames for each of them. Documents, source code, and test definitions that contain the name of their current owner should be updated. Another place to make sure that the person's name is removed is any part of the project web site that refers to him as a contact for something. This can be avoided in the future by using email aliases such as scm-admin, bug-admin, and build-admin for different areas of the environment. One subject that is rarely discussed is what to do when someone working on the source code dies, and you're the one who has to take over her code. All of the above guidelines for removing someone from a project still apply, but you may feel awkward when you come to change or delete her work. My suggestion is to put a memorial comment block in the code with an injunction to future developers not to remove it, ponder your own mortality for a while, and then move forward.
|
