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
Related
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.
On our TFS Server, we have a Team Project called "Connect". The root folder for that Team Project contains the root of the web application project. I'm not sure if it was setup correctly, but what I'm trying to do is create a branch of the "Connect" Team project so there are 2 versions, 1 for Production, 1 for a new development/enhancement. What are the correct steps to get the right structure? So that we can work on the enhancement in one, and eventually merge it into the production branch....
You'll have to do some restructuring here. At a minimum that is probably:
$/Connect
---------dev
---------main
Where dev and main will become your branches and contain all the code that is currently in the root.
I'd usually expect to see something more like
$/Connect
---------ConnectWeb
-------------------dev
-----------------------src
--------------------------Connect
-------------------main
-----------------------src
--------------------------Connect
where dev and main are the branches and Connect contains the files and folders currently in root. By putting the branches in another folder (I called it ConnectWeb) you have the option of having multiple development projects within the same Team Project which allows you to manage a portfolio backlog in a single team project.
Rename or move files and folders
I'm using TFS2013 to build and publish a single Web project to a local folder on the build machine. As specified here I just add the parameters below as msbuild parameters and it works, including the Web.config transforms.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sharedfolder";AutoParameterizationWebConfigConnectionStrings=false
Now I'm dealing with a solution containing multiple Web projects. I'd like to end up with multiple local folders, one per Web project. The solution above doesn't seem to work (only generates one of the projects). I also checked the _PublishedWebsites in the drop folder but those files don't have the transforms applied.
Is there a way to do this?
you can achieve this by setting up publish profile for each project. Add publish profile for each Project with same name. you can use File system Publish Method to Publish the output to different directories for each project.
Just call the Publish profile in the Ms-build Argument.
/p:DeployOnBuild=true;PublishProfile=yourProfileName
Follow this link for more details http://msdn.microsoft.com/en-us/library/dd465337(v=vs.110).aspx use File System instead of Web Deploy.
We use TFS as source control. In TFS we host a solution consisting of multiple Visual Studio projects. We do not want our contractors to see the source code of ONE of these projects (limited users should still see all compiled assemblies). What is the best way to achieve our objective without setting up two repositories and having to synchronize all code changes between them?
I would recommend that instead of just changing the permissions in place that you move the projects that you want to protect to a separate folder with its own solution. Secure that folder as above. You can then build it separately and deploy it to an internal nuget repository.
you can then reference that repository from within the Visual Studio package manager and it will be managed as an external dependency. If you update and publish the other solution then the other devs will be notified of updates..
You control access rights to a folder by selecting Advanced->Security from Source Control Explorer. From there, you can turn off security inheritance for the item(s) you need to protect. Then, create a TFS-specific group containing the 'limited users' only and only allow them access to the particular project folder. Alternatively, create a group for the contractors and deny them access.
This is based on VS/TFS 2012.
But my guess is that you will also need to create a specific solution for the contractors that doesn't have the particular project included.
We have installers referencing a wixlib file to get some common functionality. The wixlib is built in another solution then moved to a folder within that solution. When we try to build the installers with a TFS build, we get an error from light.exe:
light.exe: The system cannot find the file '..\..\..\Core\Common\assemblies\v1.0\Common.Wix.wixlib' with type 'Source'.
Our regular projects can reference \assembiles\v1.0, since we have some other common assemblies stored there. How do we get WiX to recognize this location during build?
You are referencing wixlib directly. So as far as I understand the TFS build process, it should be added to TFS project of your solution. TFS project shouldn't be dependent on the output of another non-dependent solution. It is at least bad practice. And in any case you can't guarantee this output would be generated before your project build on server.
As far as I remember, TFS build creates separate folder for each build and gets sources there. So your solutions are no longer on the same folder hierarchy level.
One more point in favor of explicitly copying wixlibs into your installer project: versioning - in this case any bugs made in the common library will not immediately break all projects that reference it. And you can gradually upgrade and test every project. Can you imagine auomatically downloading new version of any 3rd party dll on every build? Any change in that dll will immediately break your application even if changes are not critical to you.
Since the shared component and the active solution are in two separate projects in TFS, the workspace must be setup so that the relative paths for references remain intact. The easiest way to do this is to set your Build Agent Folder structure in Workspace in your TFS Build to have $(SourceDir) represent your root. However, don't change your Source Control Folder - that stays the same.
For example, say you have the following structure:
-TFS
|-SharedComponents
||-MyComponents
|-ProjectArea
||-MyProject
You would want to have the following two items in the build Workspace:
Source Control Folder Build Agent Folder
---------------------------------------------------------------------------------
$/ProjectArea/MyProject $(SourceDir)\ProjectArea\MyProject
$/SharedComponents/MyComponents $(SourceDir)\SharedComponents\MyComponents
This mimics the structure in TFS in your build folder, thus allowing all relative paths to remain intact.
One more note about this configuration: Since you have the shared components in another location, you may want to create a solution folder in MyProject and add the components that you are using to it. This will ensure they get pulled automatically when anyone loads your project from TFS - they won't have to go back and pull down the share components folder separately after discovering a build error.