SCM Design Patterns: Version Control & Multiple States

[article]
Part 2
Summary:
The Version Control design pattern is seen when you only want to capture iterations (versions) 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 next design pattern is Multiple States, where you need to track unique collection of items that represent the application at a certain point in the lifecycle of the development process

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.

jjdesignpatterns2-1

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).
jjdesignpatterns2-2

Here are some of the processes that could be automated:

    • Check-out
    • Check-in
    • 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. 
jjdesignpatterns2-3

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

Pages

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03