Yesterday, May 12th, Visual Studio Online exposed a collection of service hooks which sends information to other services on interesting events that happen inside Visual Studio Online – things like builds completing, work items being updated, or code being pushed. Visual Studio Online supports direct integration with over a dozen services, and one of this services is Trello.
Last week, at the BUILD conference, Microsoft announced the general availability (GA) of Visual Studio Online. That’s great news, but this however impacts your current account and team projects living on the service. The first important thing to note is that the “early adopter” period of Visual Studio Online is nearing its end. On May 7 th, 2014, the early adopter period will stop.
Many of the users started out with VS Online before there was a clear view of how the future of TFservice (as it was called previously) would like like. Because of that, some people may want to take this transition to GA as an opportunity to reconsider their ALM configuration and move to an on-premises TFS server. Therefore, Microsoft enabled a data export window for any customer that has been on the service and wants to “opt out”. You now have the option to export your data from Visual Studio Online in a format that can be imported to Team Foundation Server 2013 Update 2. The data export process is a transfer of a faithful reproduction of your Visual Studio Online data. Read More
Yesterday, I gave a session at the Visual Studio Usergroup (Visug) in Belgium. I talked about how you can leverage the power of Git with TFS 2013 and Visual Studio.
As promised, you can find my slides at Slideshare:
Thanks to the people who joined my session! I hope you enjoyed it!
In this post, I will describe how you can easily ‘move‘ an existing Git Repository (like GitHub, BitBucket,..) to Team Foundation Service or Team Foundation Server 2013. As you might know, TFS Service and 2013 offer Git support as DVCS solution. You can find some additional information about the Git story on the great blog post by Brian Harry!
So, you have an existing Git Repository, and you want to ‘move’ it to TFS? Well, compared to a migration from one server using TFSVC (a topic I blogged about recently) to another server (like TFService), moving a Git repo is a piece of cake! In fact, you have two options
In this post, I will demonstrate how you can migrate your TFS on-prem to TFService in the cloud. This process will migrate your sources and your Work Items. When you want to migrate from an on-prem version to the cloud, the only viable option is using the Integration Platform. Because using the Integration Platform can be challenging (if you Bing/Google the integration platform, you’ll see what I mean), I want to guide trough the required steps to perform a migration.
In this post, I’ll guide you trough the process of installing Windows Server 2012 R2, SQL Server 2014 CTP1, and on top of that the brand new TFS 2013 that was released in preview yesterday at Build. The reason I do this post? Well, I just love using the latest bits and finding out the different compatibility options. So, be aware that this post will mainly consist out of screenshots, many screenshots.
Let’s go. What I did was creating a new Hyper-V machine on my existing Windows 8 host. Give it some memory (4096MB seems to be enough for this basic installation). Boot the machine using the Windows Server 2012 R2 image. Just follow the wizard.
NOTE: you can of course also create a brand new Windows Azure Virtual Machine using the Windows Server 2012 R2 template. Just just ignore the first part of this post.
Windows Server 2012 R2
Active directory domain controller (optional)
Allthough this step is optional, I decided to install a AD DC controller on this machine. I just wanted to know if there were any changes to this process, comparing to 2012. To start, select “Add Roles and Features” and add the role “Active Directory Domain Services”.
And that’s it. Your machine is an AD controller. What you can do now is adding some AD service accounts like SQLService, SQLRS, SQLAS, TFSService,..
SQL Server 2014 CTP1
Next step, the installation of SQL Server 2014 CTP1. But first, a big “do not forget”: You need to have .NET 3.5 enabled. I was hoping that the SQL Server installation wizard would handle this, but you have to install it manually. Otherwise, you will get this great warning:
Team Foundation Server 2013 Preview
And now finally the installation of TFS 2013 Preview. Not a difficult one, as with the previous components, it’s as easy as completing the wizard. Start the installer:
Select the ‘Advanced‘ option, as I want to select my SQL Server, Reporting and Analysis Services
Enter your service account. I did it the “right” way and used an Active Directory account
Use the default settings
Populate the URL’s from your Report Server installation
Test the SQL Server Analysis Services instance
Enter your “Report Reader” account (again, I used an AD account)
I did not configure SharePoint, as it’s only a lab environment
Create a new Team Project Collection
Verify the “Readiness Checks”
There you have it! TFS 2013 Preview has been installed
To verify, open the TFS Administration Console
To test the installation, I’ll just create a new Team Project using the new Visual Studio 2013 Preview, I used GIT as version control system:
And the web access:
I got a question from a friend of mine (Pieter Turcq) today, who asked me if it’s possible to use one single Project Site (in SharePoint) for both TFS and Project Server? Well, actually you can. In this post, I will show you what the requirements are and how you can easily achieve this. But first let me start with a brief ‘overview’ of how it looks like out of the box.
One of the nice things about Team Foundation Server is that it creates a SharePoint “Project Site or Portal” when you create a new Team Project. This is a place where you can add project documents, view some dashboards and whatever SharePoint magic you want to use. On the other hand, you have Project Server. In some cases, you can have a nice integration between both systems using the Team Foundation Server Extensions for Project Server. This way, you can manage the data flow between TFS and Project Server (but this is not the scope of this blog post). The thing is, if you create a new Project in Project Server, it also creates a Project Site. The total picture will look like this:
Note that this is a situation where the Project Portals from TFS are hosted on another SharePoint environment as the Project Sites of Project Server. (If they are hosted on the same environment, it will of course use a different Site Collection, but you will have less work to get to the end solution. I’ll explain this a bit later). Now, how can we get one Project Site for both systems? We have 2 options: A quick-and-dirty solution, or a decent solution.
The quick-and-dirty solution
The first solution is really simple. What you do is pointing the Project Site from your TFS Team Project to the URL of your Project site of Project Server. You can do this using Visual Studio using Team Explorer. If you go to “Settings -> Portal Settings“. There you can set an option “Use a website“.
It will now redirect to your Project Server’s Project Site. That’s all. Nothing more, nothing less. It will have no interactivity with TFS or what-so-ever, you will not see the Project Site documents in your Visual Studio, you will not have any dashboards on your Project site,.. So this is not an option. Let’s move on.
The better solution
A better solution is to make it possible to let the Project Server’s Project Site behave like it would have been a “standard” TFS Project Portal.
If your are in the same situation like the one I’ve illustrated, you must install and configure the Team Foundation Server extensions for SharePoint Products on the remote portal. If not, you can skip this step, and no actions related to this need to be executed! This is a step that has to be executed for ALL SharePoint application servers. It contains the necessary Web Parts and some dashboards. You have some excellent guides for this, but it really is a straight forward process. Just make sure that you have the right permissions, and especially that the TFSService account that needs to a Farm Administrator.
- How to: Install Remote SharePoint Products for Team Foundation Server
- Configure Team Foundation Server Extensions for SharePoint Products
Great, now our SharePoint instance who’s hosting the Project Server’s Project sites is able to do “TFS related” things. Next, assigning this SharePoint instance to TFS. Open the administration console and click on “SharePoint Web Applications -> Add“
Note: It is import to know that when creating a new Team Project in TFS, we will NOT allow the wizard to create a Project Portal. Because if you don’t watch out, it will create one on your PWA instance directly. This is not the behavior that we want. We want Project Server to create Project site, and link our TFS Team Project to that site manually. So be careful!
Alright, so now that the SharePoint instance of Project Server is known by TFS, we can configure our Team Project to use an existing Project Site from Project Server. Open Visual Studio, go to Team Explorer and select “Settings -> Portal Settings”. Enter the correct settings:
In this example, I use the TailspinToys Project Site from Project Server, to be used as TFS Project Portal from TFS. Be sure to select the check box “Reports and dashboards refer to data for this team project“. Click Ok. If you now go back to Team Explorer and select the “Documents” node, you will see the content of the documents library from you Project Server’s Project site.
Mission accomplished.. or not? Well, it’s great to have the documents library available from your Project Site. But wouldn’t it be cool if you could also use this Project Site to add your TFS Dashboards, and some TFS Related Web Parts? Well, actually you can! If you open your project’s Project Site (in Project Server), and go to “Site Settings -> Site Features“. And activate the dashboard you need. In my case, it’s a TFS Team Project based on the Agile Process Template, so I selected “Agile Dashboard“. If you click activate, you will see some new items in the menu on the left side. That’s exactly what we need. This way, we can also change whatever we want, and we can even add the TFS specific Web Parts like a Work Item Query list.
That’s pretty cool! So there you have it, one single Project Site/Project portal for both TFS and Project Server. Have fun!
Note, when Project Server was not on the same SharePoint instance as TFS, and you followed the previous steps using the TFS Administration Console, and you don’t see the dashboards listed in the features list, be sure that it’s enabled in the Web Application of your PWA! You can check this using the “Central Administration -> Application Management -> Web Applications -> Web Application -> Manage Features“. It should be enabled by default, but you never know! Next to that, if you don’t see any web parts related to TFS, look at the Site Collection Features, and be sure that “Visual Studio Team Foundation Server Web Part Collection” is activated. That’s all!
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:
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.
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:
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:
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!)
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.
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 (email@example.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“
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!
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“.
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
In a previous post, I was talking about how you can build SharePoint 2013 apps using TFS 2012. In this post, I will guide you through the process of creating App packages using a TFS 2012 build. There are some small things that you need to know.
Required Components on your on-prem TFS build server
To start, you need two extra components on your build server, to be able to create App packages on the one hand, and Web Deploy packages on the other hand (if you’re creating an “Auto Hosted” or a “Provider Hosted App”).
- The first component you need is Web Deploy V3, which you can download here.
- Next, you need to copy paste the following folder from your local machine to your Build Server. “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web”. Otherwise you will get this nice error:
Hosted TFS Build Server, you can use it, now!
In my previous post, I mentioned that the Hosted TFS Build Server could not yet be used because the “Office 2013 and SharePoint 2013 Developer Tools” were not installed. Well, good news, now they are! You can make use of the Hosted TFS Build Server. This is an overview of the installed component on the hosted Build Server.
Creating App Packages
Previous versions of SharePoint have the notion of SharePoint Solution Packages (wsp). It was also possible to use TFS (2010) for creating these packages. You can find a nice how-to on this link. It all comes down to that one parameter called “/p:IsPackaging=true”. You need to pass this parameter to MSBuild.
Now with the new App model of SharePoint 2013, this behavior is identically. You also need to pass this parameter to MSBuild. To do this, create a new TFS Build Definition (like described in my previous post). On the “Process” part, check the “Build process parameters” and find the “MSBuild Arguments” on section “3.Advanced”. Add the parameter “/p:IsPackaging=true”.
Save the build definition and queue a new build (right-click on the definition, and select “Queue New Build…”. After a while, you will see that you have a nice red build. Yes indeed, build failed!
The problem is in fact a (small) bug on the TFS part of the build process. To create an App package, the AppManifest.xml my not be marked as ‘read-only’. Because we’re using TFS, files are marked as ‘read-only’ once they are downloaded to the Workspace. The reason for that is because the TFS 2012 build server uses ‘Server’ workspaces. Meaning that every file gets this annoying ‘read-only’ file attribute. Local workspaces, on the other hand do not behave like that, but a Build Server always use the server workspace. (You can find a nice overview about the difference between Local and Server workspaces here). There are also reports that you can have the same behavior when you want to create an App package using Visual Studio. (Right-click on your project, and select ‘Deploy’). You will not have this issue when you’re using a local TFS workspace, as files will not be marked as “read-only” than.
Unfortunately, there is no easy solution to fix this error, except a small modification to the Build Process Template. (There is an awesome guide available by the ALM Rangers to get you started, get it here). What you could do is make a copy of the ‘DefaultTemplate.11.1.xaml‘ file, and add an extra workflow activity to this template who will remove to ‘read-only‘ attribute from the AppManifest file.
The Real Solution
Now I see you thinking: nah, I really don’t like editing WF 4.5 XAML files. Well, good news, someone already created a Build Process Template with this modification. There is a nice Codeplex project called “Office / SharePoint 2013 Continuous Integration with TFS 2012“. There you can download a customized Build Process Template that can be used. All you have to do is adding this XAML file to the (for example) “BuildProcessTemplates” folder in Source Control, and change your Build Definition that it will use the new Build Process Template. So it looks like:
That’s it. Just queue a build, and it should be green. (You also don’t really need to add the parameter “/p:IsPackaging=true” anymore, because this great Build Process Template will take care of this. But it’s also that smart that it will detect if you did pass the parameters, so no problem).
So for now, I talked about how you can actually build you SharePoint 2013 App project using TFS. In this post I described how you can produce an .APP package. In my next post, I will talk about how you can deploy your App. I will also make use of this Build Process Template from CodePlex, because it’s already all in there!
In this post, I want to talk a little bit more about how you can build those shiny new SharePoint 2013 Apps using a TFS 2012 build server, but especially: without installing Visual Studio! To start, I will shortly guide you trough the process of setting up a TFS Build Server (with 1 controller and 1 agent).
You might be wondering, why do you setup a separate TFS Build Server? Why don’t you just use the Hosted TFS Build Server? Well, that was also my intake, but it just doesn’t work (yet). The Hosted Build Server does not have the “Office 2013 and SharePoint 2013 Developer Tools” on it, so it’s not able to build SharePoint 2013 apps. So for now, a separate server will do the trick.
TFS 2012 Build Server
Let me start with a quick overview of how to setup a TFS 2012 build server. In my scenario, I’m using a fresh Azure-hosted Windows Server 2012 VM. Fast and easy setup. Download the TFS 2012.1 installer and start the ‘Build Service Configuration Wizard’:
The next few steps are just a ‘next-next-next‘ experience, use the default settings as they are provided. Once you’re ready, you should see that it has one controller and one agent connected to your TFS Server.
CI Build Definition
Now comes the tricky part, how can be build SharePoint 2013 Apps without installing a full-blown Visual Studio 2013? Which components do you need? Well, we’ll start by creating a Windows Azure Auto Provisioned App like I’ve described in another post. Once you have this app, add it to Source Control, and perform a check-in.
Next step is to create a build definition which will perform a continuous integration build of our app. Using Visual Studio, go the the ‘Builds‘ section of Team Explorer, and click ‘Create New Build Definition‘. Give it a name and select ‘Continuous Integration‘ as trigger.
On the ‘Build Defaults‘ section, select the Build Controller we’ve just created, and define where you want the drop output to be stored. I will just use a drop folder in Source Control (which is a new feature in TFS 2012).
On the process section, select the solution file, and leave the other settings by default. That’s it for the build. To try, just queue the build manually, and you should see a nice failing build. That’s completely normal of course, as we didn’t install any build-related things on the build server yet:
Now that we have the build, we need to make the necessary changes on the build server (where the actual Build Agent service is running). Install the following components in the right order:
That’s a tricky one. It will start the web platform installer, and it will give you this error:
That’s correct, we don’t have Visual Studio installed, and that’s exactly what I don’t want! But when you click OK two times, you will a nice overview of all components required:
We can now use the Direct Download links provided to install the required components:
When installing this, you’ll get another nice warning about the ‘Microsoft Web Developer Tools’. Just click ‘Continue‘
There we go, another nice screen telling me that I need the Windows Identity Foundation Runtime.
My build server is a Windows Server 2012 machine, and there you can ‘enable’ the WIF runtime as a feature on that machine. When you enabled this, just retry the setup of the WIF SDK.
- Microsoft Identity Extensions (Dependency) (that’s required for OAuth2.0 usage in the App)
Almost there! If you queue a build now, you will see the following nice error:
Correct, that piece is missing on the build server. To solve this, all you can do is ‘copy‘ the folder ‘C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications‘ from your development machine to the Build Server (on the exact same location). That should do the trick! If you now queue your build, you will get:
That’s it, you have your SharePoint 2013 building on clean, fresh Build Server without installing a full-blown Visual Studio 2012. It was quite a challenge, but thanks to Xavier Decoster and some research I managed to get this thing working!
In a next post, I will explain you how to build an APP package with the TFS Build Server. It’s not that simple as just adding “/p:IsPackaging=True” as extra ms build argument unfortunately.
Some extra information: In case you are wondering why I install the Windows Identity Foundation SDK (Dependency)? You can just use the .NET 4.5 Framework, and WIF is already in there. But you need to have the WIF SDK 4.0 to be able to install the WIF extensions. So… You just have to know..