We're working on getting better use out of our TFS/TFVC server and move to benefit from TFS Work Items, and I have been put in charge of figuring out how to do so.
We have a lot of projects, most of them working with common code libraries. Our way of implementing new features have been to just include a reference to the code and build it all together when changes are needed, instead of referencing DLLs for the libraries.
My question revolves around setting up workspaces that don't end up making this a hassle when updating code in common libraries as well as the main project being worked on.
In working with this briefly, I have created multiple team projects for each product we're developing and it looks like the individual developer has to make sure to move between all the workspaces connected to the individual project and check in code for each of them. I feel like this is clunky and that there must be a better way to get this done.
A structure could look similar to this:
ROOT
|- Common Code
|- Team projects (each having their own backlog and referencing "Common Code"
|--- Product one
|--- Product two
|--- Product three
Would a better approach be to work on a single workspace and just create teams and have backlogs for each or is there a clean way of allowing the developers to utilize a common code library from individual Team Projects?
There are a lot of considerations going into the setup of your team projects. The most important reason to separate out to different project is security. If you have a need to ensure that different projects can't see the metadata of other projects, then a single Team Project is a bad idea.
If your teams have major differences in the process they follow, they may also have a need for different Team Projects, as the Process can only be defined at the Project level and all teams under the same Team Project have to follow the same process (either Scrum, CMMI, Agile or a custom Process). It may be worth to move your teams to the same process template though, there are not too many differences between Scrum and Agile, so unless you depend on CMMI or a heavy custom template, you can practice Scrum and something other kind of Agile in either template with a little bit of fantasy.
In all other cases it may be valuable to consider creating a single Team Project and using Team Backlogs to represent your projects. This approach is commonly called the "One project to rule them all" setup.
As for your "common code" project, I'd personally consider using the Package Management features of Visual Studio Team Services to generate NuGet packages of changes made to common code. The ALM Rangers have written some guidance on setting this up in the past, it's not updated to the latest version of VS and TFS, but it does give a nice outline of the process. Then include these common libraries as NuGet package references to your other projects. This gives you more control over when specific projects upgrade to a specific version of the common libraries and it results in a nice separation between the different projects using the common libraries. After having done this, it's also easier to setup things like Continuous Integration, Gated Checkins etc. working with complex workspaces will make that harder as well as you'll find out.
So it'll look like:
+- YourAccount.visualstudio.com
+- CompanyProject (Team Project)
+- TFVC Repository (Can only be one)
+- Common (folder)
+- Project 1 (folder)
+- Project 2 (folder)
+- Project 3 (folder)
+- Package Management nuget repository
+- Common
+- Teams
+- Root / Company
+- Project 1
+- Project 2
+- Project 3
If you move your projects to Git, it also becomes a little easier, as you can have multiple Git Repositories under the same Project.
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.
Our team works on a Agile methodology, having specialized teams in different parts of the product. Currently we have everything in a single Team Project, but we want to restructure everything so that we can apply a nice functional continuous build as right now, we have a build definition for our backoffice and one for our website. The problem is that if we make any change inside that team project, even if it's a text file, everything will go to queue and that is causing us big problems. So, this is how we would kill our problems:
# = Project Collection, > = Team Project, | = VS project
# PRODUCT
> Core
| CoreProject
> Integrations
| IntegrationsProject ( makes use of CoreProject )
> Backoffice
| BackofficeProject ( makes use of CoreProject and IntegrationsProduct)
> WebSite
| WebsiteProject ( makes use of CoreProject and IntegrationsProduct)
What this would allow us:
- Diminish the amount of builds in the queue
- Create branches of Integrations, which would not be changed often
- Restrict access to Integrations and Core to specialized teams ( even if i know this can be done in other way )
Questions:
Is this the possible best solution for our requirements? If not, what
would it be?
Let's say, working in WebsiteProject solution and having projects from diferent team projects in that solution, is it possible to checkin does projects?
Thanks!
I suggest having one big team project, and just have 4 root folders in version control, and 4 build definitions that have the workspaces mapped to each of the 4 root folders. So long as you have the build workspaces mapped appropriately, checking in files to one folder, won't trigger the builds for the other folders.
This also allows you to set separate security permissions on each root folder should you wish.
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.
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.
Our .NET team works on projects for our company that fall into distinct categories. Some are internal web apps, some are external (publicly facing) web apps, we also have internal Windows applications for our corporate office users, and Windows Forms apps for our retail locations (stores). Of course, because we hate code reuse, we have a ton of code that is shared among the different applications. Currently we're using SVN as our source control, and we've got our repository laid out like this:
- = folder, | = Visual Studio Solution
-SVN
- Internet
| Ourcompany.com
| Oursecondcompany.com
- Intranet
| UniformOrdering website
| MessageCenter website
- Shared
| ErrorLoggingModule
| RegularExpressionGenerator
| Anti-Xss
| OrgChartModule etc...
So..
The OurCompany.com solution in the Internet folder would have a website project, and it would also include the ErrorLoggingModule, RegularExpressionGenerator, and Anti-Xss projects from the shared directory.
Similarly, our UniformOrdering website solution would have each of these projects included in the solution as well.
We prefer to have a project reference to a .dll reference because, first of all, if we need to add or fix a function in the ErrorLoggingModule while working on the OurCompany.com website, it's right there. Also, this allows us to build each solution and see if changes to shared code break any other applications. This should work well on a build server as well if I'm correct.
In SVN, there is no problem with this. SVN and Visual Studio aren't tied together in the way TFS's source control is. We never figured out how to work this type of structure in TFS when we were using it, because in TFS, the TFS project was always tied to a Visual Studio Solution. The Source Code repository was a child of the TFS Project, so if we wanted to do this, we had to duplicate the Shared code in each TFS project's source code repository. As my co-worker put it, this "breaks every known best practice about code reuse and simplicity". It was enough of a deal breaker for us that we switched to SVN.
Now, however, we're faced with truly fixing our development processes, and the Application Lifecycle Management of TFS is pretty close to exactly what we want, and how we want to work. Our one sticking point is the shared code issue.
We're evaluating other commercial and open source solutions, but since we're already paying for TFS with our MSDN Subscriptions, and TFS is pretty much exactly what we want, we'd REALLY like to find a way around this issue.
Has anybody else faced this and come up with a solution?
If you've seen an article or posting on this that you can share with me, that would help as well.
As always, I'm open to answers like "You're looking at it all wrong, bonehead, HERE'S the way it SHOULD be done.
I think there's some misunderstandings here. First, you can have multiple (as many as you want) solutions in a single TFS project. Also, a single Visual Studio project can have any number of solutions referring to it.
Second, what version of TFS are you using? 2010 is different from 2005/08 in how it handles TFS projects.
Under 2008, there are several ways to approach this depending on what you want to get out of it. You can either have multiple TFS projects or a single TFS project.
I'll start with multiple.
Set up a TFS project for your shared library type code, and others for each regular project you have. As part of the development process on this shared library, check in the completed assemblies. Then Branch those assemblies into any other TFS project you want to use them in. When you do a feature update or bug fix to the shared library, simply merge the branch into any other TFS project you want the updates to go into.
This allows you to make shared changes for a single app without having to push all of them.
If you want a single TFS project holding everything, just add folders for each Visual Studio project you want. The visual studio solutions can refer back to projects outside of their base tree without issue. Now, when configuring things like Builds for each solution, make sure you limit what directory the build server pulls from / watches. That way you don't have it building one of your internal sites when changes were made to an external site.
Only recording this in the hope that it helps someone else some day, I fear I'm a little too late to answer your original question ;)
We have a very similar situation, and your question (and subsequent answers) made it very easy for us to set up TFS properly.
To use your example to explain our setup:
# = Project Collection, > = Team Project, | = VS project
# SVN
> Internet
| OurCompany
| OurCompany2
> Intranet
| UniformOrdering
| MessageCentre
> Shared
| ErrorLogging
| RegularExpression
This means that work can be assigned (using Scrum templates in Sharepoint) to any of the Team Projects (which are SAAS apps in our case) and the developer can choose to open any or all of the VS Projects to get the job done.
The majority of the senior developers (those that are across multiple products) have one VS Solution (maybe "WholeEnterprise.sln" to continue the analogy) that contains ALL the different VS Projects and can therefore work on any/all of them at any one time. We can also ensure that projects build properly, and all the dependencies are up to date before pushing an update.
The structure of this in your operating system of choice is totally up to you! Some of us have replicated the structure of TFS, others have a totally flat hierarchy... This doesn't seem to make a difference at the end of the day.