Currently we have a team project in TFS 2010 named MyApp that was put in years ago. I would like to create MAIN and DEV branches as described in the ALM Rangers guide. I know it would've been easier if the existing team project was created with the branches initially, but that's in the past. I don't want to lose the version history in the existing project.
Is it possible to create those branches (or at least a DEV branch) without affecting the existing project?
UPDATE My folder structure looks something like this (bold is folder, italic is file):
server\DefaultCollection
MyApp
Lib
packages
Repositories
MVCClient
MyApp.sln
There's not a great solution to this, but here's one option:
Create a MAIN folder. Copy all your source under this folder. Convert MAIN to a branch. Branch DEV from MAIN.
Keep your old source code around (the stuff not under the MAIN folder) for history purposes.
Related
I am doing to for the first time so I want to use Release isolation strategy for our project using TFVC. I went over documentation on how to do that but I was unable to branch out our projects. We have two projects which are dependent on each other and structure of those projects looks like this:
Project 1
folder 1
folder 2
folder 3
I tried to convert project itself to branch and then branching it out but it gives me an error saying TF10175: ... Team project does not exist. Then I tried to create one main folder inside the project and convert that folder into branch and then branch it out but reorganizing folders causing build issues. Do you have any advice how I could branch my projects out and why am I getting team project does not exist issue. Do I need to create new project in TFS called XYZ-branch?
We installed the free version of TFS 2017 and created a new project. We now have source code with history. The PM decided they wanted to switch from Agile to Scrum so a lot of commands were run to try to do this. These commands came from a blog found on the internet. The supervisor then decided that it should NOT have been switched to scrum and said we needed to switch back to Agile. So similar commands were run to try to do that. Now the Project Management portion of our project is broken. We can't run queries and the work items are corrupted. I want to try to just install a new instance of free TFS 2017 and copy/move the source code (TFS, NOT GIT) to the new instance and start over with the PM stuff. Can we do this or is it a lost cause.
Actually we do not suggest OPs to do the process template change in a single team project. Take a look at this MS documentation (here) ...
You can change the process a team project uses from a system process
or inherited process to an inherited process. You can only change team
projects to use another process that inherits from the same system
process. That is, you can change an Agile-based team project to any
process you created from the Agile system process as well as to the
Agile process. Whereas, you can't change a Scrum-based team project to
an Agile-derived inherited process.
There is no need to set up a totally new TFS instance, you could simply create a new team project based on Agile and then move your source code and workitems to that new team project.
Since you are not care about the history info about your original team project, it's more easier to achieve this, simply remove your old workspace mapping and map to the new team project.
To move workitems you can export them to Excel, create a new Excel connection to , that is connected to the new team project, and then copy the workitems and pushing them from the new Excel file into the new project.
If you insist on moving the code to new TFS server, you just need to back up your local code and directly check in them as pending changes in the newly created team project on new TFS server.
More details please refer the answer from Andrew Clear in this similar question: Visual Studio Team Services: How to migrate from Agile to Scrum process template
If you want to only move Source code from one Team Project Collection to another Team Project Collection, one of the crude workarounds is the following, when you are ONLY requiring SRC code moves.
Create a workspace and check out all SRC from the source Team Project in the source TPC.
Create a new Team Project in the new TFS instance.
Remove the binding files from the SRC dumped out in (1), or better yet just move it on the disk to a new directory and remove all SRC binding files.
Then add the source (from the above step 3) into the new Team Project you created in the target TPC you created in (2) above (or it could also be into an existing Team Project you already had in the target TPC).
Once again this is ONLY if you don’t care about the other things such as WITs and Reports from the older Team Project, and you only care about the Source Code.
In addition, you can use the following tool Timely Migration.
On our TFS Server, we have a Team Project called "Connect". The root folder for that Team Project contains the root of the web application project. I'm not sure if it was setup correctly, but what I'm trying to do is create a branch of the "Connect" Team project so there are 2 versions, 1 for Production, 1 for a new development/enhancement. What are the correct steps to get the right structure? So that we can work on the enhancement in one, and eventually merge it into the production branch....
You'll have to do some restructuring here. At a minimum that is probably:
$/Connect
---------dev
---------main
Where dev and main will become your branches and contain all the code that is currently in the root.
I'd usually expect to see something more like
$/Connect
---------ConnectWeb
-------------------dev
-----------------------src
--------------------------Connect
-------------------main
-----------------------src
--------------------------Connect
where dev and main are the branches and Connect contains the files and folders currently in root. By putting the branches in another folder (I called it ConnectWeb) you have the option of having multiple development projects within the same Team Project which allows you to manage a portfolio backlog in a single team project.
Rename or move files and folders
I have a project folder called as "APP1" . We are currently deploying code from this folder . we would like to create one more folder or branch so that Dev can easily checkin all their new changes without directly affecting the main folder .
Should we have one more branch of folder "APP1" so that Dev can checkin all their changes in the newly created branch and eventually we can merge all the new changes to the main folder "APP1"?
Is this a correct approach and how easy it will be for us to merge all the new changes to the main folder ?
We have team of about 4 developers working on the same project .
You can consider using Basic Branch Plan. The structure like this Development <-- Main --> Release. You can branch your project "Main" into two, one named "Development", the other one named "Release". All users can work in Development branch, after they test their code, then merge to Main branch. When you want to release your project, you can merge your code from Main branch to Release branch.
That would be one way to do it. You'll likely need to play around with differing branching and merging strategies until you figure out what works for you and your team.
There's a large guide put together by the ALM rangers for TFS branching and merging strategies. See https://vsarbranchingguide.codeplex.com/
Here's a picture from one of their guides describing the potential branching/merging strategies that may work for your team, depending on team size and release cadence:
I have a Visual Studio Solution having 3 projects in it. Same solution is having a folder in which I added existing projects which belong to other TFS Team Project.
TeamPrj1
|- Solution1
|- External Reference(folder)
|- PrjA (added as existing project)
|- Prj1
|- Prj2
TeamPrj2
|- SolutionA
|- PrjA
I want to have a TFS Build for my Solution1. The problem I am facing is that the solution is not compiling on the TFS Build Server as it cannot find the reference of the PrjA. I know there is some tweak to be done in the workspace mapping and I went through different forum and blogpost too but still doesn't work. Some say to add the PrjA dll as a file reference but I dont want to go that route as what if something changes in PrjA than the Sol1 needs to be re-reference the latest dll. Having added as reference, it automatically gets the latest everytime Solution1 is opened from TFS.
Currently below is my workspace mapping.
Active $/TeamPrj1/Main/Solution1
$(SourceDir)
Active $/TeamPrjA/Main/SolutionA
$(SouceDir)\Main\
Since the solution needs to reference the other project using a relative path, you need to make sure that the Workspace mapping for the Build Definition actually results in the same file structure as on your local workspace.
Judging from your folder names, you should use the following mapping:
Active | $/TeamProj1/Main/Solution1 | $(Sourcedir)\Solution1
Active | $/TeamProjA/Main/SolutionA | $(Sourcedir)\SolutionA
But I cannot be sure of the exact target paths until we know the relative path defined to PrjA.csproj in Solution1.sln.
You will probably need to update the path to the solution in the Process Tab of the Build Definition editor as well.
If you have a Visual Studio project, for example a team project containing shared library code that is used by multiple team projects,
You can either manage the project within the owning team’s project or
you can create a separate team project specifically for the shared
project.
If you choose the latter approach and use a common shared project,
the folder structure in Microsoft Visual Studio Team Foundation
Server (TFS) source control looks like
For more info see the following:
Chapter 6 – Managing Source Control Dependencies in Visual Studio Team System
I guess the best option is to have a enterprise NuGet server and publish packages this NuGet site internally.
For visual studio solutions under different Team Projects, they can easily NuGet for referencing. The TFS Automated build can also easily restore NuGet packages for any solution.
You can also have the automated builds to drop a NuGet package to NuGet server for the assemblies/exe's which are common across multiple TeamProject and Team Collections also. (xcopy command in build template).
The biggest benefit of using this approach: Everything is automated. No need to do any manual merge and checkin. Can be used across multiple TeamProject & TeamCollections. If a parent common dll changes, the automated build for it can push it to NuGet server. Next time all other project using the common dll via NuGet will have always the latest one as on the Build Server it will always download the latest from NuGet (assumption that you keep the version # same).