Adatis BI Blogs

Migrating Team Foundation Server backlog

What is the issue I recently had a need to move a Microsoft Team Foundation Server (TFS) backlog I had created in an on-premises instance of TFS to a newly created Microsoft Visual Studio Online (VSO) instance. My existing on-premises TFS backlog had multiple Features, Backlog Items and Tasks as well as detailed information for each item; my new VSO backlog was completely empty. This blog post will describe steps to transfer my TFS backlog from on-premises to VSO but it can be used or slightly edited when transferring TFS backlogs between any versions of TFS Steps for migration 1. Export your current on-premises TFS backlog to Excel with the required level of information. To do this, navigate to the TFS webpage for your on-premises TFS and open the work tab, open the ‘Queries’ page and create a new query. Be sure to change the ‘Type of query’ to ‘Tree of work items’ and customise the query to include all relevant information that has been added to your on-premises TFS backlog which you wish to transfer, in my ‘Column Options’ I included; ID, Work Item Type, Title, Assigned To, Effort, State and Iteration Path. 2. Open Excel (with the Team Foundation Server add-in), go to the ‘Team’ tab and select ‘New List’ then connect to the on-premises TFS and the relevant project, finally choosing your query from the Query List. You should then have a table representing the items in your backlog. 3. Create a dummy Feature, Product Backlog Item and Task in your new VSO TFS backlog (A separate item for however many different levels you have in your backlog). This is to give you the correct number of indented title columns for your level hierarchy. 4. Create a query in your VSO TFS as described in Step 1 which directly matches the one created in your on-premises TFS with the same columns, filters etc. 5. Open another instance of Excel and follow the instructions in step 2 but this time connect to the VSO TFS project and open the query created in step 4. Copy all the rows from your table created from your on-premises TFS query in Excel from step 2 and paste them underneath the dummy items in your on-line query. Do not copy the ID’s for the items you are copying, leave them blank as the ID’s will be assigned once we publish them to your VSO TFS. *You may get validation errors for the newly added items, I had validation errors due to unsupported field values for ‘State’ where I had ‘In Progress’ values in my on-premises TFS which was not in the list of supported values for my VSO TFS. This is due a TFS constraint where you cannot create a new item (which we are effectively doing) unless it is in its ‘initial state’. To rectify this I filtered the ‘State’ column for where the value is not ‘New’ (which is their initial State for the column) and then manually changed all the values to ‘New’. After the backlog has been published you will need to navigate to the backlog in the on-line TFS and manually change the state of those items on the board back to what they were in the on-premises TFS backlog. 6. Once the new items have been added select ‘Publish’ and the changes will be uploaded to TFS. Navigate to the new on-premises TFS backlog webpage and check that everything has been added successfully.

Getting Started – Continuous Integration – Team City Installation and Setup

