Looking for documentation about moving only a subset of contents from a TFS 2018 server in certain domain and hardware to another TFS 2018 server in another domain and hardware.
More Details :
It is possible to follow general instructions for migrating a tfs to another server/domain, but we need only a subset of the contents i.e. contents for specific team projects in the single default collection that we have. The existing documentation in microsoft docs relates only to all the contents as a whole. We'd thus also like to assess whats recommended : migrate all and delete relevant contents on target or migrate only relevant contents from source to destination. Contents include : code, work items, Build & Release, all history, etc...
There's no way split individual projects out of a team project collection without resorting to third-party integration tools and suffering from a lot of pain.
The best solution is to clone the team project collection using the standard process, migrate it, then delete what you don't want.
Related
I have a TFS 2015 installation where we have a rather big number of projects. Currently there are old projects, that aren't used anymore but need to stay available as an archive (read only).
I'd like to make a workspace or something in TFS so that these projects normally don't come up in the normal view.
One way I found out is to set the TFS offline, make a copy of the database, bring the copy of the database online and then delete all projects that are still active and rename it. After that bring back online the original database and delete all archived projects.
This can be done once. Maybe once a year, but it will result in a large number of databases. This will make it worse than leaving the inactive projects in the workspace.
Does anyone have better idea? Or: What do you do with old projects?
First, there currently is no archiving function on TFS. However you can use something else as a workaround. To do this, you can either create a project designated as archived that you then have to assign permissions to and so on or move the project into another collection using the TFS Integration Toolkit.
Set the Read permission to Deny of contributor group will hidden the collection to come up in the normal view.
Below are some related blogs for your reference:
How to: Archive Team Foundation Server Team Projects
completely archive a TFS2012 project
Moreover, there has been a feature request in UserVoice, you can also vote up it to get more attention.
The process you are using (cloning a collection) would be the only method to achieve an archive as you describe it.
I would start by understanding why you have so many projects! Prefer larger Team Projects that contain many Products, Projects, Teams that are easier to manage.
I’m beginning to consider moving an on-prem TFS 2012 installation to Visual Studio Online. So, one of the first things I started investigating was how we might export our content back out of VSO in the future if we ever decided we needed to. The more I’m looking, the less I’m finding. It seems there was a temporary time period when VSO first went GA that Microsoft offered that capability if you asked to have it done (http://www.visualstudio.com/en-us/news/2014-apr-3-vso.aspx). By implication, that would seem to mean that this isn’t something that is a planned feature of VSO.
Making a commitment to house all of my source and ALM data in a repository I’d effectively be barred from leaving doesn’t sound particularly appealing. Am I missing something, or does Microsoft really not have export capabilities on their VSO product roadmap? It would seem that this would be a show-stopper for many organizations from coming onto VSO, which is a perfect application to put into the cloud IMHO.
For code you can use Git. Even if you start with TFVC, you can use Git-TF. Clone with the --deep parameter to get the full history in a new Git repo, then push back to a new project (Git or TFVC).
For work items the TEAM tab in Microsoft Excel is a very capable export facility for work items, though you don't get links (other than parent child), or attachments.
In the original project, create a query that lists all your work items.
Open Excel, go to the TEAM tab and click 'New List', you should get the option to select your project and the query you just created.
In the Work Items tab select the 'Choose Columns' button and select all the columns you want to migrate.
If migrating to another TFS / VSO project, create that project, open another list in Excel connected to the new project.
Cut and paste all the work items from the original project list to the new project list (excluding the Id column).
Publish.
voilà.
You're right there's no good solution for this yet. However, if you're using Git as the source-control back-end (instead of TFVC), you can easily pull down the entire repo then push it up into any other source control server (non-VSO) with full history.
For TFVC source-control, or work items (or builds, test results, etc), things aren't so easy.
The answer is not black and white: with the TFS Client API you can connect to both platform and read/write as you please. It is not a trivial task, so someone has created tooling, like Brian says. Another option is using the open source TFS Integration Platform: it is complex but with some help you can do it.
What you really must consider and plan is the data model: moving from an ALM Platform to another is never trivial and the complexity lies in the difference of the underlying model and any customization you made.
As long as you do not customize you on-prem TFS, it is very doable, with a reasonable effort to move to VSO and back. In this context customize means: custom workitems fields, types or workflows, server-side plugins; shortly anything that requires code or schema change. Note that you can still customize builds as this is properly managed.
I expect to see more solutions arriving thanks to the new REST API, but it will take time before we see solid products.
So your original question has a positive answer (TFS on-prem -> VSO) using OpsHub, but know what you are doing and, as I write, it is practically a one way journey.
I need to create a new project from an existing one in TFS. This is for source control only. I do not need to copy any work items.
so now i need to create NewTeamProject in NewProjectCollection and use the source branch of OldTeamProject in OldProjectCollection.
Kindly advise to go ahead with this.. Thanks a lot for your help in advance..
Manual Split
Create a new team project in your existing collection
Pick the branch from team project option in the creation wizard
Follow the split a team project collection guidance
However, I have a feeling that this will not bring all the history along with it, and it's not a particularly nice option, especially when it comes to the collection splitting.
TFS Integration Tools
Another way is to use the tfs integration platform, which basically replays all the checkins on a new team project, which can be in your new collection. You will lose the original date/time of the checkin, due to the way this program works but will still be able to see what each checkin changed.
TFS Integration Tools
Tfs integration tools blog posts and references
There is one risky way to get your timestamps correct, by manually updating the database
I am pretty new to TFS but I have some experience with VSS. I like to know your opinions of what would be the best way of working with TFS in the following scenario:
We are a group of developers working on projects. All projects starts from a common base code. All projects are one man only, no code sharing until the project is done. A project can last from a few hours to several months, no code is merged until done. Any developer works simultaneously on more than one project, usually 7-10 projects at a time. Usually the projects only involve a small numbers of files that are changed/created (10-20) but rely on a large group of infrastructure files that change quite often. However, any change in infrastructure is not considered until the merge, so we don't get latest version from server until the final build.
An additional request is that, when merged, we’d like to use a 3 way merge tool. We use this approach in VSS, via a custom made application and it works very well. However this involves special file management, for example every file that has to be changed must have an original version saved somewhere that will be used as the “root” file for the 3 way merge process.
What do you think?
You should take a look at the Visual Studio TFS Branching Guide 2010. (direct download). In that package, there is a PowerPoint deck that walks you through a series of possible branching structures.
It sounds like you want either "Branch by project" or "Branch by developer" (since you only have one developer per project, these are effectively the same).
Regarding the 3-way merge tool, take a look at this list to see how to configure your favorite diff/merge tools.
We're setting up a brand new TFS 2010 server, without having used TFS before (or, frighteningly enough, no other central source management system). Here's the general structure our small team (of 6-7 programmers) talked about setting up, and I'm curious, based on others experience working with TFS, if this is a good idea or not (these names are just descriptive and not what we're planning to use):
$/
Our Organization's Collection/
.Net technology projects/
class libraries projects/
Project 1/
Project 2/
Project 3/
etc.../
ASP.NET projects/
Project 1/
Project 2/
Project 3/
etc.../
Windows Workflow Foundation projects/
etc.../
WPF projects/
etc.../
Other non .NET source code/
SQL/
Server configuration/
(and so on)
Will we regret this structure after a year of using it? An application would span many parts of this structure - would that be a problem to manage?
At what level do we set up release/main/dev branches?
Thanks for any input and guidance!
Plan now. Branch when necessary.
With a team that has never managed branching/merging, I wholly recommend keeping everything as simple as possible to start (meaning, forget branching for the short term). After having recently converted our source from VSS to TFS2010 and implemented a Branch By Quality strategy for a team of a similar size with similar experience levels, my recommendation is this:
Do not implement a branching strategy until you need it. You can always branch once you determine it is necessary. Go ahead and bring the projects into TFS for source control and make sure everyone is comfortable with the software and the teamwork necessary to keep it stable.
In the meantime find members of the team who are interested and give them time to research, train, test, and practice on a parallel or simplified instance of your codebase. They will need practice creating projects, branching and merging in situations that mimic your deployment process; they will need time to communicate with the rest of the team to fine tune your processes and DOCUMENT them; they will need to be willing to be a resource to other members of the team as the learning curve flattens out. This way you have team members prepared and confident to step up and implement your chosen branching pattern.
You do not want to jump into a branching strategy before determining the need for it. There is a large amount of administrative overhead involved with plenty of perils.
With that said:
I don't think you will have any trouble managing what you have there once you start branching to accommodate a need. The key here is to make sure you don't over-architect this and complicate the management of your source/deployment. Also know that the structure of your TFS will be reflected in your local file system / workspace.
We created a separate Team Project for each independent solution or group of related reused libraries. In one case we grouped a set of highly dependent solutions together under a single Team Project - a large multi-application intranet portal that is deployed at once. Doing so allows us to keep deployment and source management simple. Here is a look at our branching structure for this one at a high level:
This is one large project with many sub-projects. Every branch is a complete copy (just the difference/versions are stored on the server). There are a large number of Team Projects above and below this one in the Collection and looks a lot like your list up top.
The final answer depends on the interdependency, structure, and deployment strategy of your applications. Do you have any specific concerns regarding your structure there?
In addition to #hangy's link, if its TFS 2010 your settingup then codeplex's Visual Studio TFS branching guide details the current wisdom for 2010.