Pilots, Proof of Concepts, Test, and Pre Production Environments
Although you may not find many references to dev, test, staging, environments, these are critical to large deployments. Even in the commodity type space where you are simply hosting the out of the box SharePoint code, it still very important if not critical to have a "test" environment where you can validate that the service pack installs, and the steps you follow work, and most important of all it works with your environment. If there's a user error in the install how much better is it that you learn it on a non critical environment. There are slight differences to all these various stages to deployment. Some more critical than others. Let me provide some insight into the differences. For the record I'm not saying every environment needs all of these, all the time, but they should be considered and incorporated into your planning at various stages. Much of these deployments can be served by virtual environments, but when it comes to perf and figuring out load balancing and some elements to clustering it is helpful to have hardware you can use. I've been in some environments where this is a check out process where hardware or virtual images can be allocated temporarily during that phase of the project. More and more I do expect to see environments to move to virtual, but as with anything testing is a major element and even when doing things virtually you'll find that RAM and CPU are still important elements, so you can't scrimp.
Proof of Concept
Many proof of concepts happen during the sales or sometime before the aquisition of the licenses. Maybe it was an IT deployment of the software that convinced the business that they wanted to do a larger one or a successful deployment of a departmental solution that woke up someone up the chain to the value. Whatever it is a proof of concept allows people to see the functionality and maybe even test out. If you want to know if the BDC (business data catalog) will connect to your SAP or X CRM and pull in the right records to make it easier to search and pull up customer records, you'll likely want to do or see a proof of concept.
Other proof of concepts even happen in MTC's throughout the world. Customers want to see if they can really have a million items in a list and see how indexing and search perform for a large digital imaging implementation as an example. Sometimes they are not cheap, but not only does it provide the answers with guidance, it can save the company money on seeing that the solution does or does not work as expected.
Even within a business, IT may want to do a POC to determine the right hardware to start with. If during the POC they find that 8 GB of RAM adds much more scale than 4, they might just make the decision to purchase 8 GB of RAM with their multi core servers. Disaster Recovery is best determined in a POC rather than later figuring it out in prod.
Pilot
Some companies even have policies that there must be a pilot. What's a pilot? A pilot is what a service is before it goes live. An offering must go through this stage for all parties to accept it. Parties such as support, operations, engineering, and the business (likely the most important group in this case). The business may be represented by corporate communications / marketing or HR. Even in a simple hosting of "team sites" it's important to validate that quotas are meeting peoples needs and all the essentials are there. Imagine that a common file type is blocked that the business uses. To go full scale with it could mean that you would have unimagined support burdens. That's what support is trying to get out of this. If we could get a sample representation of 10% of our company and get a real good cross cut then not only will we get a sampling of what type of issues we get, but we can extrapolate the support needs, the call volume, allowing for FAQs to be created, and the ability to staff up as needed. Tons of benefit to this team.
Operations gets the ability to see how the hardware will perform under a representative sampling. Note of course it's not linear scale, but with a representative sampling they can see what features are being excersized. Maybe they'll find out that Excel services isn't needed for all site collections, only the finance team and the treasury care about it (as an example). Maybe they'll find out that they didn't configure the crawl account properly or that Kerberos isn't working as expected due to either a misconfiguration or lack of installed service pack. There really is a lot that ops can learn just getting their feet wet and making sure the new System Center Ops packs they downloaded are catching the errors and they know how to deal with the noise or lack of noise and dial it appropriately.
The business is looking to see that it meets the functionality as expected. Expect scope creap. "What do you mean there are no track backs on the blogs!" Lists only have black text, I want this column, red and blinking. Stuff like that. I'm sure you've heard it all. Not only is it a chance for everyone to get their feet wet before the larger wave hits, it gives the service management a chance to meet with the business to lay out plans for further information on the vision and direction of where they plan to take the platform in the company. Scope in the beginning may simply get them to this point where they can do acceptance and further verification of addressing specific business needs. Not every environment is about simply getting it up, it's about getting the business using it and adopting it to address processes and optimize end user productivity. You know all that jazz about making people more productive. If you think it's going to be easier to see how that (TCO) works in an enterprise wide deployment you're looking at some reports I haven't seen. You can see how it works with a specific department, team or business unit much easier when you work directly with them and setup the specific ways the team will use it replacing the process or adding efficiency to the existing process.
SharePoint was described as plastic to me the other day. If SharePoint is plastic that means it can meld to your business needs, but to do that you need to know what shape it needs to take place. You have to a have a vision of what this mold looks like. Do you have a handy jello mold or are you looking for me to provide you one. :)
Dev
Never do dev in production. Let me say that again. If it's really a production environment where you have real production users don't do dev in production. You shouldn't need a list of why, but let me give you a few. When a dev finishes a solution and deploys it, it requires an IISReset or more precisely an app pool recycle. Developers will go with the IISReset since it meets their bill, they won't think about what else is running on the server (no offense devs :) ).
The developers will thank you in the long run if not the short run for having a separate environment where they can comfortably try out things without the risk of affecting production users or customers. Devs don't want to hurt anyone. They just want to build their solutions in peace. Then they want the IT pro to push it to production, and for everyone to be happy. Unfortunately the shorter the dev to production the more likely it will be that their code will hurt someone. If it's on top of production, then people will be sad and the dev will get blamed for the sadness. I'm obviously simplifying the situation, but he'll get blamed for any memory leaks and perf issues and the IT Pro will also be hating life trying to troubleshoot while the platform is changing underneath him. He's looking for stability and to reduce the moving parts to troubleshoot.
The ideal scenario is where the devs may each have their own dev image or environment (whatever that is) where they can do their thing and bring them together in a common dev environment, which would then get propped to test where the testers bang on it, then back to dev, or out to a UAT or user acceptance environment or staging and after acceptance to production.
Test
Essential to a true development lifecycle is a test environment. Even if you don't have testers, it gives the IT Pro a chance to see how the propegation of code works. Someone does need to bang on it. The dev should be writing some simple how it should work type outline. That way people can verify that it works. It gives change management a chance to understand what's moving and let it bake in. A lot of documentation happens during this phase. Support and operations even might be engaged to check things out and start to establish support or operational processes around the new functionality. Does it need to be monitored, does it need an FAQ item?
The difference between a UAT and Test environment is test is an IT only platform. Only the techies are looking at it. It's a good place to test out a service pack, patch, or QFE. If it's physical hardware it's a good place to do perf testing on code as it goes out. If it's virtual you might have to wait.
UAT (User Acceptance Testing)
The goals with a user acceptance environment is to both get user feedback and to have it really feel like a preproduction environment. This is the closest thing to production. Having this be a near mirror of your production environment, possibly even a backup/restore essentially allows you to validate the code prior to release. Bringing together the code changes, service packs, and the content. It will really happen in production, but you want to have an environment where you can see it happen. The business may have goals here, IT will obviously have goals here as well.
I commonly see these various environments be used for restores. Do you have a restore environment?
Conclusion
It still amazes me when I find environments that are missing this idea of pre production a very critical step in deployments. Here are some examples of pre production environments along with some examples and potential goals. Make sure you have this all understood before you make this critical path. It's not about making deployments take longer, just more stable, reliable, and validated.
