Home > SharePoint > Automating SharePoint build and deployment–Part 4 : Putting it together

Automating SharePoint build and deployment–Part 4 : Putting it together

This is the fourth, and probably final, in a multipart post about automating the build and deployment of SharePoint solutions.  The other blog posts are:

In this post we will put all these bits together to form one process from check-in to deployed solution.  Again as in the rest of this series this post is going focus on the principles behind this task, and how we went about it.  It is not going to give any code.

The parts

So far we have built an automatic deployment script, got automated builds happening that build the package for deployment.  Now we need to get the automated build triggering a deployment into a staging or test environment.

We could use the lab management features of TFS Team Build to handle this, and that would be good way of going.  But the approach we decided to use was chosen as the only dependant tool is PowerShell, the other active components can be replaced with anything that will do that task, which there are a few to choose from.

For our team, in order to leverage the work that had been done by other teams just before us we decided to use TFS Deployer to launch the deployment based on changes to the build quality.

PowerShell Remoting

In order to allow TFS Deployer to do its job we need to enable PowerShell remoting from the build server (as the client) and our target SharePoint server (as the server). 

To setup the SharePoint server open an elevated PowerShell prompt and enter the following commands:

Enable-PSRemoting -force
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000
Enable-WSManCredSSP -Role Server

This script enables remoting, increases the size of the memory available and then allows the server to delegate authentication to another server.   This enables our deployment script to issue commands on other parts of the farm if required.

The build server is our client so there is a little more work to do from the client.

# Enable Powershell remoting on server
$SharePointServer = "SharePointServer"
Enable-PSRemoting -force
Set-Item -force WSMan:\localhost\Client\TrustedHosts $SharePointServer
Restart-Service winrm

# Enable client to delegate credentials to the a server 
Enable-WSManCredSSP –Role Client –DelegateComputer $SharePointServer

#Also need to edit Group Policy to enable Credential Delegation

Further information on this entire process can be found at Keith Hill’s blog http://rkeithhill.wordpress.com/2009/05/02/powershell-v2-remoting-on-workgroup-joined-computers-%E2%80%93-yes-it-can-be-done/.

TFS Deployer – The agent in the middle

TFS Deployer is the tool we have chosen, it is not the only one, to detect the change in the Build Quality and launch the scripted deployment on the chosen environment.

TFS Deployer had got a good set of instructions on their project site.  To simply our environments we run TFS Deployer on the build server.

In order to simplify the process for our many clients and projects we have TFS Deployer call a generic script that first copies the project specific deployment, after interrogating the $TfsDeployerBuildDetail object for the location of the files.  It then calls that deployment script to execute the deployment.

The project specific script file is also reasonably generic.  It first copies the packaged output (see previous posts) to the target server.  It then remotely extracts the files and executes the deployment scripts from inside that package.  Of course, in this scenario we know all the parameters that need to be passed so we can conveniently bypass any prompting by supplying all the parameters needed.


That ends the series.  Unfortunately it has been code light, as I was working through the process and trying to capture the philosophies rather than the actual mechanism.  Hopefully you have learnt something from reading these posts and picked up a few tips along the way. 

As stated in the first post the purpose of this series was to put together and understand our build framework and requirements so that I could build a new version using the TFS Build workflow mechanism.  I believe I now have that understanding, so I can start that work.  Perhaps doing that work will lead to a few more blog posts in the future.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: