Technologies:
Proget – Nuget Package management server
TFS – On premise 2017 Update 1
Issue:
When re-releasing a build from TFS release, to re-package a CI Nuget package that has already gone to my Proget development feed, there does not appear to be a way to get automatic Semantic versioning.
The help dialog that appears in regards to setting the version within the Nuget packager setup is as follows.
Use Date and Time If you choose 'Use the date and time', this will
generate a SemVer-compliant version formatted as X.Y.Z-ci-datetime
where you choose X, Y, and Z.
Use an Environment Variable If you choose 'Use an environment
variable', you must select an environment variable and ensure it
contains the version number you want to use.
Use the Build Number If you choose 'Use the build number', this will
use the build number to version you package. Note: Under General set
the build format to be
'$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
I’d like to be able to re-release a Nuget package that has gone from my CI build in TFS to my Proget development feed, over into my production Proget feed. Microsoft has a great article on Versioning NuGet packages in a continuous delivery world. In that article they elude to the fact that they are doing something similar, but they aren’t providing any real direction for how it was accomplished.
Question:
How would you configure the Nuget packager so that upon creating the package you would input a build variable? Or is there a way that you could set the major version and just have the minor increment each time? How are others handling the promotion of packages from development to production?
Have tried the following:
Tried $(Version) as a build & release variable, and it doesn’t seem to work. The package gets tagged with the date. Also, this only seems to be really functional in the Build portion of TFS where the modal window contains a spot to modify this value.
Tried using the date & time method, and it sticks CI into the build number. This is almost exactly what we want minus the CI definition. Because it automatically inserts CI, this is not suitable for production.
Turned it off and it pulls the version from the Nuspec, but then this would assume that in your CI build you are always upping the version number to one more than current after you have pushed your last release version. This is because the nuspec is in the build files that you are re-releasing through the TFS release chain. Confusing to say the least.
Use the build number set to $(BuildDefinitionName)$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) What I’d like here is $(Major).$(Minor).$(Patch). Trying $(Version)$ with a version of 1.0.0 gets you a file named with that has 2017.11.3.1 as the output, seemingly ignoring the $(Version) variable.
Not sure if I totally got your point, seems you would like to create a semantically versioned nupkg after ci process on TFS.
Usually the nupkg should be as shown MSVersioningSample: 1.0.8-ci-20171106-156033.nupkg
However you would like to rename nupgk and republish it to nuget server as the release version simply MSVersioningSample: 1.0.8.nupkg The same as $(Major).$(Minor).$(Patch).
You need to edit NuGetPackager.ps1 in the build agent, change the $VersionRegex value, details you could have a look at the answer in this question: How do I get TFS 2015 to parse 3 digit versioning for NuGet packaging
Also give a try with some 3-rd party extension to handle with Semantic Versioning in TFS build, release task, nuget package, a sample for your reference: Semantic Versioning Build and Release Tasks
Besides just a note: Semantic Versioning 2.0.0 is only supports with NuGet 4.3.0+ and Visual Studio 2017 version 15.3+.
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.
We have upgraded from TFS 2013 to TFS 2017, One feature we are trying to implement that we had in 2013 was the ability to have a custom build number. the previous method we had a file called BuildVersion.XML which during the first build step would read the major,minor, and revision and name the build with that build number + 1 on the revision. It would then change then checkout and update the revison number and check in the new version. I know that there are steps where people update the AssemblyInfo. The issue is that not all our code is .net apps. we also now have SSIS Packages, Cordova iOS/android apps, angular sites, aws Lambda functions with node.js which do not have the concept of AssemblyInfo. is there an easy way to implement this?
You can do exactly the same thing in Team Build in TFS 2017.
You can update the build number from any task by calling:
Write-Verbose -Verbose "##vso[build.updatebuildnumber]1.2.3.4"
Add a PowerShell task and add an inline script to read from your file and update the build number with the above.
You can then have additional scripts that use the build number any way you need to version your application.
You can see the full list of logging commands here
https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md
You can use my VSTS TFVC tasks to interact with source control, though I do not recommend it. I built these tasks for clients of mine who were doing exactly what you are doing.
Instead of relying on a file in source control it would be a much better solution to pass the BuildNumber from the Build Definition along to the build, have one of your first steps update the files on disk with the correct version number then run your build.
If you manipulate files during the build and check them in you run the risk of inconsistent numbering when you scale up to multiple build agents, it's hard to use in combination with parallel builds and build variable multiplexing and it becomes notoriously hard to do Gated Checkins and Shelveset builds. Plus, it limits your options to move to Git in the future.
I've been tasked with setting up a new Team Foundation/Build server at my company, with which we'll be starting a new project. Nobody here currently has experience with TFS, so I'm learning all of this on my own. Everything is working so far; The server's been set up, the Repository and Team Project has been created, the Build Server has been created, and I've created a simple hello world application to verify the source control and Continuous Integration builds (on the build server) run properly.
However, I'm having a problem setting up the automatic versioning. I've installed the TfsVersioning project, and it's working fine; I'm able to define a format for my assembly versions. I haven't yet decided what format I'll use; probably something like Major.Minor.Changeset.Revision (I'm aware of the potential problem regarding using the changeset number in the assembly version, so I may decide to switch to Major.Minor.Julian.Revision before we begin development).
The problem:
I don't want assemblies to have new file versions if their source code has NOT changed since the last build. With a continuous Integration build this isn't a problem, as the build server will only grab the source files that have changed, causing an incremental build which produces only updated modules; the existing unchanged modules won't be built, so their version will remain unchanged.
If I set up a nightly build, I'll want to clean the workspace and perform a Build-All. However, this means that ALL assemblies will have new version (assuming the Assembly File Version includes the build number).
A solution?
This has prompted me to consider using the latest changeset number in the Assembly File Version. This way, if nothing has been committed between two successive Build-Alls, the versions won't be incremented. However, this would mean that a change and commit to a single file would force a version increment on ALL assemblies.
I'm looking for one of two things:
A way to only increment Assembly Version Numbers if their source/dependencies have changed since the last build. Successive Build-Alls should not cause changes in version numbers.
OR
A way for testers and non-developers to be able to tell version W.X.Y.Z and version W.X.Y.Z+1 of assembly 'Foo' are identical, even though they have differing file versions.
I've probably read about 20 articles on the subject, and nobody (except this guy) seem to address the issue. If what I'm asking for isn't common practice in the Team Foundation ALM, how do I address the second bullet point above?
Thanks for your time!
This is something I did in the past. The solution has two critical points:
You must use an incremental build, i.e. Clean Workspace = None
The change to AssemblyInfo.cs must be computed at each project
This latter is the most complex and I will just draft the solution here.
In the custom MSBuild properties use CustomAfterMicrosoftCommonTargets to inject an hook in normal Visual Studio compile
/property:CustomAfterMicrosoftCommonTargets=custom.proj
Also forward a value for the version
/property:BuildNumber=1.2.3.4
In custom.proj redefine the target BeforeCompile to something similar
<Target Name="BeforeCompile"
Inputs="$(MSBuildAllProjects);
#(Compile);
#(_CoreCompileResourceInputs);
$(ApplicationIcon);
$(AssemblyOriginatorKeyFile);
#(ReferencePath);
#(CompiledLicenseFile);
#(EmbeddedDocumentation);
$(Win32Resource);
$(Win32Manifest);
#(CustomAdditionalCompileInputs)"
Outputs="#(DocFileItem);
#(IntermediateAssembly);
#(_DebugSymbolsIntermediatePath);
$(NonExistentFile);
#(CustomAdditionalCompileOutputs)"
Condition="'$(BuildNumber)'!=''">
<Message Text="*TRACE* BuildNumber: $(BuildNumber)"/>
<MyTasksThatReplaceAssemblyVersion
BuildNumber="$(BuildNumber)"
File="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"/>
</Target>
You need to have a task for replacing the AssemblyFileVersion in the AssemblyInfo.cs source. MSBuild Extension Pack has an AssemblyInfo task for this purpose.
I posted the full details at my blog here, here and here.
I'm starting to dive into TFS 2012 and I have a basic understanding of the tiers and how build servers, controllers and agents work and how different build scripts can have different configurations and projects.
However, one of the things I'm struggling with is a requirement for our source control solution that says that I need to be able to prove a particular changeset or shelfset produced a particular build. That is, given a particular binary, I can point to a release changeset that generated that binary. I should also be able to point to the test changeset that was merged into the release branch. The idea here is not just a separation of duty, but validating that because the release and test changesets are identical, no code was injected into a project by a code reviewer.
I've read one blog post that talks about "Binary promotions" -- would that concept be useful in my situation? I'm having a hard time finding how this binary promotion is set up in TFS.
Deployment
Out of the box TFS doesn't really support deployments, it can deploy to 1 location on build which often is a test server (think lab management). TFS 2012 has built in support for Azure deployments, but they still happen at the end of a build and the build artifacts cannot be automatically deployed to a new location.
You could modify the build template to allow to release to different locations, but that would still be a fresh build for every environment and not true binary promotions.
TFS does, however, have a concept of build quality and actually fires off events when this quality is changed. TFS Deployer is a 3rd party tool that hooks into the quality change event and can execute powershell scripts. This means with a simple change of a dropdown value you can automatically kickoff a script that releases to any environment you want. You can customize the build quality list (per team collection) to be a list of environments (dev, uat, staging, production etc) which the script then figures out where to release the specific build to.
VS2012 also has some nice improvements to web deploy which means deployment configurations are stored in source control with the project, which in theory means they'll be available in the drop folder for TFS Deployer to make use of.
I don't believe TFS keeps a history of build qualities, which means you can't really use the build quality history to maintain a list of what is deployed to which environment. You could fairly easily record this information as part of the deployment script though. Or at the very least add a custom summary node to the build with information about the release.
TFS2012 does have the ability to mark a build as deployed as part of the Azure deployment functionality, you mark tfs deployer builds as deployed using a script but it doesn't feel very useful.
Octopus Deploy is another project that's worth checking out, and could be used instead of TFS Deployer if your build template creates NuGet packages. It requires a bit more control over the production hardware as you need to install agents on each environment to handle releases, but it solves a lot of other issues with deployment.
Versioning
Once you have a nice consistent way of automatically releasing that people don't bypass, you can look at enhancing the build template to inject the build version, or changeset number as the assembly version for anything built as part of that automated build. There's a number of different ways to do it and plenty of blog posts and tools to help you achieve that.
Alternatively you could just use automatic assembly versioning ([assembly: AssemblyVersion("1.0.*")]) to give you the date/time the build occurred, which ends up like 1.0.1234.123 where 1234 is something like the days since jan 1st 2000, and 123 is the minutes since midnight (my specifics may be wrong here).
If you're deploying websites, then I highly recommend injecting the current build version into the html somewhere. This way you can check what version a website is running without needing access to the bin directory. It can also be appended as a querystring to css/js file imports to ensure no browser caching occurs between versions.
Thoughts
Personally I'm hoping Microsoft realise that the xaml build workflows are trying to do too much and that they split the different concerns (build, test, deployment...) into different scriptable parts. Of course that would not be until the next major release of TFS which is years away. Although with Team Foundation Service they are trying to iterate a lot quicker, so they may actually extend the Azure deployment stuff into something more useful in the nearer future.
i have a nightly build in my TFS server that runs every night and is working completely fine. we plan to create a clickonce application as well which is currently working fine except the publish version (ApplicationVersion) which we want to automatically increment with each build instead of entering it manually. An important point to mention is that we only want the Revision part to be increment by 1 with each build. e.g 1.1.1.1 for first time and 1.1.1.2 for the next build.
Please note as alot of information is available for assembly versioning so i am not at all interested in it, i just want my application version to increment so please do point me in this direction.
My VS and TFS server is 2008.Is there any way i can edit my Publish version before build as i do in this case to edit the InstallUrl of the projecte-g
<File.RegEx Path="$(BuildDirectory)/Sources/Client/Client/Client.csproj"
RegularExpression="<InstallUrl>(.*?)</InstallUrl>"
NewValue="<InstallUrl>$(InstallUrl)</InstallUrl>" Force="true"/>
The publish version is a combination of
<ApplicationVersion>
and
<ApplicationRevision>
and in my scenerio it is defined as follows
<ApplicationRevision>1</ApplicationRevision>
<ApplicationVersion>1.9.4.%2a</ApplicationVersion>
and then
<File.RegEx Path="$(BuildDirectory)/Sources/Client/Client/Client.csproj"
RegularExpression="<ApplicationRevision>(.*?)</ApplicationRevision>"
NewValue="<ApplicationRevision>$(ApplicationRevision)</ApplicationRevision>" Force="true"/>
<File.RegEx Path="$(BuildDirectory)/Sources/Client/Client/Client.csproj"
RegularExpression="<ApplicationVersion>(.*?)</ApplicationVersion>"
NewValue="<ApplicationVersion>$(ApplicationVersion)</ApplicationVersion>" Force="true"/>
But the value is never incremented after first run. after the first run the value is always 1.9.4.1. Is there any way that it should be incremented for the next Build. Have tried application revision with *+1, #+1 ...
You should update your TFS server to TFS 2012 first. This will maintain support for VS2008 (TFS 2013 no longer supports it) and gives you access to community tools that no longer support 2008.
You will find two custom activities in the TFS Community Build Extensions that will do what you need.
ClickOnce - this updates and configures the manifests for clickonce deployments from build
TfsVersion - this creates and populates the versions number with the correct incrementing
No, I do not know any what to do this (except to roll you own) in TFS 2008. It is just too old to be supported by the community.