Overview: Development, Test, Acceptance and Production (DTAP).
To implement SharePoint solutions it is a good idea to have DTAP environments. DTAP can be as simple as 4 environments but I would recommend 5 or more separate environments for SharePoint.
Development
The base development machines can be standalone VM's with self contained SQL databases, AD, FAST, and SharePoint. Additional software would include: InfoPath, SharePoint designer, U2U, Fiddler, firefox, IE8 and more. You should have TFS or a source control repository for all developers to check compiling code into.
Testing
This environment is a build release, it is stable so testers can perform testing against a specific build. Bugs should be documented (preferable in tied to source control changes).
Acceptance
End users should test the system pre go-live in this environment. This phase can also be split into 2 environments namely: Acceptance and pre-production environments. Used for user acceptance testing.
Production
This live system is only changed once the changes have gone thru change request management and have been deployed and tested on all the environments. Pre-production should be as close a copy of the production environment as possible. Production and pre-production must be kept as close as possible throughout the life time of the SharePoint farm.
Summary:
To implement SharePoint solutions it is a good idea to have DTAP environments. DTAP can be as simple as 4 environments but I would recommend 5 or more separate environments for SharePoint.
Development
The base development machines can be standalone VM's with self contained SQL databases, AD, FAST, and SharePoint. Additional software would include: InfoPath, SharePoint designer, U2U, Fiddler, firefox, IE8 and more. You should have TFS or a source control repository for all developers to check compiling code into.
Continuous Integration (CI)
This box can range from very simple to a complex complete tear down rebuild on a daily basis with unit test. At a minimum all code should be deployed daily. All changes to CI and subsequent environments should be deployed via wsp's and PowerShell scripts. Sometimes it is time efficient to write administration manual steps, this should be avoided where possible and if it is absolutely required, the documentation must be explicit and testable.Testing
This environment is a build release, it is stable so testers can perform testing against a specific build. Bugs should be documented (preferable in tied to source control changes).
Acceptance
End users should test the system pre go-live in this environment. This phase can also be split into 2 environments namely: Acceptance and pre-production environments. Used for user acceptance testing.
Production
This live system is only changed once the changes have gone thru change request management and have been deployed and tested on all the environments. Pre-production should be as close a copy of the production environment as possible. Production and pre-production must be kept as close as possible throughout the life time of the SharePoint farm.
Summary:
- Never do changes directly on the production environment.
- Build a formalised change control process for SharePoint.
- Minimum of 3 environments for small farms is my base guideline.
- Environment changes should be done using wsp's and PowerShell not the UI where possible
.
No comments:
Post a Comment