The Version Control design pattern is seen when you only want to capture iterations (version control) of static items such as documents, simple applications, and project baselines. Other features of simple version control are that you want to capture and control items while guarding against the loss of any item, maintain an audit trail of each item, and allow for roll back of items to an earlier version.
The roles I described in Design Pattern 1 are the same in this Design Pattern, except now they execute their functions much more efficiently with the implementation of an automated SCM system. The illustration shown in Figure 6 shows this topology, very similar to that shown in Figure 1.
Most of the processes defined in Design Pattern 1 can be used as a base for Version Control. Sometimes this Design Pattern is called a Single State Lifecycle since there is no promotion (more on this terminology in Design Pattern 3). Since most of the processes necessary for this Design Pattern have been defined using manual methods
described in Design Pattern 1, all that has to be done is to automate them with
a SCM System (Figure 7).
Here are some of the processes that could be automated:
- Generation of on-line forms for managers to enter change requests into the system
- Secure access to CIs
- Generation of CI version numbers
- Email notification to approvers that indicate their need to sign-off on CIs
- On-line approval of Changes
- Report generation for auditing and compliance purposes
Depending on the SCM tool and your implementation of it, there may be fewer or more functions that you may want to automate based on internal and external development and support requirements. If you went through a "dry run" with a paper based Design
Pattern, you now have requirements to evaluate a SCM tool with.
This design pattern is fine as long as you have static CIs that do not require any "compartmentalization". By that I mean you do not need to have multiple configurations or versions of your CIs at any one point in time. The requirement for multiple views of your
CIs is essential when you have a more complex Application that needs various groups to access the CIs that form an application at a single point in time. This is what Design Pattern 3: Multiple States will address.
Utilizing the first two patterns that we went through, we can now progress to the following more complex Design Patterns.
Design Pattern 3: Multiple States
Now that an automated/computerized SCM system is in place, the topology for this Design Pattern and Design Patterns 4 & 5 looks something like Figure 8.
Figure 8 shows the SCM system controlling access to all the CIs that make up an Application. It also shows access to the CIs by the previously defined Developers, Technical Team Manager, and Development Project Manager. But now we have two new roles: Testers and Customers.
Testers*: An independent group that specializes in executing testing. Activities they perform include:
- Generation of test cases
- Validation of test cases to user requirements
- Stress testing
Customers*: Existing users of the Application in the field or internal users that test the Application for "usability" from a customers' perspective.
*Note: The roles I have created for this Design Pattern and those that follow are for illustrative purposes only. Your development environment and SCM system/tool may call for other/different roles.
Once you start down the road of more sophisticated software development and SCM, you are going to want to segregate the development and SCM activities into secure areas which support the lifecycle of your Application.
An important concept of this Design Pattern is that of a "State". A State is a unique collection of CIs that represent the Application at a certain point in the lifecycle of the development process. Every State