First a brief explanation about who we are and how we work. We are a small team and we work together with a consultancy in our own project. We work with a main branch and then we create development branches from it each time we need to implement a new feature. When that feature is implemented we merge main branch into development branch and we test it. Once tests are ok, we finally merge development branch into main branch and we test again. If all test are passed in main branch, then we deploy/publish it to production.
Now what we are trying to do is to create a user for consultancy in our TFS system in order to this user can/cannot do following things:
Consultancy cannot create branches from main branch (summarizing they cannot create branches in TFS repository). We will create development branches for them and we will grant permissions for them over each development branch created.
Allow consultancy to get latest versions from development branch and map it into their local computer.
Allow consultancy to work in the development branch by using check-ins and check-outs. Consultancy can do all operations in development branch except merge it into main branch.
Allow consultancy to merge main branch into development branch but not vice versa.
The goal of this is to keep our TFS repository under control.
So how can we create a user in TFS following above rules? Note that each time we create a development branch for consultancy we must grant/deny the corresponding permissions on this user.
You can add Windows user or Windows group in TFS. TFS use the authentication with windows user/ domain user(Active Directory) to access the server. TFS can't create users directly. There are no TFS own users.
Additional: About the relationship with TFS and Active Directory
TFS does not write to Active Directory (AD) nor "has it's own
Active Directory".
TFS stores users and groups, permissions and security, into its own
database. To integrate with Windows Security by running a background
job
every hour and reading users and groups from AD.
You may have to add that user in your AD, and give him access to TFS, finally assign them corresponding permission for each branch, Main & Dev.
To manage branch permission , you could either choose
In Web Portal--Project Settings--Repositories--Branch
In Visual Studio--Right Click--Advanced--Security
For each branch's permission setting, you could directly manage that user's or create a group then add that consultancy in the group, manage the group's permission.
Check in
Check out/Pend a change in server workspace
Manage branch: Users cannot create branches from a branch for which
they do not have the Manage Branch permission.
Merge: Can merge changes into this path.
More details about the description of each permission please take at a look our official tutorial here--TFVC (object-level)
Related
Our office uses VSS as source control. Just come to know that VSTS is free for five users and our team is very small with 5 devs.
I have never use VSTS. so i have few questions. please answer pointwise and with detail along with images if possible.
how to create an account for VSTS?
how to upload our local project exist on my pc to VSTS
how could I send an invitation to other 4 developers in our team, as a result, they can clone our uploaded project on their own pc and start working?
I got one link which is showing how to Add Local Project to GIT in VSTS but I need to know how to add a project to TFVC in VSTS.
Create an account
Go to VisualStudio.com, log in using MSA, pick an available account name and register. If you have an Azure subscription and an Azure Active Directory, you can also create the account from the Azure portal, that way you can use your company-account to log on.
Upload local project
When you create your first project you get to choose whether you want TFVC or Git. Once the project is created, getting your sources in differs depending on your choice.
If you pick TFVC you must create a local workspace on your machine, copy the sources into that directory, then check them in.
Invite other users
To add other users to VSTS they need to have an MSA account or to be part of your AAD (depending on how you setup your account). Then go to the Users hub in the VSTS admin panel and add them to your account. The first 5 basic users are free. If users have an MSDN account (pro or higher) they do not count towards the free user limit as VSTS access is included in the subscription.
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.
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.
I have the following scenario:
I have a Dev and Stage branch
Code is checked into Dev, and at some point those changesets from Dev are merged into Stage
No direct edits/check-ins happen to stage (beyond the merges from dev)
What I want to do is identify/verify that no new code has been introduced directly into the stage branch which did not originate from a changeset in Dev.
It does not appear possible to secure Stage (from a source control perspective) to only allow check-ins of merges from dev (since all operations appear to be merge,edit after I do the merge), so what I thought I could do is create a TFS Check in policy which attempts to compare the merged changes to their source.
I have created a class which derives from PolicyBase and have over-ridden the Evaluate method. In the Evaluate method, I spin through this.PendingCheckin.PendingChanges.CheckedPendingChanges and check the .IsMerge property and .ServerItem property to see if the item in question is a merge and is destined for my Stage branch.
When I spin through each change however, I don't see a way to track its lineage or access the parent from where it might have originated (ie: the Dev branch version #).
How do I only allow merges, but no direct edits on my Stage branch?
The only way to achieve this in TFVC is for you to take ownership of all merges. If you do the merge then you have the control. Many organizations with these sorts of draconian policies create an automated script that does the merge and rejects if there are any conflicts. That way the developer is forced to pull from Staging to Dev and resolve all conflicts before requesting the merge through a web portal. If the merge is successful it was conducted on a server by a single service account and no coder required permissions to Staging of any sort.
This is however dysfunctional. Either you don't trust your coders, or they are not competent enough to work in your code base.
Another method might be to move to Git in TFS for source control. In Git merges are non-editable and are performed as a single action rather than the merge/edit you get in TFVC.