Skip to content

Commit 337f068

Browse files
HHobeckHHobeck
committed
Update documentation in docs/input/docs/reference/modes/*
1 parent 1e248e2 commit 337f068

File tree

4 files changed

+67
-168
lines changed

4 files changed

+67
-168
lines changed

‎docs/input/docs/reference/modes/continuous-delivery.md

Lines changed: 17 additions & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -2,75 +2,33 @@
22
Order: 20
33
Title: Continuous Delivery
44
Description: |
5-
Continuous Delivery is the default versioning mode. In this mode,
6-
GitVersion calculates the next version and will use that until that is
7-
released.
5+
Sometimes you just want the version to keep changing and deploy continuously
6+
to an testing system. In this case, Continuous Delivery is a good mode to
7+
operate GitVersion by.
88
RedirectFrom: docs/reference/versioning-modes/continuous-delivery
99
---
1010

11-
Continuous Delivery is the practice of having a deployment pipeline and is the
12-
default mode in GitVersion. Each stage of the pipeline gets the code going
13-
through the pipeline closer to production.
11+
Continuous Delivery is the process of checking into a branch, running all the
12+
tests and if everything goes green it is automatically pushed to a testing system.
1413

15-
The topic itself is rather large, here we will just focus on the building and
16-
creation of _releasable_ artifacts. This is only a part of continuous delivery
17-
as a whole, with the hard part being the ability to measure the impacts of what
18-
you have deployed into production.
14+
A good case for Continuous Delivery is when using Octopus deploy, as you
15+
cannot publish the same version of a package into the same feed.
1916

20-
In essence continuous delivery means:
21-
22-
* Your code is automatically built and tested
23-
* If any of the automated tests fail, the team's #1 priority is to fix the
24-
build
25-
* If the build is green, the application can be deployed at any time
26-
* Ideally the business should make that decision
27-
* The same artifacts which were built and tested should be deployed
28-
* That means no rebuilding everything when you are deploying
29-
30-
Continuous delivery does not work well with GitFlow. The reason is that you are
31-
required to _merge_ to main to do a release, triggering a rebuild and a new
32-
set of artifacts to go through your pipeline. Depending on how long your
33-
pipeline is, this could be a while.
34-
35-
GitHubFlow is a better fit for Continuous delivery, the [mainline
36-
development][mainline] model means that every merged feature branch will be
37-
built as a _stable_ version and if the build/builds go green then you are free
38-
to deploy to production at any time.
39-
40-
## Usage
41-
42-
By default, GitVersion is set up to do Continuous Delivery on all branches but
43-
`develop`, which is set up with [Continuous Deployment][continuous-deployment].
44-
To change the mode to Continuous Delivery, change your
45-
[configuration][configuration] to:
46-
47-
```yaml
48-
mode: ContinuousDelivery
49-
```
17+
For this mode we follow the logic in [this blog post by Xavier Decoster][blog]
18+
on the issues of incrementing automatically.
5019

5120
## How Continuous Delivery affects GitVersion
5221

53-
The thing about continuous delivery is that there will be _multiple_ candidates
54-
to deploy to production and it is a human choice to deploy. This means that
55-
GitVersion will build **the same semantic version** until that version is
56-
deployed. For instance:
57-
58-
* 1.1.0+5
59-
* 1.1.0+6
60-
* 1.1.0+7 <-- This is the artifact we release, tag the commit which created
61-
this version
62-
* 1.1.1+0
63-
64-
Tags are required in this mode to communicate when the release is done as it's
65-
an external manual process.
22+
Continuous delivery is good when you deploy continuously to an testing system.
6623

67-
## Resources
24+
* 1.1.0-3
25+
* 1.1.0-2 (tag: 1.1.0-2) <-- This is the version which has been deployed on testing
26+
* 1.1.0-1
27+
* 1.1.1-0
6828

69-
* [Continuous Delivery on Wikipedia][wikipedia]
70-
* [Continuous Delivery, the book][book]
29+
Tags are not required but optional in this mode to communicate when the release
30+
is done as it's an automated process.
7131

72-
[book]: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
7332
[configuration]: /docs/reference/configuration
74-
[continuous-deployment]: /docs/reference/modes/continuous-deployment
75-
[mainline]: /docs/reference/modes/mainline
33+
[blog]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions
7634
[wikipedia]: https://en.wikipedia.org/wiki/Continuous_delivery

‎docs/input/docs/reference/modes/continuous-deployment.md

Lines changed: 12 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -3,42 +3,27 @@ Order: 30
33
Title: Continuous Deployment
44
Description: |
55
Sometimes you just want the version to keep changing and deploy continuously.
6-
In this case, Continuous Deployment is a good mode to operate GitVersion by.
76
RedirectFrom: docs/reference/versioning-modes/continuous-deployment
87
---
98

10-
Continuous Deployment is the process of checking into main, running all the
11-
tests and if everything goes green it is automatically pushed to production.
12-
13-
A good case for Continuous Deployment is when using Octopus deploy, as you
14-
cannot publish the same version of a package into the same feed.
9+
Continuous Deployment is the process of checking into main and automatically
10+
deploying to production.
1511

1612
For this mode we follow the logic in [this blog post by Xavier Decoster][blog]
1713
on the issues of incrementing automatically.
1814

19-
As such we force a pre-release tag on all branches, this is fine for
20-
applications but can cause problems for libraries. As such this mode may or may
21-
not work for you, which leads us into a new mode in v4 of GitVersion:
22-
[Mainline Development][mainline].
23-
24-
### Usage
15+
## How Continuous Deployment affects GitVersion
2516

26-
By default GitVersion is set up to do Continuous Deployment versioning on the
27-
`develop` branch, but for all other branches, [Continuous
28-
Delivery][continuous-delivery] is the default mode. From version 3 of GitVersion
29-
this behavior is [configurable][configuration].
17+
The thing about continuous deployment is that there will be only one version
18+
to deploy on production. This means that GitVersion will build
19+
**the same semantic version** for every commit until it has been tagged. For instance:
3020

31-
The default behavior for v3 and how v1 & 2 worked was that the version only
32-
incremented after a tag, which signified a release. In v3 you can simply switch
33-
the default mode in the [configuration][configuration] from `ContinuousDelivery`
34-
to `ContinuousDeployment` and the version will then increment each commit,
35-
giving you the features of GitVersion with continuous deployment:
21+
* 1.2.0
22+
* 1.1.0 (tag: 1.1.0) <-- This is the version which has been deployed on production
23+
* 1.1.0
24+
* 1.1.1
3625

37-
```yaml
38-
mode: ContinuousDeployment
39-
```
26+
Tags are required in this mode to communicate when the deployement happens on production.
4027

41-
[blog]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions
4228
[configuration]: /docs/reference/configuration
43-
[continuous-delivery]: /docs/reference/modes/continuous-delivery
44-
[mainline]: /docs/reference/modes/mainline
29+
[blog]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions

‎docs/input/docs/reference/modes/mainline.md

Lines changed: 0 additions & 82 deletions
This file was deleted.

‎docs/input/docs/reference/modes/manual-deployment.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
---
2+
Order: 10
3+
Title: Manual Deployment
4+
Description: |
5+
The Manual Deployment mode can be used to remain on the same pre-released
6+
version until it has been deployed dedicatedly.
7+
8+
RedirectFrom: docs/reference/versioning-modes/manual-deployment
9+
---
10+
11+
Having not the necessity to deploy the build artifacts on every commit is an
12+
indecation of using the __Manual Deployment__ mode. This mode can be used to
13+
remain on the same pre-released version until it has been deployed dedicatedly.
14+
15+
## How Manual Deployment affects GitVersion
16+
17+
The thing about manual deployment is that there will be _multiple_ candidates
18+
to deploy on testing and it is a human choice to deploy. This means that
19+
GitVersion will build **the same semantic version** until that version is
20+
deployed. For instance:
21+
22+
* 1.1.0-2+1
23+
* 1.1.0-1+2 (tag: 1.1.0-1) <-- This is the version which has been deployed on testing
24+
* 1.1.0-1+1
25+
* 1.1.1-1+0
26+
27+
Tags are required in this mode to communicate when the release is done as it's
28+
an external manual process.
29+
30+
## Resources
31+
32+
* [Configuration][configuration]
33+
* [Continuous Delivery on Wikipedia][wikipedia]
34+
* [Continuous Delivery, the book][book]
35+
36+
[configuration]: /docs/reference/configuration
37+
[book]: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
38+
[wikipedia]: https://en.wikipedia.org/wiki/Continuous_delivery

0 commit comments

Comments
 (0)