I am trying to deploy a sample project with tfs release management vNext. I tried a lot of things (for example: VS RM – vNext Template for On-Premise Target Server in Un-trusted Domain - although I am in a trusted domain) but am now totally lost. My vNext deployment tells me:
ROBOCOPY - ERROR 3 (0x00000003) Accessing Source Directory
\rmServer\ReleaseManagementShare\15b27b05-d176-492d-b534-268af1845a36\2\ComponentName\
The system cannot find the path specified.
And this is true. The folder with the id does not exist.
Concrete questions:
Who is generating the id 15...36?
Who is creating this folder?
Why does it not exist and how can I change that? :)
In the tfs frontend build definition - what is the correct value for 'Artifact Type' and 'Artifact Name'?
Can somebody help out?
The ReleaseManagementShare folder is generally created by the installer when you set up the RM server -- or at least I recently observed that behavior in RM 2015 Update 1, I'm not sure if older versions did that. If it doesn't exist, you can create it yourself. Make sure your RM Server service account has read/write access to it. This folder typically isn't used.
The ReleaseManagementShare folder is only used if you're using a XAML build and have the build output set to go to Server instead of a file share. It may be used for the new build system as well when you choose to store your artifacts on the server, but I haven't tested that scenario. If you push your binaries to a file share, this folder is completely irrelevant. See this for more details:
https://blogs.msdn.microsoft.com/visualstudioalm/2014/11/11/whats-new-in-release-management-for-vs-2013-update-4/
Basically, there are two potential UNC shares involved:
One is for the build server. It puts binaries there, and the target servers reach out to that location to grab them.
The other is this ReleaseManagementShare. It comes into play when you don't have the share outlined in #1, and instead are storing your binaries in TFS. The targets servers still need to get the binaries somehow, so the release management server will "stage" them in the ReleaseManagementShare so the target machines can grab them via the same mechanism they would use to grab them from the build artifact share.
The ID is just a random GUID.
I'm assuming you're using the new build system since you're asking about artifacts. For the Artifact Type, I know for a fact that File Share works. I'm not 100% certain that Server works, however.
The artifact name can be anything you want, but it's important to note that the component name that you define in RM server must match the artifact name, otherwise it will fail to find the binaries.
Related
I am new to the world of scripting with TFS2015. I created a script that builds all of the projects within my solution (it is a rather large solution) and puts it out in a shared folder (where each project has its own subfolder).
I would like to create a separate script for each project that simply copies the bin folder from the shared and pastes it out on my Test environment. I rarely need to deploy everything, so the idea is one build...multiple deploys.
However, when I run my deploy script using the Copy Files step it is doing another build. Although it copies the files that I expect, it is after a full build that creates the folder structure for the build.
Am I able to make the Copy Files step NOT do a Build?
Here is the steps that my script is curently doing:
As you can see, there is only one step (Copy Files) but it still does the Get sources and copies everything into a new folder on the build box like so (where the number keeps incrementing up with each run of the script):
I just want to copy the files from the Source to the Target and not do a build or Get Sources.
It looks like you're still on TFS 2015 RTM or Update 1. Which is already pretty old technology if you compare it to the lifetime of the new build system which was introduced with this version.
TFS 2015 update 2 has introduced a similar system to the Build pipelines to orchestrate Releases. This doesn't require you to map any workspaces or git repositories and can act on the artefacts of your builds or simply on the contents of file shares.
It makes sense that a Build has to build something and in order to build something, it has to get the things to build. If you're actually not building something, then you're probably deploying or releasing or packaging something else. Hence the distinction between Build and Release pipelines.
TFS 2017+ has an option to disable the syncing of sources. Primarily to allow people to get the sources themselves in creative ways (e.g. a custom powershell script that invokes git.exe).
My primary advice would be to upgrade to TFS 2018 update 3 or at least TFS 2017 update 3.1, worst case TFS 2015 update 4.1. The fact that versions older than update 2015.4.1 have a known XSS scripting security bug may be reason enough to convince your organisation to perform this update.
Barring that option you're left with one solution:
Link your build definition either to a git repository with only a single commit (If I remember correctly the 2015 agent still crashes when syncing an empty Git repo) or link it to a TFVC repository and set the workspace settings to cloak everything. This essentially causes the build to sync an empty folder, which it can cache, before calling your powershell script.
We have a customized lab build. We are using the latest build from a specific build definition.
Our testing agent is on another network with shared drop folder, and we need to copy files to this folder before running the tests.
The latest folder is defined in the staging section of the build definition (under Build Defaults). How can I get it in the xaml?
I tried "BuildDetail.DropLocation", but gets nothing (prints an empty string).
We are using VS2012, the server is TFS 2013.
Thanks,
Annat.
Update: Found the solution in my case. Just had to use "BuildDetail.DropLocationRoot".
I wrote some note on the subject on a post, which can give you some ideas on managing drop folders and avoiding copies.
Answering your question, the simplest way is to use the TF_BUILD_DROPLOCATION environment variable in a script.
I am not a developer nor am I the Application Lifecycle Manager. I pull the latest builds from TFS Build Server along with the latest code and I import them in AppScan source for analysis (security tool). Against each security findings there is a class name within which the findings were found along with the directory where the class is located.
Builds are created automatically during a certain time of the day. As mentioned earlier the directory names change every time after a new build and a new number (highlighted below) is introduced. It is not sequential, does anyone know of TFS build server assigns these numbers.
C:\Builds**12**\Development
C:\Builds**14**\Development
C:\Builds**13**\Development
C:\Builds**15**\Development
TFS will create folders based on the following.
DriveLetter\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
so if you have 1 controller with 4 agents on a clean install you would get
Drive:\Builds\1\$(BuildDefinitionPath)
Drive:\Builds\2\$(BuildDefinitionPath)
Drive:\Builds\3\$(BuildDefinitionPath)
Drive:\Builds\4\$(BuildDefinitionPath)
Your Build definition is the name of the build definition and then each subsequent build is stored underneath, with each individual build getting its own folder.
these settings are available on the Build Agent properties screen.
These are transient files and you cant rely on them being there. They are only used as part of the build. You would be better doing a "Get" from TFS at the appropriate Changeset number for the build and using the binaries from the drop folder.
I really don't understand the meaning of tfs build although MSDN provides many definitions.
For example, I have an asp.net project. If I passed the local build on my local machine and I checked in the code. Everything is fine.
I used to copy(publish) the code to the server, that's it.
Why we need tfs build? What is different between tfs build and local build. You might to say, there are build history that can be reverted to an old one. But I think that since code was versioned, we can checked it out and rebuild in the local machine and republish the project to the server.
When I was using TFS, I could run local builds on my local machine. And then when checking in code, TFS would automatically perform a build on the build server (this is specified via a build definition). In that case, the build server was located on the machine which housed the master copy of the TFS source repository.
It's not enough for each developer to build locally as they may not have the latest code. I think the point of a TFS build is that it will run a build on the build server which has all the latest code. I think the idea is that if the build is successful on the build server, then it's deemed safe to check in the code.
That's how I understood it anyway. It's useful if there are multiple developers working on a project. If there is only one developer on one machine, a separate build may not be necessary.
Did that answer your question or did I misunderstand?
The answer of CiaranG is indeed one way to look at it.
Also the TF Build server has the possibility to build your code with signed 3rd party DLL's and put everything in a place as it is every time a new version of your software. This can be then useful for testers that need to test your software and don't need development tools.
Besides CiaranG's description of the Continuous Integration benefits, there is also the security and cleanliness. Allowing production code to be built off of developer machines where there is a chance for virus/malware may be present and the configuration is not known/documented is just poor policy. By building it off a protected server, from which no surfing is ever done, you are ensuring a safe, clean, reproducible environment which adds professionalism to your code deployments. TFS also adds in reporting build metrics over time, accountability, and archiving.
I've got a simple ASP.NET MVC website. It has Debug, Testing and Release configuration modes.
We're using TFS as our source control and bug tracking, etc. Nice.
Now, we're about to embark on using Team Builds to automate some Continuous Intergration. The thing is, we're not sure how to make it so that if we want to make a DEBUG build, or a RELEASE build, it also drops the correct web.config file into the destination directory. Also, we have certain sections of the web.config file extracted to seperate files (eg. the connection string section or the machine key section, etc). Can the correct environment files be dropped correctly into the destination directory.
You could do a pre-build step
Say you have checked in
/Debug.Web.Config
/Release.Web.Config
You could write a pre-build step to check the build type and copy the proper .config file to
/Web.Config
Something like
cp $(ConfigurationName).Web.Config $(TargetDir)
On a side note, ASP.net 4.0 will have support for multiple Web.Configs
http://weblogs.asp.net/gunnarpeipman/archive/2009/06/03/visual-studio-2010-multiple-web-config-versions.aspx
Incidentally, using either a pre-build or post-build step will not work under Team Foundation Server. It automatically configures security on the build directory to prevent any changes being made to configuration files during the build process, whether as pre-build events or as post-build events. The only result of using cp is to return an "Access denied" error.
Look into config transforms. http://msdn.microsoft.com/en-us/library/dd465326.aspx