Social Enterprise optimize

Poll: How many stages are in your deployment environment?

Developers, do you have a one-, two-, or three-stage development environment? Answer this question in our quick poll.

For much of my career, I have not had the common three-stage deployment environment (development, staging, and production) available to me. Typically, my local machine would be "development," and then it would get deployed to production. It was no one's fault, really, just how things worked out (mainly because of budget and time). In the situations when I did have all three stages, I wished that I didn't because deployments were so painful -- each extra environment made me even more miserable.

Lately, I've had the luxury of working with more environments that have been set up more robustly, and a deployment story that I find enjoyable. As a result, I am finally receiving the rewards promised by this environment.

J.Ja

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

About

Justin James is the Lead Architect for Conigent.

26 comments
pjboyles
pjboyles

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*

Tuno85
Tuno85

Local Development (Integration) Test Acceptation Production

lhegler-admin
lhegler-admin

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.

sissy sue
sissy sue

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.

mandrake64
mandrake64

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.

StevenDDeacon
StevenDDeacon

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

sumbloke
sumbloke

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

Rexxrally
Rexxrally

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

adam.howard500
adam.howard500

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.

jim.butcher
jim.butcher

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.

Sterling chip Camden
Sterling chip Camden

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.

Slayer_
Slayer_

Support/Report -> BA assess -> BA assigned -> Dev assess -> Dev assigned -> Internal testing -> Production Upload -> User acceptance testing -> Deployment

todd_dsm
todd_dsm

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, [i]openness of communication lines and general competence[/i], 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.

adjustable_pliers
adjustable_pliers

With the comments so far, I'm glad to know my setup is typical: 1.) Development 2.) Quality Assurance 3.) Staging 4.) Production

bill@tarket.net
bill@tarket.net

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).

Longin15v
Longin15v

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/

Longin15v
Longin15v

In the situations when I did have all three stages, I wished that I didn’t because deployments were so painful — each extra environment made me even more miserable. yahoo.com

Skruis
Skruis

Leading us in to your next article Justin?

keely2001
keely2001

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.

irperez
irperez

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.

mikewor
mikewor

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.

RudHud
RudHud

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.

Beejer
Beejer

Development, Testing, Acceptance, Production

todd_dsm
todd_dsm

No seriously, this seems to be the most popular - seriously; I voted for this one.

jmiceli
jmiceli

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.