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.
Related
I've recently completed the deployment of TFS 2015 Update 1, we have around 15 development teams in the UK and previously we have always structured our TFS projects as follows:
Default Collection
Application 1 (Team Project)
Application 2 (Team Project)
This caused issues with sharing work items across teams as it is difficult to move WI's across the project boundary.
Rather than create a new team project for each team, I want to manage things with a single team project and create separate areas\iterations\teams for each one. So:
Project Collection > Master Team Project > Area 1
Area 2
Area 3
etc
in terms of permissions I would like to add in each of the standard TFS permission groups to each area. I would also like to create a root folder for source control for each area.
At the moment I can't work out how to do this? Can anyone help?
I suggest you to look at the some community suggestion on this topic.
One Team Project to rule them all
Why You Should use a Single (Giant) TFS Team Project
How to implement a multiple team strategy in Team Foundation Server 2013
In general it is a good practice (I won't say best practice as it is not the right thing to do in some cases).
Regarding you question, you should focus on Team to define developers access, and TFS groups for general (e.g. administrative) access.
I'd recommend you to use the multiple teams feature in TFS2015. It allows you to manage the team members, permissions, work items more easily. And you can track the entire project status from the team project page and track the individual feature team status from their own project page. The work items can be also moved between the teams easily (Just change the area path). Refer to this link for details: Multiple Teams
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.
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.