I have been working on a project where we have been using Continuous Integration (CI). Having used this for several months I am very enthusiastic about it. To give a brief explanation, using CI means that when you check in your source the project will be built built and (configuration dependant) deployed to a shared development environment. Whilst this takes a little getting used to I have found the benefits are significant – errors during the build are immediately spotted and with the automatic deployment to the shared environment errors or code clashes can be identified quickly. In this blog post I will be detail the setup of Team city in a windows and TFS environment for use in CI. The free edition of Team City will be used which allows access to all features and use of 3 build agents should be sufficient for most BI development environments. In subsequent blog posts I will cover the setup of automated build and deployment for Database and SSIS packages using MSBuild. Preparation 1. Download Team City (Windows edition) from: 2. Create a domain account which will be used to run the Team City service. The account does not require any special permissions on the network but should be granted local administration rights on the machine selected as the build server. Later when we use Team city for deploying projects this account will need appropriate permissions on the target servers to deploy the Databases, SSIS Projects etc. 3. Download the latest version of the JDBC driver for SQL Server from Microsoft, available from 4. Select a SQL Server instance to be used to hold the Team City metadata (2005 or higher). Mixed mode authentication should be enabled. 5. Create a database on the server to hold the Team City metadata. I suggest calling it TeamCity and using the Full recovery model. Ensure that the default collation of the database is set to SQL_Latin1_General_CP1_CS_AS this is generally NOT the default configuration. 6. Create a non windows account and give it full permissions over the TeamCity database created in step 5. Installation 1. Run the Team City setup program as an administrator. 2. Install to the default directories and Select all features. 3. Select the option to install as a service. When prompted use the service account setup in Preparation Step 2 for Team City Agent & Scheduler (not the SYSTEM account). 4. Choose a default port for the Team City Agent. This will be used when you access the administration portal to view build progress and make configuration changes. For the purposes of this tutorial I will use 8083 which will make the address of the when viewed from the local machine http://localhost:8083/  5. You should be presented with a screen like the below. If the configuration looks correct click save.   6. Select to run immediately upon completion of the install. 7. Open your web browser and navigate to http://localhost:8083/mnt (change port number if required) You should be presented with the following screen: 8. Click Proceed. Following this (if you do not click proceed the directory will not exist) Install the JDBC driver from preparation step 6 and place the drivers (sqljdbc4.jar & sqljdbc.jar) in the C:\ProgramData\JetBrains\TeamCity\lib\jdbc directory (assumes default installation paths). 9. When prompted to setup access to a database chose 'MS SQL Server' as the instance type. Set the connection properties and name of the database to the DB setup in step 5 of the preparation using the SQL account from step 6 of the preparation. 10. Read and accept the license agreement. 11. Create an Administrator account for Team City configuration and ensure that the credentials are stored securely for later use. The next step is to connect TeamCity to your source control, detailed here:

From Nothing to Source Control

Source Control, often called Revision Control or Version Control, is a process of maintaining projects. It is essential for any software project, collaborative or otherwise. Below is a non-exhaustive list of benefits of Version Control: Version Control and Tracking Provides locking and serialized changes to any file Structure Everyone operates in the same way Centralized storage Multiple users can work on the same project simultaneously. When a person makes a change and checks it in, everyone else can get the latest version Backups If you accidentally delete a file you can just undelete it Ability to branch If you want to develop a large feature or make small fixes separate from the main trunk so as not to disturb or break the main development effort your can create a branch of code History You can see who made changes to what and when Roll back If a build is broken you can roll back the changes made These features are fantastic for large projects but also for small ones, even if you are working by yourself. As well as the above points, there is also capacity to accommodate integrated automated builds and project planning and tracking, for starters. So how do you go about getting free source control? Visual Studio Online includes free TFS for up to 5 users! However this does not include MSDN Subscribers. Navigate to Click on ‘Get started for free’ and you will be redirected to a login screen. This is to create a Visual Studio Online account. You will then be asked to sign in with your Microsoft account or an organisational account before being asked to fill in some extra details. If you do decide to sign up with an organisational account, it means that users can only sign into the Visual Studio Online account if they are a member of the connected Azure AD or 365 Subscription. If you sign up with a Microsoft account then users are fully managed by the Visual Studio Online account owner (and Administrators) and only Microsoft accounts can sign into it. When you sign up you will need to provide a URL in the form of: https://<yoururlhere> This has to be unique. If you choose a URL that is already taken you will be presented with an error message stating that that URL is reserved. Once you’re all signed up you will be presented with your newly created Visual Studio Online page. Here you can start creating Projects and adding users. If you navigate to Users you will see that you have yourself as a user and that on the far right you should have the number of free and total users. You can add new users by email address and select whether they are a basic or Eligible MSDN Subscriber. You can edit existing users to change their License type. Finally you can delete users. If you navigate back to the homepage you can create your first project. With your Project you can choose between two different versions of Version control. These are Team Foundation Version Control and Git. With Team Foundation, typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Git is a decentralized version control system. Each developer has a copy of the entire source repository on their dev. You can learn more about the differences in this extensive page: TFVC or Git You also have the choice of a process template. You have the choice of 3: Microsoft Visual Studio Scrum 2013.3 MSF for Agile Software Development 2013.3 MSF for CMMI Process Improvement 2013.3 These define the set of work item types (WITs), queries, and reports that you’ll use to plan and track your project. They are detailed here: Process Templates Once you have created the project you can open it with Visual Studio. This requires you to have Visual Studio 2013. There is a link on the home page to obtain VS 2013. There are 3 free Express versions to choose from or you can trial Ultimate 2013. You need to configure the workspace mappings before you can open the solution. This maps the files to a local directory on your machine. Once you have chosen a directory of your choice then you can click ‘Map & Get’ and then you are ready to go. The same applies if you are using Git where you have to specify the directory for the local repository. In the Solutions section you should see the option ‘New…’ This brings up the familiar New Project dialogue. Once you add one, you can check it in via ‘Pending Changes’, and you’re done! If you wanted to sign into your online source control starting from Visual Studio on your desktop instead then open up Visual Studio and on the ribbon choose ‘TEAM’ > ‘Connection to Team Foundation Server…’ The Team Explorer window will appear on the right. Then choose ‘Select Team Projects’ and add your URL you created earlier, as a server. You will need to provide credentials. If you wish to add more projects you can do so via the home page using ‘New’ under the recent projects & teams section. You can always get back to it by clicking the Visual Studio Online link that is in the blue bar at the top left of the page. This can also be done from within the Team Explorer on your desktop VS.

