I want to use existing TFS build scripts but move my code to the TFS cloud.
Can this be done?
Is it as simple as changing the "Source Control Folder" in the Build Definition? (I doubt it).
We have a local build machine which I want to use as it has custom installations required for the build to succeed.
You can. If you install and configure a TF Build Controller locally you can connect it to VSO. Add some agents and you can build hapily locally with all you code safe and secure in the cloud.
Related
Is there any similar plugin like this
https://wiki.jenkins.io/display/JENKINS/Config+File+Provider+Plugin
in TFS Build & Release
I want to provide configuration.json file which is not included in git source.
Unfortunately, there is no such extension in TFS/VSTS Build & Release.
According to your tag tfs2013, seems you are working with XAML build.
Just like you need a workspace on your dev machine to develop your app, you must specify the workspace that the build agent uses to build and test your app. Then we get/pull source files from TFS server side. It's not able to achieve below similar features in TFS UI:
Adds the ability to provide configuration files (i.e., settings.xml
for maven, XML, groovy, custom files, etc.) loaded through the Jenkins
UI which will be copied to the job's workspace.
As a workaround, you could try to put configuration.json files in a ftp server instead of git source and then use a PowerShell solution to down the files in build agent workspace. If create a PowerShell to over FTP you can have it called by the build template(customize workflow).
The Challenge
We have an on-prem application (RM) that cannot communicate with VSO
Our code must stay in VSO
We need to give RM access to Build Definitions that are tied to our VSO source
Attempted Solution
Install TFS locally to host build definitions only
Have those build definitions pull from VSO
Problem
It looks like we can't use a VSO project directory in the Source Control Folder mapping
Is there a workaround?
Your best bet is to start migrating to the new Release Management service in VSTS, since the existing Release Management Server application is rapidly being deprecated. There are tools available to help ease the pain of migration.
You could also use RM Server in non-integrated mode -- nothing would be tied to build definitions, and you'd have to specify the path to the build drop manually when queuing the release. It can still be automated via the ReleaseManagementBuild.exe utility in the Release Management client folder, it would just take a bit more effort to build it out.
You could also build a custom build process template to pull the code from VSTS and build it, but again, that's investing a lot of effort in RM server.
[Full disclosure: I am a contributor to the migration tool linked above]
I have created a lightly customized TFS build process template and also appropriate TFS build definition. It builds fine on the TFS build server.
Is there any way I can allow developers to reuse the same build process XAML and definition to do full builds on their local machines? Maybe there is some utility which can be run with TFS build process XAML files?
I really would like to avoid maintaining a separate copy of the build script for full local rebuilds.
The build templates can only be run by the TFS build service. Without installing that on each developers machine, that might not be the best idea.
An alternative is to setup a share on the developments machine and grant access to the TFS Build account (the one that TFSBuildServiceHost.exe runs on the server as). Then the developer can Queue a build and get the Server to Drop the files onto their machine.
The downside to this is you need a lot of builds to be run on the Agents.
My Question: How can I run a deployment script from the TFS 2010 build template on a remote system that has only a MSTest agent running?
I know this can be done by activating the Deployment section in the test settings configuration file, but this is not flexible enough. At night a build runs. When the build is successful, a deployment script is placed at a drop location. The drop location is date, project and build definition specific. These parameters are available in the TFS build template we use.
I do not have Lab Management available, just a physical server. I would rather not spoil the physical server with an additional build agent to only do the deployment. The MSTest agent is apparently capable of running deployment scripts, but how do I use that functionality from the TFS build workflow. For example, can I use the RunDeploymentScript activity without having Lab Management?
PSExec is a great tool for running scripts on remote computers. I use this in Team Deploy that allows you to install MSIs on remote computers from Team Build. You can also run PowerShell on remote computers but it is a little more complicated to set up. Another option is to use MSDeploy. There is a command option that you can run any command on a remote computer. I usually use an InvokeProcess activity to call a PowerShell script on the build server. From the PowerShell script I have called MSDeploy to run a remote PowerShell script on a target server. It sounds bad but worked good.
You can't run the RunDeploymentScript on the target machine. You can use a modified template to deploy to a physical environemnt. Here is a good post on doing this.. The options I mentioned above do not need any agent on it. You can use the ExecuteRemoteTestRun lab management activity without Lab Management to run the MTM Tests with the Test Agent with a Test Controller that is registered to the project collection (Test Manager).
Let me know if you have any questions on any of these options.
Can I have TeamCity Build server check out code to another server or machine, in addition to itself? What I am asking is can I run build configurations that automatically checks out, udpates source code from TFS into multiple servers. Each Build configuration handling a different server?
I didnt try it myself, but waht you could try is to set the "Checkout directory" in the "Version Control settings" to an network dir. for example
\10.30.9.1\d$\project\
or "map" a network drive on the TeamCity Build server