Continues integration is a critical process in modern day product development for improving the quality of your solution from 1st Sprint (iteration) of your product development if you are following an agile approach like Scrum. This allows you to detect and rectify the issues in your solution early, which increases the chances of success without having to go through painful integration issues and surprises at the last minute in your product development cycle.
How does it improve the quality of my custom SharePoint solution?
Well, if you have a mature fully automated continues build (CI build) and a Nightly build you are on the right path and your SharePoint development team enjoys the following in every sprint.
- It enforces you to promote the code from Dev -> Test-> Staging -> Production in the correct way in the first place. Otherwise automation will not be possible.
- Every code check in by a developer will kick-off an automated code validation, run unit tests (if any) and build the SharePoint solution (.wsp files) in the Team foundation server.
- A Nightly build will do every thing in step 2 plus Add, Deploy and Activate your SharePoint solution packages into your test farm and can run automated coded UI tests and automated load tests (if any) for you.
here is the sketch workflow.
Why was this approach not so common in SharePoint Development?
The Lack of SharePoint development tooling support with VS2008 contributed significantly. This is also coupled with the natural complexity that arises when you develop on a platform rather than a development Framework. When it comes to SharePoint development, you may not necessarily develop with Visual Studio environment. You can develop quite powerful collaborative solutions and branding work with SharePoint Designer as no code solutions. But unless we convert those customisations into solution artefacts we will not be able to cleanly source control and maintain the solutions which breaks the fundamental concept of Application Lifecycle Management (ALM).
SharePoint 2010 has evolved and positioned as a single unified platform for most originations playing a mission critical role for day to day operations. With the introduction of Business connectivity Service (BCS), Client OM, Sandbox solutions, WCF based Service Applications and Claims based authentication SharePoint 2010 has also significantly evolved as application development platform which opens up a number of extensibility options for the developers.
We also have integrated set of tools built into Visual Studio 2010 for SharePoint Development. So the challenge is how to use these tools effectively and efficiently in a team based environment to build your product or solution and deploy into those shared mission critical environments confidently with consistent quality? This post describes how to implement an automated continues build with the help of following tools to validate, build and deploy SharePoint solutions.
Step1: We need to get all your customisations as solution artefacts. Reverse engineer your SharePoint designer customisations and featurize them. CKSDev Branding SPI can help you to deploy master pages and CSS as Features. Save all SharePoint Designer authored workflows as Reusable workflows as .wsp from SharePoint Designer and bring it to Visual Studio environment.
: Create a new Team project and add your solution into source control under TFS. For the purpose of this post I am using a simple VS2010 solution name SPHelloWorld. For Code analysis, SPDisposeCheck ruleset needs to be in source control and can be shared across multiple projects with in your repository.
Step3: Enable Code analysis for you solution via project poperties and select SPDisposeCheck RuleSet from your local TFS workspace as shown below.
Step4: Note that Code Analysis now runs SPDisposeCheck rules as part of compilation and both Dispose and Do not Dispose rules are fired when detecting the poor code.
Step5: Now open the Default Build Template for the project. We are going to extend the default build definition file to deploy our solution to the Test SharePoint Farm remotely. TFS 2010 is using windows workflow foundation 4 based
.xaml template. Drag the activities from the left side bar tool box and assemble the activities as shown below just after packaging is finished.
The high level tasks performed by this segment of the workflow are
- Build the Solution
- Run Code Analysis with SPDisposeCheck on the TFS Server. If this code analysis fails our build would fail at this point.
- Create .wsp solution package
- Check the user specified deployment flag (This is a work initiation parameter)
- Write a log message to the log file
- Map a Admin share drive to the Target SharePoint Server (Test Farm) with the user specified credentials.
- SET the STSADM path on the target server
- Stop V4 Admin service in the target farm. (This uses PSEXEC to remotely execute STSADM on the target server)
- Copy each .wsp file to the target SharePoint server and add, deploy and execute the timer job in user specified sequence.
- Finally turn on the V4 Admin timer service.
If you are interested the customised TFS2010 workflow template for building and deploying .wsp solutions can be downloaded from my SkyDrive here
Now define the additional parameters required for the workflow initiation that needs to be supplied by the user when starting a new Team build.
Set activity properties for each activity. As a sample I’ve shown below the properties set for the “Add solution” InvokeProcess workflow activity. Once all properties are set WF4 validates your workflow. Once all validations are passed, check-in your custom build definition template into TFS.
Author a new Build definition based on our updated workflow template.
Some important parameters that you need to set are shown below.
: It’s time to Queue a new Build. Now assume a scenario where the developer rushes to check-in by overriding the Check-in Policies set by the build master.
and here is the result : TFS build agent decided to fail your build because your code did not pass the code analysis. No .wsp’s produced.
So the developer now fixes the code with proper disposing as shown below and checks-in the code again.
And after few seconds we get this TFS Build status. All green!
Opening the build log gives us the workflow execution log as shown below. Note how STSADM has been invoked remotely via psexec.exe on the TFS build agent.
and see below the end result in the central admin in our test SharePoint Farm.
On a final note “the right tools make all the difference”. But tooling in itself may not help you to build a quality product. The process matters. TFS 2010 supports you with your chosen process and allows you to tailor the default process templates if required. You have the chance to select the process template when you create a new Team project as shown below. I highly encourage you to check out the new “Microsoft Visual Studio Scrum 1.0” template. This template has been co-developed by Microsoft in collaboration with the Scrum community. The template guides you with scrum based agile product development. I've highlighted a few below.
- Creating effective user stories
- Creating prioritizing grooming product backlog
- Agile estimation and Sprint planning
- Scrum artefacts such as sprint burndown and release burndown chart
And here is the high level process behind the template.
The correct tools coupled with the correct process will take your product/solution to the next level faster and smoother and make you a successful SharePoint developer and hence a successful product/solution delivery Team.
Where to go from here?