I would like to access some files from source control (tfvc) while release management.
The sources I found are either build (type "Build") and the whole source tree (type "Team Foundation Version Control").
The type "Team Foundation Version Control" seems to match, but it is not allowed to select sub folder, e.g. "$/MyApp/branches/V2/scripts".
Do I need to create an artifact for the script files?
Instead of linking in a separate repository, I'd strongly recommend either publishing them as a build artifact (as the other answer mentions) or publishing them as a versioned NuGet package.
The reason is because everything that goes into a deployment should be versioned together. Scripts that are changing out of sync with everything else can cause abrupt deployment failures for unknown reasons. Let's say you linked those scripts in as an artifact and started a deployment along your pipeline from Dev -> Production. Dev deployment is fine. QA deployment is fine. Staging deployment is fine. Production deployment... fails? Because of an error in the scripts?
Whoops, someone committed a change to those scripts and introduced a bug. But the scripts weren't versioned, so you had no way of guaranteeing that the scripts being used in prior stages were the same as the scripts being used in your production stage.
You can save your source code as a artifact in your build process. Use the "Publish Artifact" step to publish your source code in Tfs or on a unc path. After that release management downloads your artifacts as the first step.
Related
When we do a TFS Build, can we alter the build output so that the output is limited to only the changes so that deployment payload is reduced ? Example:
When I build a solution, I should only get the changed dlls not all (which includes Microsoft and other 3rd party dlls which are never changed.
Configure CI solution in TFS 2015, and unchecked clean options, Since TFS 2015/2017 always delivered all files - changed and unchanged, but I need only changed. This trick doesn't solve the issue:
Build (TFS Build), only what is changed
Followed a couple of other sources.
IncrementalBuild property in TFSBuild project
Incremental builds in TFS
Applied these tricks to update project with few settings (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) under PropertyGroup definition to the end of the TFSBuild.proj file.
But the issue still persists, we are unable to produce only changed binaries in build folder, there is always all files.
Please help me to achieve the desired build output.
Incremental builds only rebuild assemblies that don't depend on changed files. But it does copy all of the project output (subsequent projects that depend on it may depend on these assemblies and files being there).
This causes incremental builds to be much faster, but it doesn't "only deliver the changed files". It always delivers all files whether they are changed or unchanged. On top of this, you could have multiple agents and each agent can have multiple working folders, the incremental build could use any of these as base for the incremental builds, there is no guarantee that the changed files are between your previous build and the current one.
You'll have to implement this feature yourself, it has never been part of MsBuild or TFS Build. It would involve querying TFS for the last drop folder and performing a compare after running an incremental build. Then copying just the changed files and a log of deleted files.
PS: The TFSBuild.proj type builds are very deprecated. They have been surpassed by the XAML builds in TFS 2010 and have been considered "legacy" since then. They have subsequently been surpassed by the new VSTS/Azure DevOps build system which has deprecated the XAML builds. Most of the properties that interact with Source Control are ignored when a TFSBuild.proj project is executed in the Legacy XAML workflow. Instead, the XAML agent takes care of fetching the sources prior to passing control to MsBuild. These new VSTS/Azure Devops build tasks are now also getting YAML support for Git based source control repositories.
When we do a TFS Build, can we alter the build output so that the output is limited to only the changes so that deployment payload is reduced ? Example:
When I build a solution, I should only get the changed dlls not all (which includes Microsoft and other 3rd party dlls which are never changed.
Configure CI solution in TFS 2015, and unchecked clean options, Since TFS 2015/2017 always delivered all files - changed and unchanged, but I need only changed. This trick doesn't solve the issue:
Build (TFS Build), only what is changed
Followed a couple of other sources.
IncrementalBuild property in TFSBuild project
Incremental builds in TFS
Applied these tricks to update project with few settings (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) under PropertyGroup definition to the end of the TFSBuild.proj file.
But the issue still persists, we are unable to produce only changed binaries in build folder, there is always all files.
Please help me to achieve the desired build output.
Incremental builds only rebuild assemblies that don't depend on changed files. But it does copy all of the project output (subsequent projects that depend on it may depend on these assemblies and files being there).
This causes incremental builds to be much faster, but it doesn't "only deliver the changed files". It always delivers all files whether they are changed or unchanged. On top of this, you could have multiple agents and each agent can have multiple working folders, the incremental build could use any of these as base for the incremental builds, there is no guarantee that the changed files are between your previous build and the current one.
You'll have to implement this feature yourself, it has never been part of MsBuild or TFS Build. It would involve querying TFS for the last drop folder and performing a compare after running an incremental build. Then copying just the changed files and a log of deleted files.
PS: The TFSBuild.proj type builds are very deprecated. They have been surpassed by the XAML builds in TFS 2010 and have been considered "legacy" since then. They have subsequently been surpassed by the new VSTS/Azure DevOps build system which has deprecated the XAML builds. Most of the properties that interact with Source Control are ignored when a TFSBuild.proj project is executed in the Legacy XAML workflow. Instead, the XAML agent takes care of fetching the sources prior to passing control to MsBuild. These new VSTS/Azure Devops build tasks are now also getting YAML support for Git based source control repositories.
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.
I've just setup a TFS (2012) server and now I'm trying to build the complete code (written in .NET 4.0 in VS 2010) via the TFS Build server. But in my solutions I have also a WCF RIA project which contains linked files because they are used somewhere else also and there is no possibility to add a reference to a general .NET binary in WCF/Silverlight.
Everything builds without any problem on my development machine but when I check it all in, create a standard build definition and run that build definition I get the following problem. The linked files have usings (UsingNamespace for example) to other projects that are also build by us and build before the WCF/Silverlight but the following error pops up while building through TFS Build server:
The type or namespace 'UsingNamespace' could not be found (are you
missing a using directive or an assembly reference?)'
Is there any solution for this problem that I looked over?
EDIT 1
Just tried to set the Copy to Output Directory propertie of the linked files to Copy Always but this still gives me the same error as I was expecting. The problem is that the linked file is placed somewhere that it can use the usings but the WCF RIA service cannot access/find that using.
EDIT 2
Just tried out my local test TFS where I can do what I want and there I made a build definition with just the solutions needed to make that the project with the linked files builds. This worked without any problem. Then I tried the same on our TFS server with a new build definition that has the same solutions as on my test TFS and here it did not work. The only difference that I know for sure is that my test TFS is TFS 2012 Update 1 and that my production TFS does not have the update 1 yet. I'll try to install it next week.
EDIT 3
I've just updated our production TFS to Update 1 but it is still not working with my temporary build definition which only contains the projects that are needed to build the silverlight application with the linked files. The 2 workspaces are the same on both server and the projects to build are also the same.
You need to specify the workspace information in the Build Definition for the build to use. The workspaces are what the build process copies from source control to the build server. If you don't have everything in the build server's workspace, it can't build properly.
The Source Control Folder in the workspace tab is the location of the files you need from TFS. The Build Agent Folder is a relative path from the build server's pre-defined base location. You'll usually use $(SourceDir)\Folder to specify the "Folder" that your build process needs.
This sounds like an $(Outdir) problem. A build definition in TFS automatically overrides the Bin folder. All Binaries are redirected to the bin folder upon compile. Sounds to me that you are using a mixture of project references and file references. The file references are probably what is causing your build failures.
Example if you compile in the same build the following solutions
Solution1.sln (TFS Build Pass)
project1.csproj
project2.csproj (references project 1)
Solution2.sln (TFS Build Failure)
project3.csproj (references binary output of project 1)
Expectations from TFS out of the box without customizing your workflow is that this simple build will fail. The reason is that in your development box all projects produce output to one destination while in a tfs build your projects will build to $(Outdir).
Some Things to try
Simple (best practice in my view)
Create 1 solution and use project references instead of file references.
Complex
Build using MSBuild project files
Modify your windows workflow to not override the $(Outdir)
Copy the binaries after a build is complete.
Best practice on Automating Builds
Build from command line
Build from cmd a NON vs2010 command line.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe FullpathtoSolutionFile.sln
Cheers!
Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.
I am attempting to use CI on a Branch of one of my TFS projects. MSBuild only fails when I try to use a Branch. I point the same Build at the "trunk" project it works fine.
The error I receive from the build log:
Task "Label"
Label TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6763"
Name="Test_SF_20090619.1"
Scope="$/MyProject" Recursive=True
Comments="Label created by Team Build"
Version="BuildServer3D143_66"
Child="Replace" Files="$/" C:\Program
Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(812,5,812,5):
error : No matching items found in $/
in your workspace.
Done executing task "Label" -- FAILED.
Done building target "CoreLabel" in project
"TFSBuild.proj" -- FAILED.
I believe this error is being caused by a lack of source files getting copied to the Build server.
Get task excerpt from build log:
Task "Get"
Get TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6768"
Force=True Overwrite=False
PopulateOutput=False Preview=False
Recursive=True Version="C204806"
Workspace="BuildServer3D143_66"
Done executing task "Get".
This is a full build. There should be about a thousand files listed in the GET.
General Information
TFS 2008
Visual Studio 2008
Established build server (been
running builds for the last year)
Project being branched is a ASP.NET
web stie (2.0 Framework).
Full Build Params
/p:SkipClean=false
/p:SkipInitializeWorkspace=false
/p:ForceGet=true
/p:IncrementalBuild=false
/p:IncrementalGet=false
note: I know IncrementalBuild is redundent but I just wanted to be sure.
Questions:
Are there restrictions on builds off a branch?
Any idea why MSBuild fails to pull files from the branch workspace?
If it's for CI then you're most likely doing an Incremental Get. TFS will only bother to get files it thinks have changed since its last get - e.g. if you delete any files from your server, it will still think you have those files so it won't get them again. In this case you'll need to run the build once with the incremental properties turned off so that it forces a full get of the source. You can do this by overriding the properties in the MSBuild command line box in the Queue Build dialog with:
/p:IncrementalGet=false;ForceGet=true
Another possibility that springs to mind is that the Label task is confused by your branch. It may be that your workspace is set up incorrectly, so check that you're mapping in everything it needs.
I had two issues in this case.
First, the branch security did not give rights to the build service account. I had restricted the branch to our team's Tech Leads and Release Engineers. The build service account needed access as well. What tipped me of was while searching the internet I stumbled upon a posting by someone who had made the same mistake.
The second issue was a little more involved. While cleaning up my build project file, I removed the following section.
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../_stage/MyProject/MySolution.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
Which worked fine on projects I had already built at least once, but if this was a new build, that had not copied source files to the build server, then there would be no files and the build would fail.
Some of you may wonder if my other builds were working either, after all wouldn’t they have old build files. Yes, but I had targets defined that did all the work I actually cared about. So the SolutionToBuild is a little frivalous.