I’m having trouble with versioning the packages and releases, so I need some advice.
Scenario
We are working on the 3.1.5 release of our product. Every check-in needs to be deployed automatically to our development environment in Octopus. The development team is allowed to deploy the release to the next environment: Test. Our acceptance team is allowed to deploy to the last environment: Acceptance. This results in the following setup:
Development (CI)
Test
Acceptance
This is configured in our vsts build server and Octopus.
Problem
The package version is not being auto incremented, so the development environment won’t update to the latest version.
I tried multiple options, like manually adding the version number as a MSBuild argument: /p:OctoPackPackageVersion=3.1.5.$(Build.BuildNumber)
Question
Can someone explain how I should setup a (simple) strategy for correctly versioning my packages and releases?
You are on the right track by using Octopack’s /p:OctoPackPackageVersion along with a TFS variable to have your package version always matching your build. Though from my experience, the variable $(Build.BuildNumber) holds the entire build version, and not only the build number. See what I’m talking about on my last reply on this other thread: http://help.octopusdeploy.com/discussions/questions/6945
What does your package version look like at the end of your build?
If you manually set a value like 14.0.0 to the Octopack parameter, does it get passed to the Package version as expected?
If you could send a full build log it would also help with the troubleshooting
I removed all the old packages, but I used the following format: 3.1.5.$(Build.BuildNumber). The variable format is: $(date:yyyyMMdd)$(rev:r)
Yes, this works. The only problem with this approach is that it will throw an error when you try to push the package with the same version number. I know you can override that with the ?replace=true parameter, but then it will complain about a delta mismatch or something.
What we would like to accomplish is this (while we are working on release 3.1.5)
A developer checks something in
The package version is updated to something like: 3.1.5.{incremental value}
The packages is pushed to the octopus fede
The package is automatic deployed to Dev environment
This way it’s much easier for us to track the packages and the corresponding work items.
Thanks for answering those questions. With the answer to (2) we confirmed that Octopack is properly passing the version string to the package. This means that what you need to find here is the right combination of TFS variables to pass to the Octopack parameter.
This will ultimately depend on which version of TFS you are using. I just tested this on an internal TFS 2015 server we have which is the same as Visual Studio Online/Visual Studio Team Services.
see attached screenshot for each step
1) Setting the build number format to be `3.1.5.{incremental value}`
2) Setting the Octopack parameter to `/p:OctoPackPackageVersion=$(Build.BuildNumber)` where `$(Build.BuildNumber)` will be equal to the full build number (`3.1.5.{incremental value}`)
3) Checking the build results to corroborate that the right version string was passed the Octopack, and therefore to the package version.
If you are on another version of Visual studio, the logic should be fairly similar, but It’ll be up to you to investigate which TFS variables have to be used.
