Project Management

Change Management: How to clearly define the environments

One of the most important decisions you face as an IT leader is how best to define the environments in which your developers will work. In this article, Tim Chapman explains the four most common environments used in most IT shops and presents tips for organizing your environments.

By Tim Chapman

One of the most important decisions you face as an IT leader is how best to define the environments in which your developers will work. Here are the four most common environments used in most IT shops and presents tips for organizing your environments.

Environment #1: Development

The Dev environment is at the heart of any IT shop, and it's where you want your programmers doing their work. Here is where all design, development, unit testing, and debugging should occur. Changes that your developers make in Dev are typically the direct result of requests entered in your change management system.

Consider the following questions regarding your Dev environment when you design your change management process:

  • Do you want your developers having their own copy of the source code, or should all developers share the same environment?
  • What type of source code controls, if any, should you use?
  • Should you use the same type of source code control for all code types or just some? For instance, you may need different controls for C++ code compared to database code.
  • How will you keep track of the changes that have been made in development? 
  • What type of privileges do you want to give your developers in this environment? In other words, do you want to allow your developers to work with admin privileges, or do you want one developer with admin rights and the other developers requesting access from that person?
  • Should your developers begin creating test plans along with source code documentation at this stage, or wait until the code reaches the Quality Assurance (QA) platform?

By asking and answering these questions, you, as the programming manager, will keep a tighter rein on what is going on in your Dev environment. Problems created in Dev will turn into problems you face down the road, so get input from your team in advance. If your team needs production data to test their changes, make sure your DBA gets them production data. Make it one of your top priorities to keep the Dev environment in sound condition.

Environment #2: Quality Assurance

After the development work has been completed, changes in your code will be promoted to your QA platform. Here's where your dedicated test team will perform the tests necessary to satisfy your test plans. Once the changes pass testing, they can be promoted to the next environment.

If it has not already been completed, a test plan should be completed for the QA environment to document what has changed and what needs to be tested. It's highly advantageous for the development team and the testing team to work together at this point. The developers will know, and hopefully have documented, the changes that have occurred. The test team, having an intimate knowledge of the system, will have the insight based on the developer's changes to know what to test.

It's important to develop a policy that requires the development team and test team to meet and devise a test plan. Having members of both parties in a room to discuss the changes made and what needs to be tested provides more thorough results than one team or the other creating the test plan in its entirety.

Once the test plan has been decided upon, it should be recorded in your change management process. The test plan should include clean test scenarios and the desired outcome of those scenarios. Amendments to the test plan can be made as necessary, but only if both sides agree upon the changes. As the plan is tested, new scenarios will present themselves, and bugs will be uncovered. Document these changes in the test plan log, and to include the relevant data which caused the scenarios. Any detail that will allow the developer to quickly uncover the problem should be the goal of the test team. After all, both teams are interested in the same goal: flawless software. This process should repeat as necessary until the test team has satisfied the requirements of the test plan.

Environment #3: Staging

Many IT shops overlook the staging environment, preferring to promote changes directly from QA to Production. Don’t make that mistake. This environment should be the final stop for code before it is promoted to your production environment, so take advantage of the opportunity to test any changes here.

Editor's Picks

Free Newsletters, In your Inbox