Discussion on:
View:
Show:
Development
Test before release to customer
Customer testing
Production
The "customer" is whoever the work is being done for -- human resources, asset management, etc.
A major change (not necessarily a big project, either) will have a fifth environment for pre-production testing, built specially for the test to duplicate production exactly.
Test before release to customer
Customer testing
Production
The "customer" is whoever the work is being done for -- human resources, asset management, etc.
A major change (not necessarily a big project, either) will have a fifth environment for pre-production testing, built specially for the test to duplicate production exactly.
We also have four distinct environments as follows:
1. Development - strictly developer access and it is our playground. If we crash the server, then so be it.
2. Integration - this is a secondary development environment where the development efforts of multiple teams for products that work together end to end are put through their paces for more internal testing
3. Test - this is the first environment where client access is available for their testing. After Integration testing is completed, then the clients and our company Unit Test teams are able to hit the systems in a Production-like environment with similar data that has had the sensitive, identifying data obfuscated or encrypted. Developers have no access to this environment.
4. Production - full-blown production environment with client and support staff access only. Support staff has read-only access until issues arise, then work tickets are opened and access is granted using a series of SOX-compliant and audited methodologies for a pre-determined amount of time.
1. Development - strictly developer access and it is our playground. If we crash the server, then so be it.
2. Integration - this is a secondary development environment where the development efforts of multiple teams for products that work together end to end are put through their paces for more internal testing
3. Test - this is the first environment where client access is available for their testing. After Integration testing is completed, then the clients and our company Unit Test teams are able to hit the systems in a Production-like environment with similar data that has had the sensitive, identifying data obfuscated or encrypted. Developers have no access to this environment.
4. Production - full-blown production environment with client and support staff access only. Support staff has read-only access until issues arise, then work tickets are opened and access is granted using a series of SOX-compliant and audited methodologies for a pre-determined amount of time.
Same 5 stages as gene, but in a major organisation where they had to change every system when Value Added Tax (VAT) was introduced, a staging area was included before production to make sure everything still behaved when together.
Development, Test (Which consists of many 9 Manual Testing environments & 2 Automated Testing Environments), Staging, Production.
The reason we have so many test environments is due to Team Foundation Server's execution tracing ability, which requires 1 tester per environment. But this trace info is extremely helpful!
Everything is automated, from builds, to deployments, via TFS. Developers don't get involved with the deployments.
The reason we have so many test environments is due to Team Foundation Server's execution tracing ability, which requires 1 tester per environment. But this trace info is extremely helpful!
Everything is automated, from builds, to deployments, via TFS. Developers don't get involved with the deployments.
We have six stages. I develop desktop automations and solutions. I've included the customer request as a separate process. We work directly with them to determine if it warrants a request. Customer request -> Approval/Develop Requirements and Expectations -> Development -> Developer Side Testing -> Customer Side Testing -> Deployment.
In the situations when I did have all three stages, I wished that I didnt because deployments were so painful each extra environment made me even more miserable. yahoo.com
In the situations when I did have all three stages, I wished that I didnt because deployments were so painful each extra environment made me even more miserable http://yahoo.com/
In my current project we have, development (local), dev server, test, stage, & production. This is sometimes very painful due to Public and Private keys changing between environments. Also sometimes the project manager forces out of sequence deployments (straight to stage).
With the comments so far, I'm glad to know my setup is typical:
1.) Development
2.) Quality Assurance
3.) Staging
4.) Production
1.) Development
2.) Quality Assurance
3.) Staging
4.) Production
I don't do a lot of dev work on my own but when I'm playing with the big boys, they tend to use a four-teired approach that reflects the testing stages:
1) DEV (unit testing)
2) INT (you guessed it: integration testing)
3) SYS (system and UAT testing)
4) PROD (pilot & production)
Depending on 2 factors, openness of communication lines and general competence, environments, documentation, and schedule can be cut down by a lot without losing out on quality. On the other hand, if those 2 factors are miserably low then environments, documentation, and schedule should be reassessed and probably cranked up a notch so nothing gets missed.
I believe the general purpose behind so many different environments is environmental variables and integration points; code needs to be transferred from one stage to another to insure these foundational provisions. They tend not to be documented or observed much after setup; "we just use 'em". Moving to a new environment exposes these types of omissions.
1) DEV (unit testing)
2) INT (you guessed it: integration testing)
3) SYS (system and UAT testing)
4) PROD (pilot & production)
Depending on 2 factors, openness of communication lines and general competence, environments, documentation, and schedule can be cut down by a lot without losing out on quality. On the other hand, if those 2 factors are miserably low then environments, documentation, and schedule should be reassessed and probably cranked up a notch so nothing gets missed.
I believe the general purpose behind so many different environments is environmental variables and integration points; code needs to be transferred from one stage to another to insure these foundational provisions. They tend not to be documented or observed much after setup; "we just use 'em". Moving to a new environment exposes these types of omissions.
Support/Report -> BA assess -> BA assigned -> Dev assess -> Dev assigned -> Internal testing -> Production Upload -> User acceptance testing -> Deployment
Some have 5 stages: my dev system -> their source control -> QA -> beta test -> deploy
One has only two: my system -> their production system.
Lots of variations in between.
One has only two: my system -> their production system.
Lots of variations in between.
I'm in an enterprise environment as well, and we have DEV for development and unit testing, QA ifor functional and integration testing by our Quality Assurance team, User Acceptance Testng (UAT) for additional performance and integration testing against "almost production" data by our Quality Assurance team and by client representatives in many cases, and then finally production.
Other shops I've worked in have generally been 3 stages or less. I find the UAT stage here to actually be a welcome addition, as it identifies the problems where the clients didn't get the requirements right the first time and saves the pain of issues in production.
Other shops I've worked in have generally been 3 stages or less. I find the UAT stage here to actually be a welcome addition, as it identifies the problems where the clients didn't get the requirements right the first time and saves the pain of issues in production.
Development - where daily work is done. Sometimes a tester will stray into it if there is some confusion about how something is supposed to work.
Alpha - developers move code to here for initial testing. At the same time they move updated code files to a "move" folder for later movement.
Beta - Systems department takes over to move the code here. This is primarily to ensure that they can do the move properly.
Production - what the customers use.
Alpha - developers move code to here for initial testing. At the same time they move updated code files to a "move" folder for later movement.
Beta - Systems department takes over to move the code here. This is primarily to ensure that they can do the move properly.
Production - what the customers use.
Development - Developers do their thing and their initial unit and white box testing
QA - I.S. Testers perform functional, integration, usability, etc. testing. Our installation package is also built and used for this step to ensure it works as well
UAT - End User committees try out the application, and verify that it does what they want it to in their User Acceptance Testing. The Operations team uses the installation package to ensure there are no problems installing it on a (pseudo) Production server
Production - The official release to end users
QA - I.S. Testers perform functional, integration, usability, etc. testing. Our installation package is also built and used for this step to ensure it works as well
UAT - End User committees try out the application, and verify that it does what they want it to in their User Acceptance Testing. The Operations team uses the installation package to ensure there are no problems installing it on a (pseudo) Production server
Production - The official release to end users
We have 6 or 7 stages (depending on whether the developer does local PC coding or not)
(Local PC) -> DEV -> PIT (Product Integration Testing) -> SIT (System Integration Testing) -> SAF (System Assurance Facility) -> PST (Performance and Stress Testing) -> Production
(Local PC) -> DEV -> PIT (Product Integration Testing) -> SIT (System Integration Testing) -> SAF (System Assurance Facility) -> PST (Performance and Stress Testing) -> Production
From a system configuration management standpoint you should have a minimum of four autonomous Information Technology Infrastructure Integration Stacks.
1) Developer/Sandbox Unit Test Stack
2) Integration String Testing and Performance Tuning Stack
3) User Acceptance Testing and Training Stack
4) Production Environment Stack
1) Developer/Sandbox Unit Test Stack
2) Integration String Testing and Performance Tuning Stack
3) User Acceptance Testing and Training Stack
4) Production Environment Stack
Have only two stages with no staging. Prod environment is at oldest OS and database version, both at least 2 majors behind so development is a challenge. No luxury of a staging environment so have to make do. Staging though has immense benefits, the major one being catching bugs before they can do real damage.
Once a system is mature and most developers have left, 3 stages would be as many as would be required. Ay more will just add unnecessary complication.
Once a system is mature and most developers have left, 3 stages would be as many as would be required. Ay more will just add unnecessary complication.
Develop the application based upon requirements written by people who are not the subject-matter experts and who don't know the process. Develop the application on the manager's favorite "flavor of the month" platform (whether it's suitable or not). Discover in UAT that the product is completely unsatisfactory. Can the developer (because it's his fault, of course). Put the application on the back burner for a few months. Try again, using most of the same code and keeping the same platform. Struggle with it through testing and UAT. Roll it out into Production anyway.
No seriously, this seems to be the most popular - seriously; I voted for this one.
I don't develop programs very often, but when I do, I have the same issues Justin used to have. Lack of time and money forces me to use my computer for development. Once the new software is tested, it goes straight into production.
Since my responsibility is the OS, GPOs for client and people, Office applications and base application like .NET it is more regulated than the application teams.
1. New hardware, patch released, problem fix, new requirement, new version release, nice to haves, what couldn't be stuffed into the last release...
2. Development - completely isolated from production
3. Peer Review - Team review of work
4. Test - Migrates into test environment which mirrors production as closely as possible
5. If it is a component for a specific application team then initial smoke testing by the application team in test.
6. Certification - Separate certification team to ensure everything still works.
7. Application Certification - Tier one applications and select additional are checked to ensure changes do not break applications. Similar to UAT.
8. Change management - All the affected groups get a chance to review what was done, tested and make the final approval.
9. Pilot
10. Production
Then of course you get the "special projects" that skip a step or two. *sigh*
1. New hardware, patch released, problem fix, new requirement, new version release, nice to haves, what couldn't be stuffed into the last release...
2. Development - completely isolated from production
3. Peer Review - Team review of work
4. Test - Migrates into test environment which mirrors production as closely as possible
5. If it is a component for a specific application team then initial smoke testing by the application team in test.
6. Certification - Separate certification team to ensure everything still works.
7. Application Certification - Tier one applications and select additional are checked to ensure changes do not break applications. Similar to UAT.
8. Change management - All the affected groups get a chance to review what was done, tested and make the final approval.
9. Pilot
10. Production
Then of course you get the "special projects" that skip a step or two. *sigh*
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
