Skip to content

Commit 7919345

Browse files
committed
Added octopus-deploy docs in
1 parent 106bb18 commit 7919345

File tree

3 files changed

+29
-8
lines changed

3 files changed

+29
-8
lines changed
Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
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.

docs/more-info/version-increments.md

Lines changed: 1 addition & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -17,14 +17,7 @@ If you are using GitFlow then builds off the `develop` branch will actually *inc
1717
If you need to consume packages built from develop, we recommend publishing these packages to a separate NuGet feed as an alpha channel. That way you can publish beta/release candidate builds and only people who opt into the alpha feed will see the unstable pacakges.
1818

1919
### 2. Octopus deploy
20-
Because Octopus uses NuGet under the covers you cannot publish every build into Octopus deploy. For this we have two possible options:
21-
22-
#### 2a. 'Release' packages to Octopus deploy
23-
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.
24-
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.
25-
26-
#### 2b. Configure GitVersion to increment per commit
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.
20+
See [Octopus deploy](build-server-setup/octopus-deploy.md)
2821

2922
## Manually incrementing the version
3023
With v3 there are multiple approaches.

mkdocs.yml

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,7 @@ pages:
2828
- Continua CI: more-info/build-server-setup/continua.md
2929
- Team Build (TFS): more-info/build-server-setup/teambuild.md
3030
- TFS Build vNext: more-info/build-server-setup/tfs-build-vnext.md
31+
- Octopus Deploy: more-info/build-server-setup/octopus-deploy.md
3132

3233
- Git branching strategies:
3334
- Home: git-branching-strategies/index.md

0 commit comments

Comments
 (0)