Did you forget your: Username / Password ?

Microsoft

TechWell

Home

Implementation Excellence

Aircraft Carrier Called the "CM"

Written by Mario Moreira

Sunday, 17 April 2005 16:00

In the past, I had a window view of the Boston Harbor from my office. I could see boats coming in an out, including numerous tour boats, whale watch boats, and sail boats. Occasionally, I got the chance to see the large ships including the tankers, battleships, tall ships (e.g., elegant large sailing ships), and the rare site of an aircraft carrier. The aircraft carrier is a floating runway for jets. Imagine the infrastructure needed to get those super fast jets ready and flying.

Note: Based on the CVN 77 Concept Design

The key to an aircraft carrier is to have a well running runway. This includes runway procedures, runway staff, and runway technology. A runway of an aircraft carrier has similarities to the runway needed to get the releases of an application deployed. When the runway of an aircraft carrier is built effectively, project releases can “take off” into production, much like jets can take off from the runway of an aircraft carrier. Configuration Management (CM) acts as that runway for applications. It provides the procedures and technology to control and migrate the code off the runway and into the customers’ realm (a.k.a., production). CM also provides a mechanism to ensure all pieces of an application release are accounted for to ensure a successful take-off. A good CM runway can enable quick releases and allow the pilots (a.k.a., the developers/engineers) to focus on building the jets.

CM Support of the Application Lifecycle

When we look across an application lifecycle, it is important to determine what infrastructure is needed to ensure that the application stays afloat and can be readily deployed (or released). The base level infrastructure should include hardware (e.g., servers and desktops), the network, and the system or network administration to setup and maintain each. This may be considered the hull and engine of the aircraft carrier. Then we can focus on the software engineering disciplines such as Project Planning, Requirements Engineering, Architecture, Testing, and CM. What is the role that CM plays and how important is it?

As mentioned, one analogy is that CM can be the runway for an application. How well structured, how trained the people, how aware of the parts, can make a difference as to the success of the application release. If you are only looking to prototype an application without formally releasing it, then having little or no CM process and technology is worth the risk. However, when a company is building an application, they typically expect it to last as many years as possible and contribute to the profitability of the company. This implies that if they can sell it, they hope to have numerous releases of the product. Immediately after the first release, begins the onerous task of maintaining an existing release in the field while developing a new release of the application internally. In order to stay in business, it is critical that regression of application functionality does not occur. The focus becomes establishing a good way to handle supporting multiple releases and reducing regression in the application. Configuration Management provides that solution.

Getting Started - CM Infrastructure for an Application

A big question that many new application development teams face is how soon should they start establishing their CM infrastructure and how robust does their CM have to be? The ideal scenario is being allowed to share an existing CM infrastructure. This implies a company that has been in operation for a while. However, a full CM infrastructure may not be feasible for most startup companies who do not have the resources to do this work and is initially focusing on getting an application to market. To answer the question on how quickly the CM infrastructure should get set up, let us examine two scenarios: setting up CM at the beginning and setting CM up after Release 1.

Building CM infrastructure prior to (and during) release 1

The first approach is spending effort to establish an effective CM infrastructure before beginning an application lifecycle. This has many advantages. The CM processes can be tailored specifically to the application needs and all CM controls can be available during the first release. In addition, once a full infrastructure is in place, any type of development methodology may be applied.

The disadvantages of this approach mean that resources are applied to infrastructure tasks versus focusing on getting the application to the marketplace. This can be critical to startup companies. If they do not get a product to market and establish market share soon, the company will go bankrupt

Building CM infrastructure after release 1

The second approach has the application team focusing on developing release 1 then establishing the CM infrastructure thereafter. As mentioned, often times CM is not focused on until an application team nears the completion of the first release or thereafter. The advantage is that if the immediate goal is to get the product to market, then resources and funding are focused on development. Therefore, there is little effort focused on CM and other software engineering disciplines.

The disadvantage of this approach is that a lack of CM can impact subsequent releases. While this model may not be exact, it illustrates that the project release schedule for Release 2 (or subsequent releases) may be extended. Typically, in this approach when the second is underway, the focus on CM becomes serious since a branching and merging process is needed to focus on release 2 while maintaining and patching fixes to release 1. If key elements of CM are not in place, it can take more time to solve problems and get the release out due to the risk of overwriting code increases, risk of losing bug fixes increases, and therefore causing regression in functionality that can impact the market share of the application.

