In this chapter, you've seen a variety of information on integrating Subversion into your overall development process. The developer studies showed some of the
Chapter 14. Case Studies in Development Processes
Understanding is always easier with a few examples. So far, we've
14.1. Archetypal Studies
In this section, we'll look at several development project archetypes. For each one, I will describe the
14.1.1. Managed Chaos
The managed chaos project is one with little managerial oversight over the day-to-day details of development. Instead,
In this case study, we will look at a hypothetical managed chaos project and open source program called BogeyTalk, which allows text on your computer to be read to you in the style of Humphrey Bogart. BogeyTalk is a mature project, with dozens of contributors, as well as a small team of five maintainers, handpicked from the project's major developers by the creator of the project, who we'll call Bob. Significant project releases are frequent (a couple of times a year), and the project
Because BogeyTalk is the only project hosted in its Subversion repository, the entire project resides at the top level of the repository. The main development branch of the project resides in the /TRunk directory. Additionally, there are /stable , /development , and /maint_branches directories, as you can see in Figure 14.1. The /maint_branches directory is used to store maintenance branches (as I will explain shortly), whereas the /stable and /development directories are tag directories that store snapshots of various releases of the project.
Figure 14.1. The BogeyTalk repository layout.
Branches and Tags
Because most BogeyTalk developers do not have access to make direct commits to the repository, task branches make little sense. Therefore, BogeyTalk uses branches and tags primarily to signify different versions and releases. For each release of the project, a tag of the project is created in either /stable or /development , depending on whether the release was a stable release or a development release (the different directories help ensure a logical separation between the two release categories). Both of these directories are used as immutable tag directories (i.e., copies are created here from elsewhere and nothing is changed once created), but the repository is not set up to enforce that policy. Instead, Bob made the decision to trust the maintainers and make it easy for them to make a correction if there is an error when creating a release tag. Because there are only a few maintainers, this works out well.
Most actual development on BogeyTalk occurs in the /TRunk directory, but occasionally there needs to be further development on an older version of the program in order to patch security holes or maintain compatibility with other projects. To support these security patches, the BogeyTalk project maintains maintenance branches for each stable version of the project (1.0, 1.2, 1.4, and so on) in the /maint_branches directory. These branches are created at the time of the stable version's release, and are identical to that version's tag in the /stable directory at the time of the release. When security or compatibility patches need to be made, they are committed to these branches, which are then tagged to create subminor version releases (1.0.1, 1.0.2, and so on).
The BogeyTalk makes use of the svn:keywords property to embed repository information in the comment header of each file, using the $Id$ tag. Because most BogeyTalk users get their copy of the project's source code from a release package, and not directly from the repository, this makes sure that the information necessary for finding a particular file in the repository will always be available.
BogeyTalk also uses several custom properties for storing additional
BogeyTalk uses a custom script that automatically maintains the project's download directories, which contain packaged versions of the project in source and binary form. Each night, the script is run as a cron job on the project server.
BogeyTalk also has a custom script for creating its contributer annotated blame output for the BogeyTalk developer's Web site. The BogeyTalk blame script takes the raw output from
14.1.2. Rapid Development
The rapid development project is aimed at getting rapid functional output, without a long upfront development cycle. The project is often subject to frequent requirements changes, and developers need to be able to
For this case study, we'll look at a hypothetical Web database application, being developed by the software development consulting firm, Programmers, LLC. The client on the project, Internet Sales, Inc., wants to put the application into use on its internationally known online sales Web site, but the exact requirements are fluctuating
The repository for Programmers, LLC holds all of its ongoing projects, not just the database application for Internet Sales, Inc. Therefore, the top level of the repository consists of subdirectories for each project, which in this case is referred to as ISDB (Internet Sales DataBase). The developers at Programmers, LLC are no fans of extra work, though, and many of their projects tend to have overlapping functionalities. Therefore, they have also developed a number of in-house projects that contain libraries used by their contract projects, which they also store in top-level directories. In the case of ISDB, there is one Web database project, stored in /webdb , that is used.
Inside the /isdb project directory, the project is split into a main /isdb/trunk directory, an /isdb/dailies directory, and an /isdb/releases directory (see Figure 14.2). The trunk directory is where the main project development occurs. They store daily project build tags in the dailies directory, and versions of the project released to the client in releases .
Figure 14.2. The Programmers, LLC repository layout.
Branches and Tags
Because the ISDB project is on a rapid development schedule, the project's developers are using continuous integration of their work. That puts all of their development work on the main trunk, and alleviates the need to use branches for separating work. There is also no need to use branches for supporting multiple versions of the software, because there will only be a single client that they need to support. If the project were to be "branched" for development for a different client, the developers would instead make a copy of the /isdb top-level project to create a new project for their new client.
The Programmers, LLC developers do make frequent tags of the ISDB project trunk, though. Each day, they make a snapshot of the TRunk directory in the dailies directory to store the state of the project at the end of that day's development. Additionally, they make tags of the trunk directory whenever they release a version of the software to the client (either for testing purposes, or as a version to be used in production), and place them in the releases directory.
Programmers, LLC makes use of the
Programmers, LLC also makes heavy use of properties to store project information at the top level of each project. For each project, the top-level directory for that project stores
As a part of the ISDB project's rapid development cycle, the project uses automated regression tests to ensure that no developer's contribution breaks other
The ISDB project uses a number of scripts to perform automatic testing on the project, in order to help facilitate Programmers, LLC's rapid development and integration schedule.
14.1.3. Central Planning
To examine this project archetype, we'll look at the hypothetical government contractor, GovCon. GovCon develops a wide variety of different projects for various government agencies. Many of the projects are quite large, and all must conform to detailed and exacting government specifications. In order to maintain the level of control necessary to meet these
GovCon uses separate Subversion repositories for each project, so individual projects exist at the top level of their respective repository. The project then consists of four subdirectories:
Figure 14.3. The GovCon repository layout.
Branches and Tags
GovCon makes heavy use of branches in its project development to separate tasks in order to allow each individual developer's work to be thoroughly
The GovCon projects use properties as a tool for facilitating communication between QA testers and developers. The top-level directory for each project branch contains a status property ( qa:status ), which indicates whether a branch has been tested yet. When a task is created, its status is set to untested/inprogress , and the qa:tester property is unset. As soon as a developer feels that the current task is ready for testing, that developer changes the value of qa:status to untested/ready . QA testers can then go through and test all of the tasks with a status that is marked as ready. If the tester is happy with the results, the qa:status property is set to tested/passed . If the task is not satisfactory, qa status is set to tested/failed . When a task is tested, the QA tester's username also is entered into the qa:tester property.
All of the GovCon projects use pre-commit hook scripts to ensure that a variety of project policies are being followed correctly.
hook script checks the QA property values for changes, and sends e-
14.1.4. Small Teams
In small-team projects, there are very few developers working on a projectgenerally 10 or less. Development process tends to be
For this case study, we'll look at an imaginary startup company named SmallCo. SmallCo was started by five
SmallCo currently has only a single product, which is stored in its own repository. With so few developers, SmallCo hasn't seen much of a need to be particularly creative with its repository layout, either. Following standard convention, the top level of the SmallCo repository is laid out with /branches , /tags , and /TRunk directories, as you can see in Figure 14.4.
Figure 14.4. The SmallCo repository layout.
Branches and Tags
SmallCo does all of its project development in the main /TRunk directory, with each developer committing changes as they are made and tested. Tags of the project are made at both development milestones (i.e., beta or alpha releases) and at releases. Branches are only used when problems need to be fixed with a previously released version, in which case the tag for that release is copied into the branches directory, where it can be modified as necessary. When the fix is finished, the branch is moved back to the tags directory as the new release. For instance, if a bug is found in version 1.1 of the software, the developers would copy /tags/version_1.1 to /branches/version_1.1.1 and make the necessary changes. When the new bug-fix release is ready, it is moved back to /tags using svn mv .
Because of SmallCo's
As with properties, SmallCo has not found a pressing need to automate any of its practices or policy enforcement with custom scripts. It is small enough that policy enforcement is more easily done offline (if someone messes up, the developers fix it), and the development process is handled too informally to benefit from automation.