Separate Environments Needed for Development

When I worked in a big company, these things are so obvious and I never really paid much attentions.

Having separate environment is so basic.  However, it requires some efforts to make people understand these requirements.

Here are the environments required for different purposes:

1. Development Env

• Dev team owns this. Ops may create it for Dev
• Developers have full access.
• Dev perform unit testing in this env
• Backup may be required so when Dev does something that may affect each other, we can restore to a clean env
• Creating such env from and old QA env, or refresh from QA env, so Dev can have some testing data is a good practice.

2. QA Environments

• Ops team creates it for QA
• Builds are applied to QA env for testing

There are various QA environments:

2.1 Feature development
Apply the latest builds for QA testing

• QA should run the testing workflow in the env.
• Ideally, Dev should not be granted with the permission to change anything directly 
• QA may need Dev and Ops team's help to apply Hot Fix or Unblocking QA.
• A good practice is to patch this env constantly enough without blocking or distracting QA from testing.
• Each build should have a list of features available and bug fixes included
• Build cycles can be determined ahead and coordinated among QA and Dev

We may have much such environments and each has its own build cycles if multiple branches / code lines are open.

2.2 Release Candidate

• This env does not have to be a separate env but this is an important concept.
• Once the code is almost ready for release, you start the release candidate process.
• Release Candidate is different from the regular build cycles since whether we have another RC build is determined by the quality and thresholds.  Each build is a candidate to be released.
• Some of items that are included in the regular builds are removed.
• The code may be checked in to the release branch.

Release will be taken from this env.

2.3 Performance Testing

There are special requirements for building these env.

3. Maintenance Environments

• Each customer release should have a corresponding env.
• Support, QA, Dev can use this env to reproduce and investigate the customer issues.
• Some organization may make such environment as an On-Demand env.
• You can build VMs as a library and bring the specific env for a given release up when necessary.
• There are unpatched or patched env
• Even the patched env, there are different patching levels.

4. Sales Demo Env