I want to make the builds on a specific branch advance the version number in AssemblyInfo.cs files and in Package.nuspec files according to the Semantic Versioning convention (*).
In order to do this, when code is merged into this specific branch, I want to:
Ask the merging user for a new version number, preferably during merge (then run build during check-in) or when the user runs a manual build, preferably displaying a custom dialog which displays current version number and asks if API has been broken, expanded or if changes do not affect API, then save the new version number aside.
Apply version number to AssemblyInfo.cs file(s). (Related link)
Apply version number to Package.nuspec file(s).
Run build.
Publish resulting NuGet packages.
I am not sure how to get the first step working, as it is interactive.
Has anyone tried such as approach before?
Are there any known solutions?
Any tips how to solve this?
(*) Semantic Versioning convention:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Related
I would like to integrate an automated versioning system in my ASP.NET project. For each release, it should have a version number based on the previous release. I am planning to integrate Gitversion https://gitversion.net/. Does anyone use it in your projects? For the CI/CD pipeline we have teamcity and octopus deploy.
What is the best practice for automated software release versions?
Thanks in advance
As one of the maintainers of GitVersion, I'm obviously biased, but since you're asking how to use GitVersion to implement a "best practice for automated software release", I'm going to unashamedly give you a textual description of a talk I've done on how I prefer to version and release software with GitVersion, TeamCity and Octopus Deploy.
Developer Workflow
The first thing you should figure out is what kind of developer workflow you want for your software. GitVersion supports Git Flow and many simplified variants of it, and GitHub Flow (as well as many other trunk based development flows). Which workflow you should choose depends on what type of software you are developing, your team and most importantly; your personal preference.
Once you have chosen your workflow, you can configure which mode GitVersion should operate under.
Version Source
GitVersion works by calculating a version number from your Git repository. This means that you should not commit a version number to Git in any shape or form. Not within a package.json, pom.xml, .csproj, or any other build- or project-related file that often mandates the existence of a version number.
Versioning
Instead, you should allow GitVersion to produce a version number based on the Git history, using the currently checked out commit as its starting point, and searching through the parents and their tags to calculate an appropriate version number for the current commit. This version number can then be used in any way you want in your build pipeline. You can, for instance, write GitVersion's FullSemVer variable to package.json by executing the following command:
npm version $GitVersion_FullSemVer
If you are developing on the .NET platform, it's also possible to use GitVersion to patch your AssemblyInfo.cs files so the calculated version number is compiled into your assemblies. With InformationalVersion containing the SHA of the Git commit being built and versioned, you'll be able to identify the exact origin of a compiled assembly.
Build
Once you have your workflow in order and GitVersion has a good source of information to use for its versioning, you can go ahead and create a build pipeline for your software. A typical build pipeline will look something like this:
git clone. (Ensure that the clone is complete and not shallow or a detached HEAD. See requirements for more information.)
GitVersion. Execute GitVersion by whichever means make most sense to your environment.
Patch. Patch the version number created by GitVersion in step 2 into every file in your repository that makes sense, such as AssemblyInfo.cs, package.json, etc.
Build. Perform the build of your software.
Test. Run tests that ensure the quality of the software.
Package. Create a package of your software, using the version number created by GitVersion in step 2.
Release. Release the package using the package management software of your choice, such as Octopus Deploy, npm, nuget, composer, or similar.
Test. Perform automatic tests of the released software, if possible. If successful, it's possible to automatically promote the released software to other environments, if applicable.
Through GitVersion's built-in support for build servers, the calculated version number will also be promoted to the build server to version the build itself. This will be done automatically on TeamCity, for instance. In TeamCity, I recommend that you run GitVersion as its own build configuration exposing the required variables which can then be used in dependent build configurations later on.
Release
Once you have a built artifact containing the version number generated by GitVersion, you can use the same version number to create a package, create a release and deploy the release in Octopus Deploy.
You told you want to integrate an automated versioning system? I would like to throw my hat in the ring.
I am author of Vernuntii, a simple semantic versioning library with git integration.
The answer of #Asbjørn told you already about the best practices for example choosing a workflow that is suited for your project.
The main part a versioning tool like GitVesion or Vernuntii is to generate a suitable NEXT VERSION based on (non-)existing git tags.
So at the end of the day it is a matter of taste what kind of complexity you want HOW the NEXT VERSION is calculated.
So when you want cross-branch versioning, then you are good to go with GitVersion, but if you don't need that kind of complexity then you can try a single-branch versioning like it is implemented in Vernuntii.
For more informations take a look at the README.md of Vernuntii.
Here, for giving you my impression of versioning tools and their complexity, let me give you a list (sorted from least complex to most complex):
MinVer
Verlite
Vernuntii
Nerdbank.GitVersioning
GitVersion
A fun fact beside: all libraries from top to Vernuntii also allows to calculate the next version from detached HEAD.
I did my build numbers as 1, and then 2.
Does this matter - is it just a mater of preference as to how you do them?
The Build Number (or CFBundleVersion) is not shown in the App Store so for the user it does not really matter.
The purpose of the Build Number is that developers can distinguish different builds using the same Version (CFBundleShortVersionString).
Consider you are working towards a version 2.1.0. Before you publish this version on the App Store, you probably want to distribute Beta builds to testers. If they report any issues and you fix them, you will need to create and upload a new build but probably still use the version 2.1.0. In that case you would use the Build Number to distinguish the two version.
You can use whatever you like as a build version. Apple provides a tool to increase the Build Number in Xcode projects named agvtool.
Another way (and what I personally do) is to use the git commit count as the Build Number. This can be automated via a Build Phase. That way, every change that you make (and commit) automatically increases your Build Number.
I have set up my TeamCity 10.0.3 to create an assembly version number during the project build that uses the build.vcs.number (which corresponds to the changset number on the VCS Root - taken from Plastic SCM) as one of the parts.
The format is similar to this; {major}.{Minor}.{build.vcs.number}.{build counter}
This method has worked perfectly for quite some time returning the changset number (and only the number) from my VCS system.
The Plastic plugin for TeamCity has now been upgraded to the latest version (SNAPSHOT-201611231807) and since the upgrade after the VCS Root has been created the build will successfully return the changeset number that can be used within the assembly version number.
The error occurs as soon as anyone checks something into the monitored branch - at this point if an automatic or manual build is triggered the information returned as build.vcs.number has lots of additional information that breaks the build.
An example of what is returned after a checkin is:
cs.418 (guid:6a2d5c45-b1b8-4f03-889c-3f3c80c6e209)
This appears to be both the changeset number along with the ID of the changset.
If I re-create the VCS root from scratch the correct number will be returned - until something is checked back in.
How can I resolve this error as all I want returned is the changset number
many thanks in advance
We have just released a new Teamcity plugin version including new features and a big code refactor. We are aware of this problem and we are going to configure the "build.vcs.number" variable to always show the changeset number (as we do in previous versions of the plugin). The task should be done very soon.
Please contact us at support at codicesoftware dot com if you need more information.
I'm trying to setup my VisualStudio project to set the assembly version based on the latest subversion revision number as described on this page. But the version number always seems to lag one revision.
I've split out the assembly version attribute into a separate file, VersionInfo.cs, that is updated with a pre build event.
I'm using the following code to display the version number in the title of my form:
System.Reflection.Assembly assem = System.Reflection.Assembly.GetExecutingAssembly();
this.Text = "My Program Version: " + assem.GetName().Version.ToString();
Here's an walk through of what's happening.
I commit my project so that it is at the latest revision.
Using TortiseSVN I use show log to see that I'm at revision 55
I build my solution.
I then open VersionInfo.cs and see that the pre-build event correctly overwrote this file as
[assembly: System.Reflection.AssemblyVersion("0.1.55.*")]
Yet when I run the program the title bar displays and old version 0.1.52.20486
Next I open the project file in notepad, and change something, such as adding a blank line, and then save the file.
VisualStudio shows a notification that the project file has changed and prompts me to reload the project which I accept
Now when I build and run the program the form shows version 0.1.55.20645
I make a change to something in the project, and commit to SubVersion.
TortiseSVN confirms my working copy is now at revision 56.
I build my project and VersionInfo.cs is correctly updated to
[assembly: System.Reflection.AssemblyVersion("0.1.56.*")]
I try running the application again and the forms title shows 0.1.55.20750 rather then 0.1.56.xxxxxx
Also I've noticed that even if I rebuild/rerun my application the build number (the last number in the version number) is also not updated. It was my understanding that the asterisk would be replaced my a new number at each build.
Any one have any idea what's going on?
I haven't worked with the specific tool you are using but the tool I am using requires you to do an update on your sandbox after your commit. Has something to do with the tool using the revision number retrieved by the last update, not the last commit.
When you checkin a file, the revision number is incremented as you know. The problem is, you do not know what that revision number will be when you checkin - you only find out after checkin.
So, if you take the latest revision number, build your project, then checkin - the number used will always be out of date. What you really want is to be able to checkin, then get the revnum of the commit you've just performed, and then build your project with the correct version number.
Obviously this is not possible.
There is a way round it - use a CI system that builds your project immediately after checkin (through a post-commit hook). These will checkout the latest version you've just added, update your version.cs file, then build. The disadvantage is that your version.cs file will never contain the correct version number (unless the CI system then checks just it in again)
The best way to handle this is when you do your build.
I use Jenkins as my continuous build server instead of relying on doing a manual build on my system. If you don't use something like Jenkins (Hudson, Atlassian Bamboo and CruiseControl are three other popular Continuous Build servers), you should. This way, your official builds are not dependent upon a particular developer machine.
If you do use Jenkins, you can now use Nant or even Ant to help you manipulate your build. We are doing this now with Jenkins and Ant.
What I do is use msbuild.exe to build my project using Jenkins. Before I do a build, I use Ant to retrieve the Subversion revision number (actually, we use Jenkin's build number, but the theory is the same) to modify the assembly file with the correct version. Then, I do a build itself. The results is the correct Subversion revision number (err.. in our case the Jenkins Build Number) in the assembly file when it's built.
Come to think of it, you can probably do what you're doing now to set the Revision in the Assembly file. Jenkins will then build the project with the correct Revision number in the assembly file. You download the built package, and you'll see the correct version number in the title bar.
I am looking forward to implementing a daily build for an upcoming project.
But before doing that, I need to know how to properly version an assembly.
I have the following concerns:
Should each assembly have an independent version number or should they all share the same version?
Should I use a * version for build and revision?
Is revision relevant to daily build?
We stamp all the assemblies within our products with the same version number using the following steps:
Link all assemblies to an
AssemblyInfoCommon.cs containing the
version number info: see here
for an example.
Generate the AssemblyInfoCommon.cs file as part of the build
using (in our case) the NAnt asminfo task, Cruise Control .NET and the SVN revision labeller
In our case, we don't use the * version. All deployed versions are built on the build server. We don't worry about version number on our desktops.
The answer really depends on what you are trying to accomplish with the assembly version numbers. If you are doing a ClickOnce deployment and want to do independent downloads of updated assemblies, you will need to have each assembly independently versioned -- otherwise, I think it's often nice to have assembly versions match the software release number. In more complex scenarios you may need another strategy.
A scheme I used at a prior company was major.minor.revision.build -- so in version 1.0 of the product, the assembly version and assembly file version on each assembly was 1.0.0.1129 (for example). This made it easy to match up what assemblies were part of which software release, down to the build number. We accomplished this using a pre-compilation search and replace in each AssemblyInfo.cs file to replace a token with the version numbers provided by our automated build process.
So Each assembly should have the same version which is typically a combination of the release version ie 3.4 + the build number which is a sequence that represents the number of times that release has been compiled on the build server. The revision is relevant because it demonstrates the number of builds that you have created for that release. You can really do this in one of 2 ways. The first way would be that if you planned a release ie 3.4 then when you start working on that release then that is your major version number and your minor version number increments with the build. Another way to do this is to tightly control the build versions in that when you are ready to perform your release to QA / Regression you set your major version to 3.4 and you leave your minor version number to 0. You keep things tightly controlled this way until you release. This way you can control your service pack numbering through the minor version number. Hope this helps.
I would normally agree that all assemblies should have the same version number; however, I would make one caveat to that. If one of the assemblies is used somewhere else outside of this project or if it is considered it's own project it should have it's own version number. It should also probably be moved out of that solution and into it's own. The only reason I mention this is that I have seen numerous occasions where people have an assembly that's used in a couple of other places, but mainly in one place and they try and keep the version straight. It's a bad idea to do that. I think the Single Responsibility Principle applies at the solution/project level as well.
As far as numbering goes, I agree with Guy Starbuck (major.minor.revision.build). That's the way I've always done it and it has always worked well.
We have a large app (hundreds of assemblies) with frequent releases (about 1 a month). We went for the "give every assembly the same version" but its a constant source of fustration to me that assemblies for 1 version are completely incompatible with those from another, despite the fact that the interfaces of these assmblies rarely (if ever) change.
If this is case for you then you might benefit from versioning assemblies separately - each time you update your assembly only bother to increment the version number in cases where you actually want to break assembly binding (for example if the interface changes, or the changes are otherwise significant enoigh that you want to prevent someone from accidentially using the previous version).