Moving? Here let me help....

• Download source files - 89 Kb

Target audience

This guide provides team-development guidelines for lead developers, developers, configuration controllers, release controllers and system administrators. Read this guide if you plan to, or currently work on a team-based development project implementation/release.

What you must know

Some knowledge of product movement/release management and MS Excel.

Introduction

While working in a team environment, we face many project related challenges. One of which is the tracking of code and its movement to production servers.

The challenge is:

1. To implement an authorization and code movement process.
2. To track which version of code was moved, why, when, by whom and for which project.

Although I have stressed the used of a source control tool (one times too many) in my previous articles, source control only helps to the extent of maintaining code versions with historical data of who made the changes and when.

The process of implementation or movement of code to production is another matter all together.

The solution

A simple yet very powerful solution my team and I discovered in MS Excel and MS Outlook is aptly called the "Movement Log".

To describe what it does; I'll have to iterate through the challenges once again. So here it goes:

Authorization and code movement process (the background)

We have a policy in our organization where as developers we only have the rights to develop and test to our satisfaction (development environment).

The project/product of our development efforts can only be brought to light only after final approval of the project is received from the customer requesting the development. This is also known as User Acceptance Testing (UAT - normally done on a staging server or test server environment).

If at this point (UAT) the customer feels the project/product is not as per his specifications or expectations – it will be moved back to the development environment for the developers to fix and return to this environment again for another round of UAT.

Once the UAT sign-off is received from the customer the project/product files are handed over to another un-biased team (known as the Release Mgt. team). Only this team has administrative access to Production or Live Server environment. They wait for a receipt of upper management’s approval and then move the said project/product files to the live/production environment where it officially becomes launched.

After the project/product is live, if new bugs or code enhancements occur (Murphy’s Law!!) the code is extracted from our Source Control tool and worked on by the developer to go through the above cycle once again till movement to production.

As you can see from the above, there is a considerable movement of code between the three environments of Development, Staging and Production.

Tracking of movement (the background)

While the above is a nicely documented and implemented process - tracking the same and ensuring it is correctly implemented, can only be done if you have a mechanism of logging who moved what and when between the three environments and of-course why.

This is where the Movement Log comes into picture. As you can see in Figure 1, the Movement Log is actually an Excel sheet with some customized macros to move project/product files while maintaining a log entry and fitting in with the above challenges/process.

Figure 1:

The movement log

As a developer or a person requesting movement of code, I would fill in the areas of:

• “File Name” - code name and its path,
• “Move to Staging” - a Y/N value indicating if it has to be moved to Staging Server or not,
• “Move to Prod” - a Y/N value indicating if it has to be moved to Production Server or not,
• “Comments” - some comments and explanations if any for the need of movement and
• “MWS / URF #” - which is just a reference number for our organization to track developments.

Once these details are filled in, I would click on the Send Mail button. This action sends emails to the Processors (email IDs given in the movement log - Email Processor/CC Processor) with details of the files that need to be moved. See Figure 2.

The Processors check their email and forward it to the related authorities for movement confirmation. After which this email is handed over to the Release department for the final movement. Once the Release department moves the files, they come back to the movement log and update the “Moved to Staging or Prod On” dates as well as “Moved By” columns. This way the files are ensured of not being sent again for movement.

The Send Mail button auto enters the “Email Sent On” date column as the Move Files button auto updates the “Last Updated On” date column.

Figure 2:

This file can also be used for reporting requirements in the future. I have added in smart little extras providing Excel filters on each column heading. The email ID and CC to ID can be changed at any time as well as the list of file extensions or names to exclude when moving files. For the Send Mail to work the file requires MS Outlook 10.0 object library reference (msoutl.olb).

So here it is, Code authorization, Movement process, Intimation and Tracking, all included for the release process in one simple Excel file with two functions!! Enjoy!!