Is there any way to create a project in a subfolder in Visual Studio Online using TFVC?
As of now, a TFS Team Project Collection is a flat collection of Team Projects. You cannot organize them in a hierarchy. So you could only depict the hierarchy by naming the Team Projects accordingly.
In a Team Project Source Control tree, you can place many Visual Studio projects and organize them in a folder hierarchy. You can set permissions on specific folders in Version Control if you need to secure some of the projects (though this is not as easy and straightforward as in separate Team Projects).
So maybe it is an alternative to place the projects in a single Team Project and create the hierarchy in source control and areas/iterations. Precondition is are that the projects share the same process; it's also good if they want to share work items or code at least once in a while.
If you want to separate them strictly, you need to create separate Team Projects and do without the hierarchy.
Related
I want to add solution to source control(tfs I am using vs 2015).I selected the option add solution to source control, then one dialog opened, in that dialog there is no option to create a new folder directly under collection, it is always adding to the existing project(folder).How can i create a new folder/project directly under the collection.
The structure TFVC uses for source control is as follows:
Team Project Collection (created by your TFS admin)
$/TeamProject1
$/TeamProject2
etc
You can't add source code directly under a Team Project Collection -- it has to be created in a Team Project. And you can't just create a "folder" that represents a new Team Project. You have to create a Team Project either via the web UI (if you're using TFS 2015 Update 2 or later) or via Visual Studio. The version of Visual Studio used to create a Team Project needs to match up with your version of TFS, as well.
Typically, guidance for Team Projects is to create a single team project for each portfolio of related applications, since each Team Project is isolated from other Team Projects in terms of things like source code, build, release, and work item management. You can use the concept of Teams within a Team Project to create separate backlogs and the like for individual applications.
Some further reading:
Why you should use one Team Project: http://geekswithblogs.net/Optikal/archive/2013/09/05/153944.aspx
Creating a team project: https://learn.microsoft.com/en-us/vsts/accounts/create-team-project
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.
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 are using TFS 2008 for Web App dev. The WebApp is a large project, so we do not want every developer to see all the source code, which means lots of libraries or subapps need to be referenced.If I put all the libraries and subapps in one VS2008 Project or VS2008 Team Project, all the source codes will be exposed to each person.
Do I have to make the WebApp reference other Team Project to solve this problem? What is the best way doing so?
Consider each isolated section to be a project (in both the physical and management sense) as independent. Ship release from those shared components/projects and deliver them as binaries to be pulled into the others. You can use a the output from trunk or release branch builds of the shared components to deliver new "releases".
This affords you the option of full branching, work item, reporting etc for each logical project in your organization.
If you let someone be a contributor/developer on a project, then that individual has access to the entire project. If you want to keep someone out of the certain files, then that will need to be under its own TFS project. You would then reference the output assemblies from the parent project in the child project.
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.