I am currently setting up a VSTS project for our team, and want to follow the MS approved 'One project with multiple areas' approach. I'd would like to silo the git repos on a per team basis (similar to how the work items work), however the teams all have the same members. Is this possible? Here's an example...
I create a project in VSTS, let's call it MainProject. I also have a team of 4 developers, and they are all members of a group in VSTS called MyDevGroup.
Under MainProject, I set up two teams, and two areas, let's call them Main Project / Team1 and MainProject / Team2. I add the group MyDevGroup separately to the security for those two teams. At this stage, if one of the team access this through VS, they can see those two teams, and if they were to add a new Work Item, depending on which team they had currently selected, it would assign it to the correct area. This is great.
I also create two git repos, let's call them MainProject / Repo1 and MainProject / Repo2, and assign Team1 at a contributor level to Repo1, and Team2 to Repo2. However, in VS, if the user is currently looking at MainProject / Project1 team, they can still clone either repo - they see both.
This is problematic, as you can imagine a scenario where a user might have the Team1 team selected in VS, but accidentally check out Repo2 and work on it.
So, is there a way to restrict a repo to a team?
EDIT: Further to this, I realise that once you open the solution in a particular repo, close VS then re-open it, it will refer to the correct repo. However it doesn't keep the reference to the correct team. It keeps the last team opened rather than the team I'd selected for the solution. Is there a way to have VS keep the team I had selected when I closed the solution?
EDIT 2: Duplicate of this - VSTS/TFS GUI: Auto-switch repository per team view?
As per this link, this is not possible with the current functionality of VSTS. Hopefully this will be possible in the future.
Related
I have a class library project to be shared by two different solutions in Visual Studio 2017. The solutions are mapped in two different workspaces. I cannot find a way to get the shared project under source control in both solutions. Any suggestions?
I'm assuming that you have two separate Team Projects, each with its own TFVC repository. Underneath one of those Team Projects (say, TPA), you have a common library that you'd like to share with a solution located in Team Project B (TPB).
You can't do what you're asking to do -- even if you could do it, you shouldn't. You don't want to fork the source code and maintain two copies of it. What you want to do is one of the following:
Map a single workspace containing all of the Team Projects and use relative
paths for references. This isn't great, ideally each Team Project is considered a totally separate entity.
Put everything in a single Team Project and maintain a single workspace for everything.
Turn the shared component into a NuGet package and use a Package Management feed. Each consumer of the shared component can then reference a common NuGet package.
I'd say #1 is already excluded as an option. Each Team Project should be an independent entity with nothing shared between it. Since you have things shared, you've chosen the wrong organizational structure. Stop using multiple team projects.
Option 2 is okay, but it's a little bit clunkier.
Option 3 is the preferred, modern way of managing cross-project dependencies. I'd strongly recommend looking into implementing this pattern. If you adopt this pattern, maintaining multiple team projects becomes acceptable again -- you have one Team Project that acts as a publisher of shared components, and another that acts as a consumer. That's sufficiently isolated to consider them independent of one another, and thus an acceptable candidate for multiple Team Projects.
It's worth noting that the modern thought among most experts in this area is that maintaining a single Team Project for all related applications is the correct approach. I've seen teams with hundreds of members and dozens of applications using a single properly organized Team Project with no problems.
While I agree with Daniel on the fact that this is probably a bad idea and that there are alternatives, it's perfectly possible; there's one restriction though: each workspace must have its own copy of the shared project on your hard drive, they can share the remote copy on the server. This si very similar to a distributed source control model and can work just fine.
To make this work, first create one workspace and map the folders locally:
Workspace 1
$/Common/ => c:\src\1stProject\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Then create a second workspace:
Workspace 2
$/Common/ => c:\src\2ndProject\Shared
$/ProjectB/Solution => c:\src\2ndProject\SolutionB
This way both projects share the same server location and changes made to Shared will directly impact both SolutionA and SolutionB. Locally though, each solution will have its own local pending changes etc.
This solution will work as long as both Team Projects are in the same TFS Project Collection.
The only limitation is that these projects can't be placed in a subfolder of each other, so you can't do this:
Workspace 1
$/Common/ => c:\src\1stProject\SolutionA\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Nor can both workspaces map to the same local folder:
Workspace 1
$/Common/ => c:\src\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Workspace 2
$/Common/ => c:\src\Shared
$/ProjectB/Solution => c:\src\1stProject\SolutionB
Alternatives
Nuget
Instead of using shared sources directly, add a NuSpec to the Common project and build & publish the NuGet package to the VSTS package management feed of the VSTS account. Add a NuGet reference to SolutionA and to SolutionB. That way the binaries of Common are shared among SolutionA and SolutionB, but common is maintained independently. This way it's also easier to update SolutionA at a different cadence than SolutionB (this is also the biggest pitfall for this solution).
Git & Submodules/Subtrees
Convert the TFVC repositories to Git repositories. That way you can use Subtree or Submodules to reference Common directly from the SolutionA repository and the SolutionB repository.
MonoRepo/One Project To Rule Them All
Merge all your TFVC repositories into a single TFVC repository, that way both projects can easily live inside the same workspace. Technically this isn't needed to put both projects in the same workspace, but it is easier. It results in a very similar solution as described above:
Workspace Single
$/Project/Shared => c:\src\Shared
$/Project/SolutionA => c:\src\1stProject\SolutionA
$/Project/SolutionB => c:\src\2ndProject\SolutionB
Would result in the same as the following cross-project layout:
Workspace Single
$/CommonProject/ => c:\src\Shared
$/ProjectA/ => c:\src\1stProject\SolutionA
$/ProjectB/ => c:\src\2ndProject\SolutionB
Note
In any cross-project setup, the UI of both Visual Studio and VSTS will fight you. The VSTS team has been working on the ability to make individual Team Projects portable across accounts. In order to do that features like these will need to be dropped at some point. The UI in VSTS build, for example, will not show any other Team Projects in the Source picker. If you type the paths manually they will work (as long as you configure the build to have a Collection Level scope).
Advice
The Nuget solution is the most reliable solution for the type of problem you're trying to solve. The VSTS Package Management feature will allow you to easily share the Common project across multiple projects and even across other VSTS accounts is you want to in the future. It's the most reliable solution.
If you need to be able to edit the files in either solution, I highly recommend you look into Git Subtrees or Git Submodules. Git is the future in any case and these features will allow you to achieve what you need in a much easier to sustain way. They do come with a steep learning curve though.
Our TFS Source Control is setup like this:
TFS Project
Solutions
WebApp1Solution
WebApp2Solution
Libraries
SharedLibrary1
Web Applications
WebApp1
WebApp2
When I open solution WebApp1Solution, it loads my workspace with projects from Libraries and Web Applications folder.
I would like to suspend my current workspace environment for both web apps and all shared libraries and start working on a specific version of this code from an earlier label (our last deployment). We do not have any branching as of yet.
From what I've read, I think these are my options:
1. Shelve pending changes on the solution and get the specific label version of the solution. What would happen when I check any changes back in?
2. Create a branch in Source Control from the specific label version. Would I have to create the branch on all of the folders in the different locations? How would I switch back and forth between my current code and new branch code?
Any help or advice will be greatly appreciated! Thanks!
Just create a branch at your TFS Project folder into a development folder. You should actually be doing this normally for all of your development. Your mainline branch should never contain anything except for your production deployable codebase. You should always be able to get latest of your mainline and build and run as the production end product.
All developers/teams of developers should have their own TFS folder where they can branch from mainline, make changes, test, etc... then once it has passed all approvals, merge it to mainline and destroy your devline.
As for "switching" your branch is a separate folder from your mainline. You can open both at the same time in different instances of Visual Studio, just like opening two solutions at once. Branching creates a copy of the folder/solution/project structure from the point of your branch. Then when you merge it back it reports differences and attempts to merge. If there are conflicts you will be prompted to review and resolve them. Most of the time TFS does a good job at auto-resolving, but I always carefully review all conflicts before selecting a method of resolution.
I am the sole developer on a project for my client.
Clients wants me to checkin (process/formality) the source to his repository in Bitbucket.com. However, I use the TFS VisualStudioOnline.com
Bitbucket: His motivation was to look and have an internal deposit of my regular code for weekly draws.
VisualstudioOnline.com: For me, I use TFS extensively and need to maintain my checkins here, with my code and builds.
Questions: How can I maintain/add two source controls on one project? (where one project is mostly a readonly/view only checkin)
That's very easy: just add an additional remote to the Git repository, something like
git remote add customer http://bibucket.com/whatver
If you want to "filter" what you push to customer, say have one commit instead of three, then things starts to complicate a bit.
Let say there is a team working on main Git repository using branching model. Now a second team joins and is starting to work a subset of a project. As the starting point they need to collaborate on one folder from the repository. They are not allowed to see rest of the code base. What is the best way to achieve that?
Going forward they would need to be able to merge their changes into the main code base and get any updates from that one folder along the way too.
This is all based on Windows OS with Atlassian Stash and Git on internal network.
That would mean that one folder needs to be its own repo:
added as a submodule (tracking a branch) in the main Git repo
forked by the second team, for them to push to the fork and make PR or synchronize from the original folder git repo.
I would suggest separating the subset into a sub-project, and use language-specific ways to deliver it during building of you main project. For example, if you use MS Visual Studio, you could turn it into library or module and use nuget to deliver it during build of your main project.
In my experience it appears to be much more convenient than using submodules, when it comes to merging.
Another reason to do that - and maybe even more important one - that the other team would be able to handle the project as a compilable and testable unit, instead of a pile of source files.
We are using Team System 2010 and trying to adopt Scrum by using the template "Scrum for Team System". In TFS, we have many team projects that span across the single development team. To simplify, I'll explain it like this: We have 2 Team Projects that are web sites. We have 5 more Team Projects are 5 web control libraries used in those 2 web sites. As 1 Development Team, we have 1 Scrum master and 1 Product Owner over those 7 different Team Projects.
Anyone else in this configuration?
How do I bring all this work together? We need to manage releases over all those projects. Our Sprint planning meeting will deal with all those projects, so at the end of meeting, we'll have post-it notes (Product Backlog Items) that could deal with just a web site project or a control library that needs to be implemented in either of the sites.
Do I need to create another Team Project just to create work item artifacts and generate my reports (Burndown chart, etc)?
You can't have hierarchy between Team Project, this feature doesn't exist and there's a reason for that.
You made a mistake that everybody make the first time using TFS: too many Team Projects.
Lot of people do unconsciously one Team Project per Visual Studio Solution.
If you have a development team that works on a family of applications/products that share the same release cycle (or close one) then use just one Team Project.
The only advantage you have using many Team Project is a different process template can be used for each and you can upgrade your Work Item Type (WIT) definitions independently (this advantage by the way most of the time a living hell because you have to keep in sync the WIT across all Team Projects).
Otherwise you only have inconvenient (more WIT definition, more WIQ, more branches, more reports, more administration).
To implement a notion of hierarchy (whatever the hierarchy you want), you have to rely on the Area Path of the Work Items. Then your queries and reports will be able to be scoped at will.
By the way, any reason for you to not use the Microsoft's Scrum Process Template ?