TFS2010 & Continious Integration

Good Posts
http://sptechpoint.wordpress.com/2011/03/31/improving-the-quality-of-your-custom-sharepoint-2010-solutions-via-continues-integrationci-with-team-foundation-server-2010/

Chris O'Brien's has great articles on ALM that are easy to follow http://www.sharepointnutsandbolts.com/

DTAP for Office 365

Overview: Someone has asked me about DTAP environment's for Office 365 after reading my last post on DTAP for SharePoint. I should only comment on SharePoint Online's DTAP setup but the simple answer for Office 365 is to create a separate Office 365 account for each of your DTAP environments. So I would have at least 2 or 3 environments hosted on Office 365. In order of priority: Production, UAT, Pre-production, Testing. Development is done locally so CI and development machines are on-premise. SharePoint Online should use DTAP roughly as outline below.

SharePoint Online DTAP:
SharePoint 365 development should be done using a local development solutions using "SharePoint Sandbox Solutions" as this is as close to SP365 as you can get on a development environment. You can use a solution validator (as provided by multiple vendors & MS) or write your own to ensure your wsp deployment files meet all the additional SP365 requirements.
My Order would be:

1. Development Environment - local Sp2010 dev machine where all code is deployed via wsps as a SharePoint Sandbox solution. On-premise hosted.
2. Continuous Integration Environment - perform daily builds of TFS controlled code, TFS code must comply to the custom solution validator that will verify the code will run on SP Online. Candidate for removal as value can be fairly low in smaller deployments. On-premise hosted.
3. UAT, testing and pre-production - for a small farm I would make this the environment as this will be identical to the setup of production, larger implementations could have 3 separate environments. This machine. Office 365 hosted.
4. Production - only perform solution deployments once it has been tested on the pre-production environment.

Summary: Just because you are using the cloud, you should still follow good change control practices. You need to have more than a developer doing his best guess while deploying directly onto your SharePoint online production environment.

Additioanl Info:
Alan Richard's article on Lync 2010 via Office online for messaging, voice and video calls and meeting conferences

DTAP for SharePoint

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. 

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.