In this third part about SharePoint 2013 Apps with TFS 2012, I will talk about how you can deploy your package to your SharePoint 2013 (or SharePoint Online) instance. (Note that I’m using the “AutoHosted” App model) First you have to complete the steps described in my previous posts:
Assuming that this was no problem, you should have a build definition based on the “OfficeToolsAppTemplate” build process template (which you can download here). This should result in a build definition who will give you the following output:
Image may be NSFW.
Clik here to view.
That’s great. Now we want to deploy this App to our SharePoint instance. Good news, the build process template has everything available to achieve this. Once you have downloaded this build process template, you also have a folder called “DeployScripts“. Add this folder (and the content of it) to Source Control like. That’s it for now.
Image may be NSFW.
Clik here to view.
SharePoint requirements
Before we can deploy this App package, you need to have a “developer site“. Normally will already have this, because if you deploy your App directly from Visual Studio, you will also need this. You will have a site collection like:
Image may be NSFW.
Clik here to view.
A thing I can advise you is using a “custom” deployment account. There reason for that is that this account is required to be “defined” in a PowerShell script (including that password). As you can see in the previous screenshot, I have a user called “deploy” who is also an administrator of this development Site Collection.
On-prem Build Server requirements
On the Build Server, we will also need to verify some things. First of all, if you want to deploy to “SharePoint Online,” you need to have the SharePoint Online Management Shell installed. This will allow the deployment scripts to connect to your SharePoint online instance. You can easily test it using the “Connect-SPOService” command:
Image may be NSFW.
Clik here to view.
Next thing that you need to check is the account your TFS Build Service is using. If you installed the TFS Build Server using the “next-next-wizard”, your TFS Build Service account will be using “NT AUTHORITY\LocalService“. If you keep this by default, and you try to deploy your App, you will see the following error (been there!)
Image may be NSFW.
Clik here to view.
You need to change this account to a known user account so the deployment script can import the SharePoint module. In my case, I’m using a standard Windows Server 2012 Azure VM, and I simply use the ‘Administrator” account.
Image may be NSFW.
Clik here to view.
Configuring the deployment
Almost there. If you look into the folder “DeployScripts”, you will find a PowerShell file called “Parameters.ps1“. In this file, you need to supply your credentials (like my “Deploy” user) and the site URL where you want your application to be deployed. If you’re deploying to SharePoint online, you do not need enter the “$SpDeployUserDomain“, just enter the portal.microsoftonline.com login (user@account.onmicrosoft.com). Save the changes, and check-in to Source Control.
Now we have to change the Build Definition so that it will execute a PowerShell Deployment script. Edit your Build Definition, and select the “Process” section. On the bottom section, there is a field where you can provide the deployment script. In our case, this is something like “$../DeployScripts/SharePointApp/SharePointAppDeploy.ps1“
Image may be NSFW.
Clik here to view.
There you are. Save this Build Definition, and queue a new build. After a wile, you should see a nice green build, meaning that your App is deployed!
Image may be NSFW.
Clik here to view.
If you go to your developer site, you will see your App listed. Just click on it, and you will see this nice error:
Image may be NSFW.
Clik here to view.
Bummer! But no worries, that’s normal. Maybe you know, but if you deploy directly from within Visual Studio, you will be redirected to a page asking you “Do you trust this app?“. In the case of a Build Server deployment, there is no such a question, resulting in the error from above (note: by default, you will not see a detailed error, but I added “<customErrors mode=”Off” /> to my Web.Config”). To solve this error, you need to click on the “…” of your listed App, and select “Manage Permissions“.
Image may be NSFW.
Clik here to view.
If you now trust your App, you can enjoy playing with it! So if you change the Build Definition to “Continuous Integration”, you will have a “Continuous Deployment” system up and running! Have fun