SCM Design Patterns: Version Control & Multiple States

Part 2

is separated within a SCM tool from all other States so that different collections of CIs can be configured to present different views of an Application without impacting the configuration of CIs in
other States. Figure 9 shows a simplified flow chart of how this "Multiple State" design pattern looks. 


All CIs (code, make files, graphics, etc..) that are needed to build an Application must enter the SCM system through a Check-in to the Development State. Any CIs that need to be altered must also leave the SCM system from the Development State through a Check-out. This may seem obvious but it is key to controlling the integrity of the States that follow. The States are named according to what function they serve in the development lifecycle. CIs are moved between adjoining States through the concept of Promotion (moving from a lower State to a higher State) or Demotion (moving from a higher State to a lower State). The motion enabler for these movements are primarily centered around stakeholders'
testing activities and CCBs that will be highlighted in Figure 10. All States beyond the Development State are "View Only". This means that no changes can be made to the CIs directly, they can only be moved around from State to State.

Now that the basic concepts are in place we'll move to a more complete perspective of the Multiple State Design Pattern shown in Figure 10.



In Figure 10, starting in the upper left hand corner, you see the same sorts of inputs entering the Change Control step that you saw in the Version Control Design Pattern. Change Control functions the same as it did in Design Patterns 1 and 2, but from this point on CIs will be handled differently. As we discussed before, we want to insulate the States from one another by the needs of the stakeholders' activities, primarily testing and CCBs.

An important concept are the rules for moving CIs from State to State. 

  • To promote CIs from one State to another there must be a CCB approval (except between the Development and Integration States)
  • Approval of CIs from a CCB does not necessarily mean they are automatically promoted. A Technical Team Manager/Development Project Manager controls the promotion of CIs from State to State
  • A demotion from one State to another (also called a rollback) should only
    occur when an error is detected by the stakeholder of the State after one
    or more CIs have been promoted to that State. The Technical Team
    Manager/Development Project Manager controls the demotion from State to State

The source code and other CIs (indicated by the grey and green boxes) and the run-time CIs (indicated by the yellow triangles for incremental builds and yellow octagons for complete builds) indicate a relationship between these 2 components. The run-time Application in each State is unique to the CIs that are used to compile the Application in that State. The run-time Application is most often the target of testing and CCBs. But the
source code/files as well as other non-compiled CIs are the primary components
manipulated by the SCM system. 

Our first State is the Development State.

The Development State is used by Developers on a team to Check-out and Check-in CIs as changes impact the need for new or modified CIs. This might mean that you are checking-in some CIs for a new feature in your Application, you need to check-out a CI to fix a bug, or you are Checking-in a large amount of new CIs into the SCM system for a new
release of your Application. Developers probably do their work on the CIs within an Integrated Development Environment (IDE) on their local PCs as is indicated in Figure 10. The work done on the developers' PCs could be considered as a type of

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.