We are new to TFS (2013 Update 4) and are trying to implement a build process. Part of the deployment process involves finding a series of external files (namely .sql files) and copying them to a separate folder for the DBA to deploy.
At this time, and for the foreseeable future, this process cannot change. However, to make things easier, is there a way to have the build definition copy all of the files (from a specific folder tree) that are marked as changed in the associated changeset(s)?
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 are moving to TFS 2018 from 2012 and I'm working on migrating the builds. One of the builds has a few mtbwa:DownloadFiles activities in it but I don't see an equivalent way to do this in the new build system. We have a few utilities in a different branch that are used to build installers. So I need to download those utils before completing the build. How would I do this in the new build system?
If the files are in source control, then you can map the source directly in Get source step.
Then the files will be automatically downloaded to the $(build.sourcesDirectory) by deafult on the agent machine.
After that you can also add a Copy Files task to copy the files to any location as needed.
If the files are not in source control, you can also use the Copy Files task to copy them, but you need to make sure that the service account has the proper permission to access the source folder.
UPDATE:
If the team projects are in same collection, map sources in Get Sources step is also available. You need to manually specify the Server path (Click ... can only navigate to the root path of current team project).
e.g.:
In below screenshot I entered the server path $/2017ScrumProjectFromVS/WpfTest
This also works with the Copy Task, that means you can copy the files directly from another team project which in the same collection.
I have some Libraries added in my TFS 2010 project in a Lib folder.
Each time I check In a dll in the Lib folder, all the build that reference that Lib folder trig automatically (more than 20 Build).
I can use the ***NO_CI*** to prevent that. But I prefer to have something automatic.
Is it possible to have an event handler on TFS to prevent that.
Ex. If the check in is on that folder, do not scan all the CI Build Workspaces to trig the build.
The workspace mapping in the build definitions defines which files/folders are part of that build. You can use cloaked folders to explicitly exclude folders from the workspace.
However, the workspace mapping is used for 2 purposes: to determine which files get downloaded to the build server as part of the build, and to determine which files trigger CI/Rolling/Gated builds.
If you exclude folders from the workspace (e.g. using cloaked folders) it will stop the builds from being triggered but it will also stop those files from being downloaded as part of the build.
If you want to have a build download a certain folder as part of the build but not have builds triggered by check-ins to that folder I don't believe it is possible without customizing the build workflow.
When you include a folder in a workspace, you're saying that changes to that folder affect your project. This is the same for changes to shared source code as for shared binary. If it changes, then the affected applications should be built (and their automated tests should be run) so taht it can be determined whether the changed files have broken anything.
Make sure each library in the lib folder has it's own folder + version folders beneath
lib
EntityFramework
4.1
EntityFramework.dll
4.2
EntityFramework.dll
Then modify your builds to only reference specific folders for the library a project references.
It takes a lot of work to setup builds, but will ensure the build only triggers when a file needed for the build is changed.
Alternatively a copy of each library in the projects directory, which you could manage with a package manager like NuGet or OpenWrap
I want to use the same targets defined in an external file in multiple build definitions. This external target file should be stored on the source control.
The bootstrap phase explained in TFSBuild.proj and Importing External Targets does not seem to allow downloading the same file for multiple build definition as the build file is always named TFSBuild.proj and consequently sits in a separate folder for each build definition.
The question was somewhat aked in a comment of the previouly mentionned thread but it seems motre appropriate to create a new thread.
Quoting that comment by David Keaveny:
Is it possible to get TFS to download
from other folder paths during
bootstrap? I have a Common.targets
file that contains all the custom
tasks that my TFSBuild.proj should be
executing, but given that I several
build definitions (one folder per
definition), it sits in a separate
folder at the same level as the build
definitions. Without it, of course,
the builds fail immediately. – David
Keaveny Aug 17 '10 at 23:58
I'm not sure if there is an easy way to do this. You could have a master copy of the targets file, and branch that in to each of your build definition folders. When you update the targets file you'd need to remember to merge it to all of the folders. You could probably write a script that automates the merging, the script should be able to work out what the branching relationships are using tf branches and then iterate around them and call tf merge then tf checkin. This feels like a lot of work though.
You could just install the target on your build server(s). We have a number of custom targets that we use and we manage them as if they were a product, they have their own area for source control and are versioned independently of the software they are used to build. We package them using wix and once they have been tested they are installed on all of the build machines. This seems to work for us and it means we can control the rollout of new targets files, and the targets install is just part of a build server basline build.
I'd be very interested if someone has an easier way of managing this though.
I have a build definition setup with a drop location. The binaries are moved into this location, but under a new directory (named as build number) every time. Is there a way to have the same location over written everytime. we have some batch files that copy the binaries out to multiple servers that will be accessed by the end users. We need the location to remain constant so that the batch files can work correctly.
If this is not possible, is there a way for the batch files to pick the latest location which contains our exe (sometimes, the folder is created even when the build failed).
Having an unique name of the drop location, is something you cannot (and don't want to) change. To solve your issue, you can either
1) start the batch files with arguments (so the directory is %1) where you specify the name of the directory
2) Add a task in the build to copy all the files to a file share. If you are using TFS 2008, you can follow the steps provided at http://blogs.msdn.com/b/msbuild/archive/2005/11/07/490068.aspx to copy the files.
If you are using TFS 2005/2008, then TFS Deployer. It flat rocks when doing deployments.
TFS 2010 has a new build deployment model that is pretty good.