I'm the TFS admin at my company. In the past, I have recommended a linear branching strategy for small teams that are also new to TFS. Start in Dev > Dev merge up to Test > Test merge up to Prod.
This works well with solutions whose projects are subdirectories of the solution. What about projects that are dispersed throughout source control?
Can I create a single branch that that can manage projects dispersed in various locations in source control?
E.G.
\$TFS\Dev\Project1
\$TFS\Dev\SomeFolder\Project2
\$TFS\Dev\SomeOtherFolder\Project3
We have a main project that houses all our Assemblies. This project is the "build all" project. It is used with finalBuilder pro to perform the deployment to the next tier. The issue is that these projects are spread out all over source control. I'm not sure how to manage them.
Yes. With Team Build, not only you can build solutions across branches, you can build solutions across different team projects. However, I think the best practice is keeping each project and each branch with their own build definition.
In your case, I'd first try to organize the source tree, then define a master solution that builds all projects. FinalBuilder should support your scenario, though I think FinalBuilder is redundant when you have TFS.
My suggestion is to identify which "projects" are released and versioned independently, and have separate branching structures for each of those.
You don't want to have 2 independent projects (by independent I mean they are released/versioned separately) within the same branching structure.
The typical way to manage dependencies between these projects is to checkin the binaries from Project 1 Version X into the Project 2 "lib" folder. That way you can release new versions of Project 1 at will, but the Project 2 team can decide when and if to take a dependency on the new version.
If your various "projects" are all pieces of the one big thing that is released/versioned together, then I'd recommend just making sure they all live under some root folder (e.g. $\TFS\Dev) and branch from there.
Related
I am installing TFS 2018 on premises and I want to try to enforce some logical folder structure where all of the deposit related projects\development are in the Deposits folder. All of the lending in Lending etc. etc.
I created two collections one for testing of the tfs installation and a production collection. It seems you can only create Team Projects in a collection. Is there no way to create a hierarchy?
Or how about a sub project? I don't want to have a team project for every single task. Some tasks are tiny while others are large multi programmer projects. And if I create a Team project for say Deposits and have folders for each task\project then won't I lose the extensive amount of ALM features for projects? I mean, won't they comingle when they are all under one project?
I must be missing something. Even sourcesafe allowed you to create a working folder. thanks
Hierarchies are established within team projects. A team project is a portfolio of related applications.
Use teams, iterations, and area paths within a single team project for organization of work items. Iterations define your schedule for work, and area paths allow for organization of work items for filtering and assignment to specific teams.
For source code, if you're using TFVC, you can either create folders within a single team project and enforce access via security settings, or create separate team projects for each unrelated suite of applications.
A typical TFVC structure within a team project would be something along the lines of
$/MyTeamProject
/ApplicationX
/Main (trunk)
/Dev (branch from Main)
/ApplicationY
/Main (trunk)
/Dev (branch from Main)
Or if ApplicationX and Y are related and need to be branched together, you invert the structure:
$/MyTeamProject
/Main (trunk)
ApplicationX
ApplicationY
/Dev (branch from Main)
ApplicationX
ApplicationY
For Git, you can either keep unrelated applications in separate repositories, or adopt a monorepo approach. Each approach has advantages and disadvantages and will require you to do some research to decide which one fits your use-case.
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.
I am new to VS Team Foundation Server 2015 and there I have project for example "WebProjectA". I also have MVC .NET Project called "WebProjectA".
How to manage that project in TFS when I have 3 environments (Development, Testing, Production) ?
Need I have 3 TFS Projects
WebProjectA_Development
WebProjectA_Testing
WebProjectA_Production
Or can I place all WebProjectA solutions to one VS workspace or 3 workspaces and somehow to link it to the TFS and have version system enabled per solution in one TFS project ?
How do you solve this situation ?
I would handle this using a TFS branching structure. Create a single Team Project, called WebProjectA, and a single branch called Testing. Then, branch off for Development, and again for Production. This means that, when you make a change in development, you can merge through to testing, and again into production.
It also gives you the flexibility to switch to feature branching at a later date, and to maintain multiple production branches, should you wish to.
Further reading
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 have a Team System environment where our applications are set-up as separate Team Projects. Often, we run into a scenario where a development task requires updates to code in multiple Team Projects.
In this scenario, what are the pros/cons to having a single changeset that contains coding changes across multiple Team Projects? What are the pros/cons to using a one-changeset-per-Team-Project approach?
Providing the changes are made within a single workspace and all the team projects are in the same project collection (this applies to TFS2010) then a single checkin can span multiple team projects.
Within a single server (TFS2005/2008) or team collection (TFS2010) there is a single version control repository with the team projects defining the root folders: all version control operations can span different team projects.
I see no problem with this approach. Remember that TFS will allow you to rollback to the previous changeset, or inspect the files affected by a changeset (comparing to previous versions) so you can rollback some or all of your changes if required.