|
| 1 | +# Octopus deploy |
| 2 | +While not a build server, there are a few things to consider when using Octopus Deploy with GitVersion. |
| 3 | + |
| 4 | + - GitVersion follows [continuous delivery](../../reference/continuous-delivery.md) versioning by default |
| 5 | + - This means builds will keep producing *the same version* with just metadata differing. |
| 6 | + If you try to push every build into Octopus you will have issues |
| 7 | + |
| 8 | +Because Octopus uses NuGet under the covers you cannot publish every build into Octopus deploy. For this we have two possible options: |
| 9 | + |
| 10 | +## Solutions |
| 11 | +### 'Release' packages to Octopus deploy |
| 12 | +Rather than all builds going into Octopus's NuGet feed, you release builds into it's feed. When you push a package into the NuGet feed you need to tag that release. The next commit will then increment the version. |
| 13 | +This has the advantage that if you have a multi-stage deployment pipeline you pick packages which you would like to start through the pipeline, then you can see all the versions which did not make it through the pipeline (for instance, they got to UAT but not production due to a bug being found). In the release notes this can be mentioned or those versions can be skipped. |
| 14 | + |
| 15 | +The steps for this would be |
| 16 | + |
| 17 | +1. Build server has a release build |
| 18 | + - The release build publishes the built NuGet package into a NuGet feed which Octopus deploy consumes |
| 19 | +2. The release build should then automatically trigger the first stage of deployments. |
| 20 | + - This could be into a test/uat environment. You can then use Octopus to promote that version through the different environments. |
| 21 | + - You could also do this manually, but if you are triggering a release build you are indicating that is a candidate which you want deployed |
| 22 | +3. Tag the source commit with the version. This will cause GitVersion to start building the next version |
| 23 | + |
| 24 | +This approach works well with Semantic Versioning, as you will not be burning version numbers between releases (except if a build fails to get through UAT or something, then the burnt number means something!). |
| 25 | + |
| 26 | +### Configure GitVersion to [increment per commit](../incrementing-per-commit.md) |
| 27 | +As mentioned above, this means you will burn multiple versions per release. This might not be an issue for you, but can confuse consumers of your library as the version has semantic meaning. |
0 commit comments