From an IT (information technology) standpoint, having these disparate systems for making changes, testing changes, checking that the changes are correct is an attempt to make sure that your PRODUCTION system remains protected from human and mechanical error.
DEVelopment is usually used by the developers (ie. programmers, configurators, etc) as they work on individual
programs, apply program patches or updates, or turn (configure) new functionality.
Most, if not ALL, changes are done here. Dev will usually contain a much smaller set of data than is in production.
The completed changes are then "migrated" to QA.
QA (AKA Quality Assurance) will usually have a larger amount of data and generally NO changes or updates are directly done in this environment. It is used by both the developers (IT) and selected "users" to test the migrated changes in a pseudo production environment to see if the changes actually work correctly.
QA and the STAGE environments may, in some sites, be one and the same. Or they may be separate platforms.
A STAGE environment can have different roles depending on the shop.
1) It can be the QA/STAGE environment that has an exact copy of production which is used for both QA and system testing (testing of the system when alot of updates/changes or upgrade is going to go into production).
2) It may not have much data at all but is a place to keep track of the final changes that are going to go into PRODUCTION.
3) It may be an exact copy of PRODUCTION in both hardware and software which maybe have all the changes that are happening in production being applied to it in a delayed fashion. Should something happen in production (ie hardware failure, software failure, person failure (Ooops - just deleted all of the product pricing)), the STAGE environment can be brought forth into a PRODUCTION mode.
Generally, only after the changes in the QA/Stage system have been "signed off" by the programmer, user (business), supervisor authority, etc., will the changes be migrated to PRODUCTION.
PRODUCTION is the actual environment used by the company, institution, organization, etc for it’s processing needs.
You may also see a few other environments as well...
SANDBOX - Another copy of Development, QA, or Production to test major upgrades of hardware or software before applying it to the DEV, QA/STAGE, and PRODUCTION platforms.
DISASTER RECOVERY - This may be an exact copy of Production (like #3 stage above) but may be completely in another area/region from where the primary data center is. It will probably be on another power and communication grid. It'll be the goto site in case the primary site goes down and may even be having the current changes that are happening in PRODUCTION being applied to it in a synchronous or delayed fashion.
There is an overview answer since many "shops" may have a plethora of different environments and architecture schemes based on their requirements but the DEV, QA/STAGE, PRODUCTION is the most basic form.
All in all, these environments are used try to keep the PRODUCTION environment protected and stable as possible.
P.S. Doesn’t always work.
DEVelopment is usually used by the developers (ie. programmers, configurators, etc) as they work on individual
programs, apply program patches or updates, or turn (configure) new functionality.
Most, if not ALL, changes are done here. Dev will usually contain a much smaller set of data than is in production.
The completed changes are then "migrated" to QA.
QA (AKA Quality Assurance) will usually have a larger amount of data and generally NO changes or updates are directly done in this environment. It is used by both the developers (IT) and selected "users" to test the migrated changes in a pseudo production environment to see if the changes actually work correctly.
QA and the STAGE environments may, in some sites, be one and the same. Or they may be separate platforms.
A STAGE environment can have different roles depending on the shop.
1) It can be the QA/STAGE environment that has an exact copy of production which is used for both QA and system testing (testing of the system when alot of updates/changes or upgrade is going to go into production).
2) It may not have much data at all but is a place to keep track of the final changes that are going to go into PRODUCTION.
3) It may be an exact copy of PRODUCTION in both hardware and software which maybe have all the changes that are happening in production being applied to it in a delayed fashion. Should something happen in production (ie hardware failure, software failure, person failure (Ooops - just deleted all of the product pricing)), the STAGE environment can be brought forth into a PRODUCTION mode.
Generally, only after the changes in the QA/Stage system have been "signed off" by the programmer, user (business), supervisor authority, etc., will the changes be migrated to PRODUCTION.
PRODUCTION is the actual environment used by the company, institution, organization, etc for it’s processing needs.
You may also see a few other environments as well...
SANDBOX - Another copy of Development, QA, or Production to test major upgrades of hardware or software before applying it to the DEV, QA/STAGE, and PRODUCTION platforms.
DISASTER RECOVERY - This may be an exact copy of Production (like #3 stage above) but may be completely in another area/region from where the primary data center is. It will probably be on another power and communication grid. It'll be the goto site in case the primary site goes down and may even be having the current changes that are happening in PRODUCTION being applied to it in a synchronous or delayed fashion.
There is an overview answer since many "shops" may have a plethora of different environments and architecture schemes based on their requirements but the DEV, QA/STAGE, PRODUCTION is the most basic form.
All in all, these environments are used try to keep the PRODUCTION environment protected and stable as possible.
P.S. Doesn’t always work.
No comments:
Post a Comment