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.
Related
Environment:
TFS 2018 with source code in TFS Git
developers are using gitflow-like workflow (main, develop and short-lived feature branches)
there is a build definition used for CI (off of develop branch)
... and another one for releases (off of main branch)
as project evolves build definitions get updated (new steps, etc)
What is the best approach that allows reproduction of previous builds (or, at minimum, release builds)? (in case if previously made build was lost in boating accident)
Ideally I need to be able to plug in version (e.g. 8.5.12345.1) somewhere, press OK and eventually receive data identical to that produced by corresponding build in the past.
Your best approach is to switch to YAML builds and releases. That way your pipeline is versioned together with the code.
If you don't do that, you may need to clone your build and releases every time you make breaking changes.
Alternatively, use the version diff view in your pipeline to go back to an older version or use the json to create a new definition using the API.
Upgrading to Azure DevOps Servers 2020 will give you more advanced YAML features not yet available in Team Foundation Server 2018.
Note: for truly reproducible builds, you'll need to also find a way to lock the build tasks themselves, TFS and Azure DevOps will automatically roll forward to the latest minor version of a given build task. While task authors should try to prevent any breaking changes in those minor upgrades there are no guarantees. You can also never rely on any tool installers that use a v2.x notation or a task that relies on latest. Azure DevOps isn't ideally suited for full reproducible builds.
You can pin task versions in YAML now, if I remember correctly, this was added in Azure DevOps 2020.
You can set which minor version gets used by specifying the full version number of a task after the # sign (example: GoTool#0.3.1). You can only use task versions that exist for your organization.
See: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/tasks?view=azure-devops&tabs=yaml#task-versions
The Tasks docs offer special scripts to pin the versions of out-of-the-box tasks as well.
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.
I'm currently using Team Foundation Server 2015 (Update 2) and wanting to use the new build definitions and release management and wondering what the best practice is around creating build definitions when using multiple branches.
We have multiple branches and there will also be multiple solutions in each branch (for this example i'll call them WinApp.sln, WebApp.sln & MobileApp.sln).
Our project branches are something like the following...
Project
Dev
Main *** This is our development branch for new features
Updates
1.2 *** This branch is used for any bug fixes for version 1.2
Main
Releases
1.1
1.2 *** Current release branch that will be deployed to customers
Using the new build definitions in TFS 2015 is it best to create a new build definition for each of the branches or each of the applications in each branch.
For example I create the following build definitions:
AppName.Dev.WinApp
AppName.Dev.WebApp
AppName.Dev.MobileApp
AppName.Updates.1.2.WinApp
AppName.Updates.1.2.WebApp
AppName.Updates.1.2.MobileApp
AppName.Release.1.2.WinApp
AppName.Release.1.2.WebApp
AppName.Release.1.2.MobileApp
And then that would flow through to the release management by having release definitions like the following:
AppName.Dev
AppName.Updates.1.2
AppName.Release.1.2
Each release definition will have artifacts added for each of the 3 solution builds.
Or would it be better to just have 1 build definition for each branch?
Would be interesting to know what other people are doing in similar situations.
Previously with the xaml based builds, we had multiple build deifnitions because whenever we released a new build template, we did not want the older release build definitions impacted, hence we maintained multiple build definitions. We also maintained that for the sake of the version the build gets.
But, with the new vNext builds in place there is no way we can have a previous version of a task available to use once we enhance a task and upload it to the TFS all build definitions start using the latest task and there is no way(other than renaming a task) by which we can select a task of older version. So, I think it would be of no use to maintain multiple build definitions, as the build definitions are going to get updated if a task is updated.
There is a case where we require to maintain a version for a specific release and if the number depends on the builds triggered, in that case we'll have maitain different build definitions becuase our patches cannot have the latest version number.
One more reason to maintain different build definition is to escape from the headache of remembering what tasks were used in a specific release previously.
So all in all I'll go with different build definitions to avoid versioning chaos and to maitain integrity of a release build definition.
When it comes to release,we bind a build definition to a release definition. So, again to have a smooth bug fix and update, different release definition for each build definition has to be present.
We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.
Is there a way in TFS 2012 to set Project (not .csproj projects but TFS projects) build priority?
Currently we have many projects in TFS, one of which is a core project that many other projects reference. If someone checks in changes to both core and another project at once, the core project build doesn't always kick off first (I think they build in alphabetical order). It would be nice to be able to set the core project as the highest priority so that its build always runs first when changes to multiple projects are checked in. Is this possible?
There is no way to set the default build priority for a Build Definition. Since a Build Definition isn't bound to a Team project, but to a collection, there is also no way to configure the Queue to pick up builds from one Team Project before any others.
What you can do is to set a tag on an agent and then assign that tag to the build you want to take precedence. This will exclusively reserve the Build Agent to that specific build definition, causing it to jump in the queue.
Is there a way in TFS 2012 to set Project (not .csproj projects but TFS projects) build priority?
A project in TFS is quite a loose term which does not correspond to a VS project, it's actually used to refer to a product which can contain many branches. The high level project management tools then operate on the TFS "project".
If someone checks in changes to both core and another project at once, the core project build doesn't always kick off first (I think they build in alphabetical order).
Nope, assuming you don't have a custom build then they (the VS projects) don't build in alphabetic order at all, they build in order of dependency. Solutions are built in the order they are returned from the evaluation of the $(SolutionsToBuild) property (this does a wildcard search of the filesystem for .sln files, so maybe that's where your alphabetic observation comes from). Note that dependencies are evaluated on projects within a solution, there is no evaluation of dependencies across solutions.
For the following statements I'm going to assume that you have standard CI style builds gated upon checkin.
If a developer checks in everything at once then the checkin will happen as an atomic unit of work and the build will commence once the checkin is successfully committed. If this is not your experience then I would suggest that you either have funky stuff happening in a custom build, or the developer is checking blocks of work in separately rather than all at once.
Note that this happens per checkin per workspace - if two different developers check stuff in at the same time then whoever checks-in first will trigger the build, and the submission of the second developer will miss the build.