Office and SharePoint 2013 Continuous Integration Using Team Foundation Service and Office 365
When your team is collaborating on a project, you need a regular and reliable development process to ensure smooth delivery while maintaining high quality. This process typically includes frequent integrations from team members, regular builds, and testing against the new build to measure quality. Continuous integration is a great way to manage this kind of process.
In SharePoint development, continuous integration has historically meant setting up a SharePoint server together with a build server in your organization to get regular builds and run tests on it. With the launch of Office 365 and Team Foundation Service (TFS), this onerous setup is no longer required. Instead, you can simply sign-up for each of these services. In this post, we’ll walk through configuring these services so that you can enable continuous integration for your projects.
Get an Office 365 Developer account
To develop, test, and deploy apps for Office and SharePoint, you can sign up for an Office 365 Developer Site. Follow the instructions in Sign up for an Office 365 Developer Site to start your free trial.
Get your Team Foundation Service account
Team Foundation Service lets you plan projects, collaborate with your team, and manage your code online from anywhere without needing to set up your own Team Foundation server. Instead, it stores your source code and work items in the cloud. You can check your code directly into the cloud through Team Foundation Service using Visual Studio or Eclipse, and you can manage your work items and bugs in the browser.
Team Foundation Service offers a free plan for up to five users per account. It provides features including version control (through Team Foundation Version Control or Git), work item tracking, agile planning tools, feedback management, and build and test management. Go to the Team Foundation Service site to get started. The cloud-hosted build service on Team Foundation Service is preconfigured with the right environment for apps for Office and SharePoint 2013, and also for SharePoint 2010 or 2013 farm and sandboxed solutions.
Note that the build machines on Team Foundation Service can access only public visible SharePoint (and web) servers. This means that your target SharePoint site should be either on Office 365 (for apps) or on a SharePoint virtual machine (VM) in the cloud (for SharePoint farm and sandboxed solutions).
Start your continuous integration on Team Foundation Service
Earlier this year, we shipped Office Developer Tools for Visual Studio 2012 for developing apps for Office and SharePoint 2013. At the same time, we also published a CodePlex project to support continuous integration for Office and SharePoint 2013 projects using TFS 2012: see Office/SharePoint 2013 Continuous Integration with TFS 2012.
This CodePlex project contains a set of Windows PowerShell scripts for deployment and a custom TFS Build workflow template, which lets you build and deploy (for testing purpose) apps for Office and SharePoint 2013 projects using TFS 2012. Here’s all you need to do:
- Check the files (deployment scripts and workflow template) into the root of your source control team project.
- Update the parameters.ps1 file in the project to specify the parameters used for deployment, including your SharePoint site URL and your credentials.
- Create a new build definition using OfficeToolsAppTemplate.xaml, and specify the corresponding deployment scripts offered in the CodePlex project. The build definition also lets you specify what projects to build and when to trigger a build.
For detailed instructions, see the Documentation page of the CodePlex project.
Using these resources, you will be able to do continuous integration for Office and SharePoint 2013 projects. Depending on your project, you may find these tips helpful:
- Project contains a NuGet package
If the NuGet package delivers some assemblies that your project references (for example, you use the EntityFramework NuGet package in the web project of your app for SharePoint, which references EntityFramework.dll), make sure the assemblies are checked into source control. You can find the assemblies from the NuGet package in the “packages” folder under your solution folder. - Autohosted app for SharePoint includes a SQL Database project
This is a known issue in the Office Developer Tools for Visual Studio 2012. If you are using Team Foundation Service, the TFS build service will copy the .dacpac file built from the SQL Database project to a different folder defined in the app for SharePoint project target file. To work around this, add the following code at the end of your app project file:
<Target Name="xxx" BeforeTargets="PackageSharePointApp">
<PropertyGroup>
<SqlPackage>%OutDir%\YourDacpacName.dacpac</SqlPackage>
</PropertyGroup>
</Target>
Project is a SharePoint farm or sandboxed solution
Continuous integration is also supported for SharePoint farm and sandboxed solutions. Hosting SharePoint in a VM in Windows Azure is a great way to enable continuous integration with Team Foundation Service because it is hosted outside of a firewall. Check out the Downloads page for instructions about configuration.Although the build service on Team Foundation Service has been configured with essential SharePoint assemblies, your farm solutions may contain some assemblies that are not available in the default build environment because solutions can actually reference any assembly. In that case, you will need to check those missing assemblies into the source control with your project. You will know that your project is in this state if an assembly that you reference in your SharePoint farm solution cannot be found (and Team Foundation Service throws the “System.IO.FileNotFoundException: Could not load file or assembly” exception when you build the project).
I hope that you will give continuous integration a try. Like always, I’d love to hear from you. If you have a suggestion, question, bug, or anything else, please don’t hesitate to let me know!
Have fun!