This post shows how to configure a TFS Team Build 2012 server with Team Foundation Service in the cloud, and how to create a basic build of a SharePoint 2013 provider hosted app.
This is part 1 of a series on ALM for SharePoint Apps.
I have been using the Team Foundation Service for quite awhile, and absolutely love it. It’s basically TFS in the cloud, allowing me to store all of my source without having to configure TFS myself, let alone manage the environment (patch it, troubleshoot it, etc). I am working on a project for a customer to show how to do ALM with SharePoint 2013 apps, so to save myself time I set up a TFS Build Server to connect with Team Foundation Service in the cloud.
This is the really easy part. Just go to http://tfs.visualstudio.com and sign up for a free account. There’s information about pricing, but it’s free for up to 5 users.
After you sign up, you will create a team project. I created a project called “ALMDemo”.
Click Create Project, and then navigate to the team project.
Once your account is created and you navigate to the team project, you will see a section on the right of the page to help you get started. There is a link to a beginner’s guide to connect Visual Studio 2012 to the TFS Service.
The Beginner’s Guide shows you how to create a project. Once the project is created, you just go to the project’s page and open a new instance of Visual Studio.
You can now use work item tracking and source code management from Visual Studio.
The builds that I am doing will involve some tools that I am creating for continuous integration (I’ll cover that in a subsequent post). Team Foundation Service includes a build controller, called the Hosted Build Controller. I could use the hosted build controller, but I need to customize things a bit so I’m creating my own build controller that connects to Team Foundation Service.
For my demos, I am using a virtual machine in Azure, but it could be a machine on your desktop or in a virtual machine that you host yourself. That’s the beauty here, if the hosted build controller isn’t enough or you really need to customize the build environment, then you can create a build machine that has whatever you need.
Install TFS. When it’s done, the configuration center is launched. Choose Configure Team Foundation Build Service then choose Start Wizard.
On the screen to choose a Team Project Collection, since I’ve already connected to Team Foundation Service in Visual Studio 2012, it picks up the project name. I just hit next.
It then asks how many agents to configure, I follow the advice where it says what is recommended and just leave the defaults.
We’re then asked if we want to use NETWORK SERVICE or if we want to use a domain account. I am going to use a domain account that I have in my lab environment.
To make sure all the settings are OK, I choose the Verify button on the next screen and I see everything looks OK.
Once it’s verified, I choose Configure and then watch the progress.
Once it succeeds, I can close the wizard.
Once it’s all done, I can see the build configuration and see that everything is running.
Yes, it’s that easy.
My build controller happens to be the same VM that I am developing SharePoint apps with, so the VM has the Office Developer Tools installed. Make sure that you have any pre-requisites installed on the build controller and that assemblies are available prior to builds. For more information on setting up the pre-requisites for a stand-alone build controller, see How to Build Office Developer Tools Projects with TFS Team Build 2012.
Now that we’ve added a build controller, we need some source for the build controller to actually build. I created a new App for SharePoint 2013 project.
My solution will use server to server for app authentication, and I’ve already configured my environment with the certificate and issuer ID.
Once the project is created, I add it to source control.
When I add to source control, I pick the team project that I created previously, called ALMDemo. I chose to create a new folder called ALMDemoApp just so I can easily see that this is the app folder.
Check in pending changes, and the project is now in source control.
In the Team Explorer pane, go to the Home section and click the Builds link.
We’ll create a new Build Definition. In the new build definition window, we are prompted to choose a build controller. You can use the Hosted Build Controller in Team Foundation Service, but in our case we’ll use our own build controller that we just created. I also tell it to send the build to a share rather than upload it to the server.
On the process tab, I’ll choose to include the switch to tell MSBuild to package the SharePoint app package, and I’ll tell MSBuild where to put the app deployment stuff, including the app package. I am going to show you the painful way to do this first, but we’ll see the correct way to do this in Part 4 – ALM for SharePoint Apps: Understanding Provider Hosted App Publishing. For now, let’s create a simple publishing profile. We'll use the full value for MSBuild Arguments:
/p:IsPackaging=true /p:PublishDir="\\sharepoint01\builds\AppOutput" /p:AppSpecificPublishOutputs=true
Click Save All in Visual Studio 2012.
Now we have everything out of the way, let’s test our build process so far. Right-click the build definition we just created and choose Queue New Build.
Accept defaults, click Queue, and then the build starts. If everything is working correctly, you will see that the build starts. Once it completes, we see the build report.
Finally, we go to the drop folder and see that the build did run, although we don’t see the app package yet.
Go to the Builds share that we specified in the MSBuild Arguments and you’ll see it there.
We’ll take a look at customizing this more in an upcoming blog post to include information on continuous integration as well as how to customize the build process for a provider-hosted app.
Team Foundation Service – http://tfs.visualstudio.com
How to Build Office Developer Tools Projects with TFS Team Build 2012. - http://msdn.microsoft.com/en-us/library/ff622991.aspx