Aircraft Carrier Called the "CM"


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 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 to introducing CM, we can add a third. 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, a company or application team often 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 (but not be limited to):


·         Version control technology

·         Checkout/check-in 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. Version control technology, checkout/check-in procedures, build technology, build procedures, and release procedures may be important for release ,1 in order for the code to be controlled and released in an effective manner.

For release 2, you continue the prioritization and deployment. For 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 that focuses on allocating CM tasks over a period of time so they can be more easily accomplished.   These can be offered to the application team on a just-in-time basis and ultimately provides a balance

About the author

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

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