Working and building a project with multiple developers with specified permission for each one? - tfs

We are two developer(me and my friend) and working on a MVC ASP.Net project in Visual Studio 2017 with TFS Online(visualstudio.com, TFVC).
All of us have full access to all files for developing and building to view and test.
We want to outsource part of our project to another developers and we don't want to access full permission of project files to new developers.
If we didn't access full permission to all files to new developers, they can't build project to view and test.
Is there a way to access just some files of a project to another developers but they could build project to view and test?

VSTS/TFS grant users the specific set of permissions that are appropriate for certain roles in your organization. Details of permission please refer this link.
It's not hard to restrict someone to access some project files. You could just deny the Read permission on a folder level when using TFVC source control.
Read
Can read the contents of a file or folder. If a user has Read permissions for a folder, the user can see the contents of the folder
and the properties of the files in it, even if the user does not have
permission to open the files.
If you are using the host agent to build, during the get source step. You(=the new developers) are using your own account to pull source from server to build agent. Without the access to some files in the project, you could not pull down the entire project source code. Definitely, you should not be able to run the build as well.
If you are using the private agent to build, it's able to use network service account as the build service account and queue build. Just give the build service account appropriately permission, you should be able to pull down all source files in the project and run the build. However, since you have denied the access of some other files in the project, it's also not able to view and test them .
In this case, as a workaround, suggest you create an apart branch with your main develop branch, just put some files which your new developers need to work with in this branch. And deny their access to your main branch, When their work have done, they could build/test on the new branch.
Once everything is fine, they could merge changes from the new branch to your main branch. You could then also build/test the entire project in the main branch again.
With this kind of architecture, it's more easy to manage both permissions and team work.

Related

How to manage access in a projects of solution

I have a solution that contains several projects, I want a team to work on this source code, but every developer can only see his own project and can't see the rest of the projects. But he can build and run the whole solution. What solution do you have for this?
It should be able to achieve this no matter you are using TFVC or Git as your source control.
TFS build is using build service account not the user which trigger build. Once the build service account have appropriate permission, it will get source from TFS server and download to build agent.
The permission in TFS is mutual independence. And permissions can be granted directly to an individual user, or to a group.
In version control permissions, explicit deny takes precedence over administrator group permissions.
You could deny the Read permission for those users. And set the other related build permission such as view build definition and queue build to allow.
Read
Can read the contents of a file or folder. If a user has Read
permissions for a folder, the user can see the contents of the folder
and the properties of the files in it, even if the user does not have
permission to open the files.
Queue builds Can queue new builds.
View build definition Can view build definition(s).
View builds Can view builds belonging to build definition(s).
...
However, there is still some difference for Git and TFVC for control project permission:
In TFVC you can open the web portal and go to the code tab. There you can right click on any folder and select permissions. You can use any fine grain you like and control inheritance.
In Git you can only control permission ls at the Repository and Branch level.
Besides, you may also need a account with full permission of solution and all projects to create the build pipeline. Otherwise, the user may not able to select the mapping relationship in source get configuration.

Jenkins: how to control projects based on name using regexp?

For each application, we create a AppName.Dev and AppName.Rel project in Jenkins to build the Development and Release branch. Now we want to allow only certain people to modify/run the Release builds.
Currently we are using this Role/Folder based access control plugin: https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin
e.g., I have a Role/rule called TE/TS.* so everyone in domain group TS has full access to projects inside TE/TS folder. Inside this folder has projects such as App1.Dev, App1.Rel and App2.Dev, App2.Rel,etc.
Now how can I allow everyone in TS still have full access to *.Dev project, but not the *.Rel project, then only have a TS_REL group have full access to *.Rel projects.
Another approach would be separating .*Dev projects into a TE/TS/Dev folder and *.Rel projects into TE/TS/Rel folder.
The following rule can restrict users to all projects with name ended with .Release in folder TE/TS.
TE/TS.*.Release

TFS: Is is possible to transfer all checked out files from one user to another?

I am developer and work with TFS for a while but never have the responsibility of TFS admin. We have a user that was let go and now his userId has been revoked so we cannot use his id anymore.
He has so many files checked out in TFS and a lot of stuff done, we don't want to lose these checked out files if possible. Is there a way to transfer all his checked out files to me or someone else? Or what is the best way to recover these files?
NOTE: we still have his laptop with all the files, we just cant login to it with his username.
Thank you for your help in advanced
Download TFS Sidekicks (get the right version for your TFS)
They have a Visual Studio Add-in if that is what you are using as your IDE
Backup his files that you want to keep
Use the Workspace Sidekick of TFS Sidekicks to delete his workspace(s)
(this won't delete his files).
This will release any exclusive locks that he has effectively undoing all his checkouts.
You can also use the Status Sidekick to see what files he has checked out.
Get latest source and copy his files over yours
If you are using TFS2012 or later, you can use a 'local' workspace and simply copy his files over. Team Explorer will create your pending changes for you. If you are using a 'server' workspace or a version of TFS prior to 2012, you will need to full check-out everything and THEN copy his files over.
It's not a great solution but it should work for you
The changes to the developer's files that are checked out will be stored locally on the developers machine (specifically in their workspace directories) - transferring "check out status" would seemingly not accomplish what you hope.
You would need to obtain access to the developer's workspace (perhaps via an admin account on the dev's machine), copy out all the contents to a new workspace you own to consolidate differences between "source" and "new workspace".
Once you've copied the developer's workspace to a new workspace you own, you can simply compare "source" to "workspace" to find all the changed files and which are needed vs. not needed. Note, this should be done sooner rather than later as the longer you wait the more differences there will be between the two, making it harder to identify what is actually needed.

Allow create and edit build definition, but not edit existing definitions

I manage a large TFS 2013 team project, whose code we're now splitting into multiple independent parts, each part becoming a tenant in the team project. Each such part would have its own build definition(s). I want people in each part to be able to create/edit/manage their build definitions, but not others.
Currently, I create the build definitions myself upon request, and then set permissions on the new definitions, and tell people to edit them. I have permissions to that since I'm in the Builders VSO group, and therefore have Edit build definition and Administrator build permissions on the Team project.
However, I'd like to grant everyone the permission to create new build definitions and administer them, but not have permissions to change other permissions. Is this possible in TFS?
Its not currently possible to do that out of the box. However, you could setup a webpage that automated the task that you currently perform and add a new build definition and give permission to the correct team... Then they can manage it from then.
I would recommend using PowerShell for the action and the webpage mearly calls that.

TFS Folder creation and update permissions set to readonly

Over the last several months myself and those on my development team have run across a new issue. When TFS creates a folder or does a 'Get latest' and overwrites any of the files in the folder structure, it changes the folder permissions to 'Read-only'. This causes an issue, an inconvenience really, where when we go to build the project it will tell us that our access to those folders is denied. If we open the folder and un-check 'Read-only' we are then able to proceed with the build and/or publish of the solution.
We have checked with our networking department, this is not a network setting and is not occurring anywhere outside of TFS. This is only occuring when TFS creates the folder.
Is anyone else having this issue? I've been pouring over settings off and on, trying to determine if I can change this setting. I do not want the folder to be read-only when it is generated or updated.
This is by design but your inconvenience is not. In TFS 2012 (with VS2012) Microsoft introduced local workspaces that do not put anything as readonly.
You can go to the settings of your workspace and change it from server to local any time.
You are also making a common mistake in that you have files that change during a build under source control. If you remove those files you will be able to build even with server workspace.
It is bag practice to put files that you generate under source control.

Resources