Have a small ASP.Net Web Application that is setup to build and release via TFS 2017 (Update 2) Continuous Integration and Deployment. It all seems to work well, I check in a code change and the change appears on our test server as expected.
However, when I review the build/release logs it's deploying all the files in my web application project as if they're new files. This includes images and the like that haven't changed.
How can I, a) restrict it to only deploy changed files, or b) only deploy the necessary web application files?
Below are the Build and Release Definitions in TFS, along with the Build and Release logs.
2018-03-13T21:46:56.8010920Z ##[section]Starting: Build
2018-03-13T21:46:56.8167174Z Current agent version: '2.117.2'
2018-03-13T21:46:57.5354799Z ##[section]Starting: Initialize Job
...
TFS 2017 Build Log
2018-03-13T07:49:31.8449259Z ##[section]Starting: Release
2018-03-13T07:49:31.8605444Z Current agent version: '2.117.2'
2018-03-13T07:49:32.6262832Z ##[section]Starting: Initialize Job
...
TFS 2017 Release Log
Cheers
Phil
Using the Copy Files task, there is no default match pattern filters could only copy changed files.
For a),you could try to use a powershell script in release definition to achieve your requirement.
which deletes all files (recursive) which have timestamp that is <
(Now - x min), and all empty directories after that. On this way
Artifact directory contains of ONLY CHANGED files (entire file
structure (of changed files) is kept). Now Release will deliver only
these files to destination.
More detail info please refer this similar question: TFS 2017 - how build/deliver only changed files?
For b), you could try to use the Build and Deployment template and by default in the MSBuild Arguments the parameter is: /p:OutDir="$(build.binariesdirectory)\\"
Have a look at this question: Build and Deploy a Web Application with TFS 2017 using Web Deploy Package
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.
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).
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.
I have a TFS Build Definition that builds/deploys a web project to our internal IIS server. That works fine. However, I would also like to build/deploy a WinForms app (.exe) to the same web site.
I did add the WinForms solution to the Build Definition. TFS builds the .exe and copies it to the drops folder. But it's not in the _PublishedWebsites folder.
I've been manually copying the file over to the web site. Is there a way to automate this?
Thanks in advance!
In XAML build, you can check in your script, and specify a post-build script path in your XAML build definition. This script gathers some of the typical binary types from the typical locations and copies them to the folder from which TFBuild copies and drops to your staging location. Check more information about Run a script in your XAML build process at website: https://msdn.microsoft.com/library/dn376353%28v=vs.120%29.aspx
If you upgrade to TFS 2015, in the new build system, you can simply add a PublishBuildArtifacts task in your build definition. About how to use this task, check: https://www.visualstudio.com/en-us/docs/build/steps/utility/publish-build-artifacts
When I started writing this question, my problem was that after a successful VSTS Build, I wasn't able to see the files relating to my web application project for release. Only the files from certain other projects in the solution were present. However, I just came across this question, which has helped.
I can now see the compiled .dll files for my web application project, after altering the configuration of the Content setting in the Build - that is, the contents of the Bin folder under that project. But I can't see anywhere the other files I need to copy the built web application to my server - the views, the scripts, the css, etc.
I'm finding the power and flexibility of VSTS's Build and Release functionality very confusing as it's complete overkill for our requirements. Up until now, I've just right-clicked on the web app project in Visual Studio selected Publish and used the File System publish method. Easy. Now that I want to automate the building and deploying of the application, it's many times more complicated!
So, can anybody tell me how I can get the solution to build in VSTS in such a way that I can then use a Copy Files task in the Release Definition to copy the files to our web server (the server isn't visible to the Internet so I'm using a locally-hosted Agent)?
In vNext build, to publish your build artifacts with the Copy files or Publish build artifacts steps. Try to use the local path on the agent where any artifacts are copied to before being pushed to their destination. For example：
Add /p:DeployOnBuild=true
/p:OutDir="$(build.artifactstagingdirectory)\" arguments in Visual
Studio Build step；
Change "Path to Publish" of Publish Build Artifacts task to
$(build.artifactstagingdirectory)\_PublishedWebsites\ProjectName:
Details please check the screenshot of build step with this question: How do I get the the expected output from a TFS 2015 build (to match my XAML build)?
Base on your comments, you have published the web app from Visual Studio. Usually, this action will generate a publish profile under Project/Properties/PublishProfiles folder. The settings you used to publish the web app is stored in the profile. So you just need to make sure this publish profile is checked into source control. And then in the TFS build, add following MSBuild arguments:
/p:DeployOnBuild=true /p:PublishProfile="publishprofile.pubxml"