We moved to TFS 2017 (from TFS 2013 XAML builds) and the new build & release, but we mainly do windows apps. Q&A and some people are complaining about some functionality missing, for example, there is no way to specify to Keep All builds. I find it extremely strange this would not be possible. How can we do this?
I also looked into the Release part of it, but I don't see anything for Windows app. Besides, it seems that cannot keep releases indefinitely either...?
XAML and vNext are totally two different build system. The behavior is different for the new build system, there is no keep all option. You definitely couldn't use the old retention policy on XAML build for vNext.
If I mark a build or a release to be retained indefinitely, does the retention policy still apply?
No. Neither the definition's retention policy nor the maximum limits
set by the administrator are applied when you mark an individual build
or release to be retained indefinitely. It will remain until you stop
retaining it indefinitely.
More detail about the policy please refer this tutorial: Build and release retention policies
Related
I'm housekeeping the TFS Server and have 40,000 shelvesets of which 6,500 are for the Build Service Accounts.
I assume i can simple remove these as i don't think the builds will refer to old shelvesets.
I exported all current shelvesets.
Can someone confirm if we can just delete all of these? Or will we run into trouble if we want to run an old build
We are running TFS 2017.2
I don’t see any reason to keep them. Since commits should be occurring therefore giving you code history and reproducible builds.
If you delete a shelve set you cannot retrieve it latter for any old builds.
Shelve sets are not the same as code commits
Reference the MSDN documentation which applies to TFS 2017 and shelve sets for use cases.
the purpose is not to be a version history of code changes or
associate code with builds.Thats what commits are used for.
Shelve sets are temporary. However, no rule stopping you from keeping forever. Unlikely any value would be gained from so many
though.
there is not a need to reproduce a build with a shelf set that is older then your code release cycle because commits our occurring making the shelve sets moot.
#NOTE: I do not know why you would have the build agent doing code shelve sets. I would look at your build definition and take out anything automatically creating shelve sets.
Its always advised to find the details of shelveset unless you know its old enough to delete. You must be a shelveset owner, or your Administer shelved changes permission must be set to Allow as explained here. Shelveset commands to delete/find/list/... are listed here
TFS Sidekicks tool provides a dedicated UI for a number of clean-up actions, including old shelvesets till TFS2015. Not sure about its working in 2017
In TFS 2010/2015, the Xaml builds can be configured to only ever keep the last x builds (e.g. keep the last 5 builds).
However, the new style builds in 2015 change how this works, to keep builds for x number of days, and keep a minimum of y.
This might work well when dealing with small projects, but the output of our build is >5GB a time.
Is there a way to use the old retention policy, or alternatively have TFS manually delete the old builds as new ones are created?
XAML and vNext are totally two different build system. You definitely couldn't use the old retention policy on XAML build for vNext.
And there is also not any option to make TFS delete the old builds as new ones are created. Retention policies is the only way used to configure how long builds and releases are to be retained by the system for now.
As a workaround, you could use TFS API to do this. You could run a utility to clean the build artifact drop location for builds. Here is a sample from skundu's answer in this question: TFS 2015 - Delete Build Artifacts for your reference.
We are using Tfs2015.Update2.1 [14.95.25229.0].
We have vNext build definitions with a retention policy of 21 days. The maximum retention policy is set to 90 days. Yet we have builds that are over 100+ days old that have not been deleted (they still show up in the list of completed builds). It appears that the retention policy is not being applied at all. What can I do to verify that the retention policy cleanup process is actually running?
If you specify build retention policies, retention policies will delete the items below:
The build record
Logs
Published artifacts
Automated test results
Published artifacts
Published symbols
First please make sure you have set Delete build record = true.
Also note completed builds may be exempted from their associated retention policy in the view of builds by selecting Retain Indefinitely from their context menu. The Release Manager will set the builds as //kmm, please refer to the information in this User Voice.
Please view this build definition’s builds in Build Explorer window, check if some builds be set as Retain Indefinitely in there.
You can also double check the older build recoder to see whether has been deleted. The deleted build record should be the same as below picture:
There was an issue with the background job responsible for retention. Team Foundation 2017 Update 3.1 includes the fix.
I'm trying to understand the process for vNext Builds and Release Management as far as identifying what work items are included.
If I have a build set up on every check-in (each time a work is completed), then each of those Builds will have one work item linked. I can then trigger a Release deployment of those Builds to a QA environment, but then each Release only identifies that one item as being linked - not any others that have been included since our last production release. Since there could be multiple Release Deploys to QA prior to a Deploy to Production, it's confusing trying to filter through all the Releases.
I'm trying to find a good way to see all work items included in Builds/Releases since the last production deployment. Am I misunderstanding how to use this? Should I be using the same Release and just changing the targeted Build each time? It seems like it bases "included work items" off the checked in work-items in between the last build and the current one.
In Release Management, It compares current release with the last release to show the work items included in current release. You only see one work item is because that you have configured TFS to build every check-in and trigger the release for every build. If you trigger a release after two builds, you will see two work items included in the two builds. The latest version of Visual Studio Team Service has support selecting a release version to compare with current version to list the included changes and work items, but this hasn't been implemented into On-premise TFS yet.
So for now, you can create another release definition and link it to the same build to deploy the build to production manually. Then you can track the included work items from this release definition. Or you can create an app/powershell script to read the build version in the production release and then get the included the work items via Rest API.
This question is a bit round about, but I'll get to that in a minute. When someone changes the build's quality in TFS (we're on 2005) what exactly happens? Does this affect changesets or workitems, notifications??
Now the reason I ask: I want to be able to generate a changeset list between builds. As such selecting a build on Jan 1 and comparing it to a build on March 29, I want all the changesets between those builds. Perhaps there is another way to do this but I do think the build is the starting point.
Out of the box, it's just meta data about the build. The intent being you can use it in your development process to indicate when a build has progressed through certain quality gates.
It should be noted that the open source TFSDeployer project relies on the build quality as a trigger mechanism to run deployments scripts.
In TFS 2012, you can set a quality threshold on builds to say which ones can be used by Microsoft Test Manager for testing.
In MTM, in the Testing Center, under the Plan tab, under the Properties subtab, there is a section called Builds. You set a quality threshold with "Filter for builds" and then any builds that conform to the filter will show up when you click Modify under the "Build in use" line.
On a side note, I have found some interesting info here about automatically updating build quality through XAML.
I think it is just a notes field. I see it show up on some reports, but nothing else of value.