TF204017 The operation cannot be completed because the user does not have one or more required permissions (Use) for workspace

The titled error message (above) often occurs when a number of people work on a particular server, using the same credentials. This article explains the different workspace permissions that can be assigned in Visual Studio, as well a way of eradicating the error message. Please Note: This post is only relevant to TFS 2010 and beyond. Any previous versions will only allow a workspace to use the ‘private workspace’ setting Background When creating a TFS workspace and linking it to Source Control, the associated solutions (and files) are saved to a local location. By default, everything saved here is set with a ‘private workspace’ permission. As a result, only the associated user (that is logged on to a server) can create, edit or delete parts of the solution. In most cases, you would want TFS to apply the ‘private workspace’ permission. This ensures individuals have their own copy of locally developed work and prevent the risk of anything being accidentally overwritten or deleted. However, there may be a need to share a workspace across multiple users, where the solution files are store on a shared drive. Furthermore, some servers use generic log in credentials (to a server), in which more than one person would connect to TFS. Switching the TFS workspace to a more ‘public’ setting would enable everyone to share the same solution files. Workspace Permissions There are 3 types of workspaces in TFS 2010 (and beyond); 1. Private a. Default setting and most commonly used. Only the logged in user will be able to create, edit or delete from the local files. In effect, only the owner will have permissions. 2. Public-limited a. Additional users are granted the Read and Use permissions on the workspace. 3. Public a. Every valid user of the team project collection has the same permissions as the owner: Read, Use, CheckIn, Administer. Edit TFS Workspace Settings The below instructions illustrate how to change a workspace permission in Visual Studio 2010. The same logic applies to Visual Studio 2012 and 2014. 1. From the File menu, click Source Control, and then click Workspaces. 2. In the Manage Workspaces dialog box, under the Name column, highlight the workspace that you want to modify, and then click Edit. 3. In the Edit Workspace dialog box, Click Advanced. 4. Change to the desired workspace by using the ‘permissions’ drop down. Fig 1.0 – Edit Workspace Example 5. Click OK to confirm. Test Workspace Permissions You'll need to log onto the machine which has the public workspace. After starting Visual Studio 2010 and connecting to the server which has a public workspace, you'll be able to see the workspace in the appropriate drop-down combo boxes in the Source Control Explorer and Pending Changes tool windows. 1. From the Team Explorer home page (Keyboard: Ctrl + 0, H), choose Source Control Explorer. 2. From the menu bar choose View, Other Windows, Source Control Explorer. 3. Choose the recently changed ‘Public Workspace’ and begin to use it. Summary Although the original TFS error message was the reason for my findings, it also highlights the fact that there are now different workspace permissions that can fit your needs. To any users of TFS and Source Control, these types of articles are priceless when learning more about it. Visit the websites below for a more in depth look into workspaces: - - -