We are using TFS on premise, version 2015 update 3. We are using multiple team projects. Some Team Projects are used for applications (source control and builds), other team projects (with multple teams in it) are used for work item tracking. Teams can work on different applications.
Now we are looking into the Release functionality. Preferably we would like to use 1 team project to keep track of all the releases, so we get an overview of all releases in our organisation. But I can't figure out how to achieve this.
Is there a way to define release definitions linked to builds from an other Team Project? Here Microsoft says: "No additional setup is required when deploying Team Build artifacts published within the same team project." So I guess it should be possible to do an additional setup, but I can't figure out how.
We also have many team projects
We are using TFS 2015 CU2 but I do not think there are to many differences between the two versions.
The artifact link are for team builds within the same team project. I do think there is a way you can link to builds outside to other team projects.
In your one team project you could create all your CI builds there (in the build defintion mappings would can map to any source control path you want you simply have to cut in the path.)
If you still using your XAML build definitions; you could use the TFS Communinity build manager add-in for VS 2013 and clone the build defnition to you new team project.
So there is not easy way currently. We have chosen to release from every team project. The release overview is nice but we chose that it was not worth the effort. Maybe in the next release we will revise.
You shouldn't separate aspects of your project (builds, code, releases, work items, etc) into different team projects. You lose all tracability if you do that, as you're seeing.
You can manage your application portfolio within a single team project with the appropriate use of Teams, but discussion of exactly how to achieve that is going to be very specific to your organization and thus is too broad to discuss on Stack Overflow.
Related
We have a situation where at a point in our project's life, we needed to split off work item tracking and source control into 2 separate TFS projects, with the work items being in a VS Team Services project, and the source on-prem in TFS 2013.
The reason at the time being, we needed to grant access for our stakeholders to the product backlog, without them being on the corporate network where TFS is hosted. At the time there was concerns about security of the source code, hence the whole project was not lifted and shifted, just the backlog.
Now we're realizing some of the security concerns were not warranted, and we are missing out on the integration of ALM provided by a single project having both responsibilities, and would like to merge our source control out into the cloud-based VSTS project.
The problem is, the migration tools are overwriting the Work Items in VSTS. Is there some way we could merge, preserving that data, or any alternative to merge these two things together somehow?
I think you're looking at the Team Foundation Server Integration Tools here if you want to migrate source code history. Bear in mind that it's not going to be perfect (data time stamps will not be the same etc.).
If you can get away with it then just stick the latest code in VSTS and consider the on-prem server your archive should you need to go back. That doesn't tend to be too popular so you'll be wrestling with the integration tools. It's not the most friendly thing to use but mostly it will get the job done.
When you configure your session, you will want to choose Team Foundation Server\VersionControl.xml for your configuration. Then select a One-way-migration between your on-prem and VSTS.
You'll need to install VS 2012 or at least the Team Explorer.
Edit Coincidentally I had to do this myself so I blogged about the process here
Is there any way to move/migrate team projects of a Team project collection from one TFS server to another (both in TFS 2010 version). The destination Team Project collection contains a Team Project already and I want to move the source Team projects in to this particular team projects. So at the end I will have a Team Project which contains several projects in it. Is that possible? I want the history to be preserved as well.
If the above scenario is not possible, can I migrate Team projects from one server to another without going through the database backup-restore-TFS detach-attach process?
I thought of trying the TFSIntegration tool, but could see many people advised to avoid using this due to issues in it.
So if you have any information in accomplishing this, that would be great..
If you want all the history then you really only have 2 options:
TFS Integration platform - http://tfsintegration.codeplex.com/
Back up /restore the collection database - http://msdn.microsoft.com/en-us/library/dd936138.aspx#Backup
I would recommend moving the database. This sounds pretty onerous but is actually quite easy.
Good Luck!
TFS INTEGRATION PLATFORM used for integration.
A tool which helps a lot named "witAdminUi".
I would like to know what is the concept of Team Project in TFS 2010. In my company, there is a single team working on multiple products at the same time. There is a visual studio solution for each product. We are following SCRUM methodology. Our product back log and sprint back log basically comprises of items related to multiple products, so during the sprint the team works on backlog items relating to multiple products. We are looking forward to use SCRUM Process template for TFS 2010.
I was wondering what approach should i take in terms of organising the projects in TFS Source Control and making full use of the TFS Process Template(SCRUM)?
Should I create a Team project for each product? But that would mean I will have to maintain process template, product backlog and sprint backlog for each Team project. Especially when creating and querying work items, it will involve lot of switching between team projects in team explorer. Similarly, when creating burn down charts/reports, there is going to be one for each of the Team project. This seems like a nightmare!
Or should I create one Team project and put all the products(Visual Studio solutions) under it? This sounds better to me because, there will be one process template, one product and sprint backlog and one place to look at/query all work items.
To me it seems like Team project should map to a Team and not to a Product or Visual Studio Solution. However in my past experience, I have come across places where Team Project is mapped to product/visual studio solution and I am a bit confused.
The term "Team Project" is confusing. I really wish Microsoft had used a different phrase.
Having said that, I don't know what other word or phrase would apply.
A Team Project does not necessarily correspond to a Visual Studio project or solution
A Team Project certainly doesn't correspond to what SourceSafe used to call projects (those were just folders)
A Team Project doesn't necessarily correspond to a single source control tree. The people working on a Team Project may use code from multiple source control trees (assuming this can be mapped into your workspace correctly).
A Team Project more closely corresponds to an endeavor of some kind. This may or may not involve some source code. It will involve some people. It may or may not involve some work items, or builds, or reports, or portal sites, or lab environments, or any combination of those artifacts that are scoped on a per-team-project basis. These will usually be artifacts that will be useful to some "Team" in accomplishing their "endeavor" (which may just happen to ba a matter of producing and releasing some code, using the help of work items, reports, source control, builds, etc.)
I would advise you to create one team project and multiple folders for different solutions.
In other words leave your work as it is and create just one team project.When checking in products codes use server folders. This way you have a unique repository with shared work items and reports
We have a project that will be developed in multiple phases over the next 12- 18 months. It's an agile-esque project in a waterfall environment, it that matters.
My initial thought was to create one team project named 'Project X'. Under Project X could be multiple solution folders but the main development would be in a folder called Main. Branching would be done as appropriate.
The other solution folders under the Project X team project would be for some of the tools we need to build for this project that are independ of the main app, which is a web app. For example, we needed to build an app for processing data and sending it to a web service but it never interacted or merged in any way with the main web app.
The advantages I see to this approach are a) all the code for the project is kept under a single team project and b) all the work items, bugs, wishlist items, are accessible from all the other projects.
Does this approach make sense? Any ideas to improve this? I haven't created the team project yet.
I will simply comment on the advantages you listed to help you understand why this approach isn't ideal.
The advantages I see to this approach
are a) all the code for the project is
kept under a single team project and
Both your tools and your web application are for "This project." That right there is a key indicator that you should use one Team Project inside of TFS. You gain nothing by having two separate Team Projects. In fact, you may make it more difficult to manage.
Consider if you have a requirement that has work one both a tool and the main application to complete. In your scenario, there would be no way to track work history associated to one requirement because you are using two Team Projects. There are many more reasons, you have to manage permissions in two places, have two sets of mappings etc etc.
I would highly recommend you opt to use one Team Project. You, and your entire team, will thank me later.
b) all the work items, bugs, wishlist
items, are accessible from all the
other projects
If you have two Team Projects, you cannot access WIs etc across the projects. In fact, you will have the exact opposite- you will have to create the WIs in both projects if the work crossed over between the two.
You should have one Team Project. A folder for the tools and a folder for the web application. From there you can take it further having it branched off- a branch for development and a branch for main is a good start. Inside each, have the tools and web application so the versions stay in sync.
Here is a good place to start reading before setting up your project: Microsoft Team Foundation Server Branching Guidance.
What you're describing is not a Team Project. You're simply describing the structure of some source control folders in TFS.
A Team Project is a lot more than just source control. From T (Visual Studio ALM Glossary):
team project
The named collection of work items,
code, tests, work products, metrics,
and so forth, used by a defined team
with Visual Studio Team Foundation to
track a common set of related work.
We're starting to user Team Foundation Server and my boss would like some way to "archive" projects. Meaning after they are completed, remove them from an "active" state so that only "active" projects are visible.
Does anyone have any experience with this?
I've thought of 2 options.
1) Create 2 base projects. 1 for active projects and 1 for achived projects
2) Remove all users from the archived projects.
Thanks,
Sam
I would personally recommend waiting for TFS 2010 when more functionality will be introduced that will assist you in the ability to "archive" Team Projects.
In TFS 2010 you will hopefully be able to move a team project to a new Team Project Collection. Actually you do this by duplicating your "active" project collection and then deleting all the team projects from it apart from the one that you want archived. In this active project collection, delete the archived project that you have a copy of in the duplicated project collection. This archived team project will then live in it's own project collection which means it has it's own database etc which can be easily backed up / archived etc.
The archived team project project collection can then be left as it is as it doesn't slow down the server any if not being used - or it could even be detached from the TFS Application instance so that it doesn't show up at all and re-attached at any time.
An advantage of using project collections in TFS 2010 is that full Version Control and Work Item Tracking history will be maintained.
I would use it just as you normally do, but when you are done with the project then you remove it from the visible list. (In Visual Studio you can right click on a project in the team explorer and say remove.)
If you are worried about changes after the project is done, then remove the users from the contributors list. If you really want to boot the users out (so they cannot even see it) then you can deny them rights to the project.
This way you don't have to see it, but you can keep all your projects on the base level.
I would NOT recommend having just 2 base project for active and in-active. A TFS project should not be based on a state.
We created an "Archive" team project and we regularly move unused source code to that team project. It has worked out well for us, the history is preserved so we can always reference the archive project for old code or information on past changes. We also limit access such that developers have read access but only TFS administrators have write access. I haven't checked to see how these moves impact the association of check-ins with work items - mostly because everything we archived was checked in before we moved to TFS.
As for the one active team project, I was led to believe by knowledge experts and online documentation that this wasn't the best way to organize team projects. I think ideally you group projects/solutions together into a single team project if they are related (i.e. by line of business or dependencies).
I'm sure you've already done your research, but there is plenty of documentation out there that might assist (especially if your team maintains a single application or a handful of applications). I would suggest starting with patterns & practices: Team Development with TFS.