Question

I have a team of about 20 developers working together on a single project. This project has several components that involve hardware, firmware, software, and even web capabilities. We would like to track the progress of the project overall using TFS 2013. However, we are having trouble figuring out how we can manage the source control side of things using a GIT repository. The Hardware team is going to need to be able to LOCK their code to work on it, since they are dealing with binary files for laying out circuits and all other things hardware. We are currently considering having the hardware part of things be its own project, and the firmware/software side of things be its own project, using a GIT repository.

A concern we have is that TFS 2013 seems to require any work items to only associate with checkins from the same project. So to overcome this, we will have all firmware and software in the same project, but divided into several different Areas. We are concerned that if it is all in the same project, and using the same GIT Source Code Repository, we may run into issues when different software areas are released at different times, and when there are a few branches for each area. Combined, we could end up with tons of branches. Is there a problem managing these?

Can TFS 2013 be configured to allow work items to span projects? Can GIT be set up to use separate repositories for separate areas of code even though they are all in the same TFS project?

Are there any suggestions as to how to manage this, or is this unmanageable in TFS 2013?

Thanks for any help, comments, or advice.


Added this later:

After reading the answer to this post, and talking to some of my associates, it appears that the best route for us to follow in the above scenario is to have 2 projects. 1 for Hardware, the other for Software/Firmware. Hardware will have its own non-GIT repository, Software/Firmware will share a single GIT repository. We will define master branches on the GIT repository. One for each of the software programs. The programs will be each assigned a different area. This way, for the software and firmware, we can keep the programs isolated, and also have all of them visible in the same project in TFS for project management and colaboration purposes. It will also allow us to associate all check-ins with TFS items, and will allow for QA to associate bugs with tasks, and with areas, all in one project. Hardware will be treated independently from the software/firmware part of the project.

Was it helpful?

Solution

You can use Teams and multiple repositories to accomplish this, all from within the same Team Project

Step 1: Split your different kinds of work into teams. Here's a good post on adding more teams inside the same Team Project: http://msdn.microsoft.com/en-us/library/vstudio/hh500414.aspx

Step 2: Create a second repo for your hardware code. Here's a link on how to do that (about halfway down the page): http://msdn.microsoft.com/en-us/library/hh850436.aspx

An alternative method would be to use just area paths to indicate what portion of the code your team is working on rather than separate teams (which are really just area paths + permissions anyways). Here's a good link on working with area paths: http://msdn.microsoft.com/en-us/library/vstudio/ms181692.aspx. You'd still use separate repos however.

What I would absolutely not do is create more than one Team Project. That path leads to nothing but headaches in the future. Use area paths and/or teams to organize instead.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top