Search code examples
.netjenkinsoctopus-deploysemantic-versioning

How to auto increment web application version in accordance with semantic versioning?

We're going to follow for Semantic Versioning for our web applications, it looks really nice. Now, Jenkins used as CI/CD tools. We want to use Octopus Deploy as artifacts storage and CD tool, also for fast redeployment/rollbacks and other configuration features.

Octopus requires packages with concrete version (for example: 1.2.4). Therefore, we also need strong versioning for our web applications. Otherwise, how to detect what version was deployed and has bugs.

Solution described here is not transparent and doesn't fully match to semantic versioning:

[assembly: AssemblyVersion("1.0.*")]

Because, Patch version should increment one-by-one from 0, not from "random" number, and resets after Minor increment.

For my opinion - it's better to store version in the repository in the same view (1.2.4) as in package. But I found only this ways how to implement it:

  • Manual increment before commit - uncomfortably and has risks.
  • Auto increment from SVN/Git hooks before commit - requires to configure every workstation.
  • Auto increment from CI tool and commit - makes circular dependency with CI monitoring for changes in repository.

Is there any other ways to implement equal versioning as in repository, as in packages for web application? Or maybe that is unnecessary?

UPDATE 2017-02-28: We found that Jenkins can skip commits from specific users or with specific messages (in Advanced settings). It solves problem with auto increment from CI tool and commit (circular dependency between CI monitoring and changes in repository).

Solution

  • Mostly developers failed to commit right assembly versions in code. Lets say if you've 40 projects and 15 developers then maintaining [assembly: AssemblyVersion("1.0.*")] version will always be an issue.

    I recommend you can checkout code and do Search & Replace to inject right assembly build numbers like [Major.Minor.Build] always. [Major.Minor] to be taken as input and is globally aware to team thus reduce bad dll numbering/ Build number can positively increment and match with that of CI for tracking. SVN commit number can also be mixed with it.