Some CM is Better than None – an Alternative Approach

Now that we have seen two broad approaches in introducing CM, we can add a third approach. This focuses on introducing the high priority CM functionality prior to or during release 1 and focus on the lesser priority CM functionality at a later release. As mentioned above, often times, a company or application team does not have the means to implement full CM, so they end up implementing very little. In order to reduce some of the project risk, introducing some elements of CM prior to or during release 1 can be a wise decision. This may be considered the just-in-time approach. With this in mind, what CM functionality is typically included in a robust CM infrastructure? This may include (and not limited too):

Version Control technology
Checkout/Checkin procedure
Build technology
Build procedure
Branching and Merging procedure
Change Control procedure
Problem Management technology (e.g., defect tracking, etc)
Problem Management process
Audit procedure
Reporting/Status Accounting procedure
Release technology
Release procedure

Next, you should prioritize which of these CM functions are important for Release 1 of an application and deploy this CM functionality first. As an example, the Version Control technology, Checkout/Checkin procedure, Build technology, Build procedure, and Release procedure may be important for Release 1 in order for the code to be controlled and released in an effective manner.

Then for Release 2, you continue the prioritization and deployment. As an example, Branching and Merging procedure, Change Control procedure, Problem Management technology (e.g., defect tracking, etc), and Problem Management process are deployed for Release 2, and so on.

This is an example of incremental deployment of CM functionality. This approach focuses on allocating CM tasks over a period of time so they can be more easily accomplished and offered to the application team on a just in time basis. This ultimately provides a balance between funding, resources, and risk management.

Lessons Learned

In the era where many lifecycle methodologies are utilized, where focus is faster releases, and agile methods deliver releases more frequently to the market, a fully enabled runway can be advantageous. Having been involved in numerous CM infrastructure implementations under various scenarios over the years, I have learned some lessons.

In one scenario, I was involved with a new application development effort a few years ago where the application development team decided to use Scrum, a form of agile methodology. This involved producing monthly release deliverables, effectively implying that the project lifecycle per release would be no more than 30 days. The issue that was encountered almost immediately was that there was no CM infrastructure to support their needs. After being late deploying the first release, the development team began the second release. Critical issues arouse immediately because there was no CM in place. There was no branching and merging process to support the next release and apply bug fixes to the previous release, there was no change control for new requirements, and there was a very limited problem management process to effectively manage the defects coming in. This initiated a CM project to establish this CM functionality.

In another scenario, many years ago, I was involved with establishing a shared CM environment. Initially, we did not create standard CM processes and it quickly became challenging to maintain the environment. Common locations for repositories and standard structures made it very hard to establish dependencies. This also made it hard to automate since there were no standard naming conventions. This initiated a CM project to establish common CM processes, naming conventions, and eventually automation.

Summary

When entering into an application development venture, it is important to apply software engineering disciplines to help control and manage the effort. An effective CM infrastructure can provide an effective runway in which releases of an application can “take-off”. However, it is important to consider when to establish a CM infrastructure. While it is preferable to establish the CM infrastructure upfront so that CM processes can be tailored specifically to the application needs and all CM controls can be available during the first release, this may not be feasible to younger companies. An alternative is to apply a just-in-time approach. While this requires some forethought for prioritization, it can be the most efficient use of resources, particularly when CM resources are limited.

Mario Moreira is a Columnist for the Configuration Management Journal, a Director/Architect of Technology, an Author of CM publications, and has worked in the SCM field since 1986. He has experience with numerous SCM technologies and processes and has implemented SCM on over 100 applications/products, which include establishing global SCM infrastructures. He has an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience.

Mario has released a new SCM book entitled, “Software Configuration Management Implementation Roadmap." You can find it at amazon.com www.amazon.com This book includes step-by-step guidance for implementing SCM at the organization, application, and project level and includes helpful templates on CD to get started.

You may reach Mr. Moreira by email at Mario.Moreira@cmcrossroads.com

Set as favorite

Bookmark

Email this