Filled in a few empty reference docs

Author: JakeGinnivan

docs/reference/continuous-delivery.md

@@ -0,0 +1,26 @@
+# Continuous Delivery
+Continuous delivery is the practice of having a deployment pipeline. Each stage of the pipeline gets the code going through the pipeline closer to production.
+
+The topic itself is rather large, here we will just focus on the building and creation of *releasable* artifacts. This is only a part of continuous delivery as a whole, with the hard part being the ability to measure the impacts of what you have deployed into production.
+
+In essence continuous delivery means:
+
+ - Your code is automatically built and tested
+ - If any of the automated tests fail, the teams #1 priority is to fix the build
+ - If the build is green, the application can be deployed at any time
+   - Ideally the buisiness should make that decision
+   - The same artifacts which were built and tested should be deployed
+   - That means no rebuilding everything when you are deploying
+
+Continuous delivery does not work well with GitFlow. The reason is that you are required to *merge* to master to do a release, triggering a rebuild and a new set of artifacts to go through your pipeline. Depending on how long your pipeline is, this could be a while.
+
+GitHubFlow is a better fit for Continuous delivery, the [mainline development](mainline-development.md) model means that every merged feature branch will be built as a *stable* version and if the build/builds go green then you are free to deploy to production at any time.
+
+## How continuous delivery affects GitVersion
+The thing about continuous delivery is that there will be *multiple* candidates to deploy to production and it is a human choice to deploy. This means that GitVersion will build **the same semantic version** until that version is deployed.
+
+GitVersion assumes Continuous Delivery by default in it's [configuration](../configuration.md), if you want to do [continuous deployment](continuous-deployment.md) then just change the configuration setting.
+
+## Resources
+ - [Continuous Delivery on Wikipedia](https://en.wikipedia.org/wiki/Continuous_delivery)
+ - [Continuous Delivery, the book](http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912)

docs/reference/continuous-deployment.md

@@ -0,0 +1,6 @@
+# Continuous Deployment
+Continuous deployment is the process of checking into master, running all the tests and if everything goes green it is automatically pushed to production.
+
+By default GitVersion is *not* setup to do this. The good news is in v3 of GitVersion this behavior is configurable!
+
+The default behavior for v3 and how v1 & 2 worked was that the version only incremented after a tag, which signified a release. In v3 you can simply switch the default mode in the [configuration](../configuration.md) from `continuous-delivery` to `continuous-deployment` and the version will then increment each commit, giving you the features of GitVersion with continuous deployment.

docs/reference/mainline-development.md

@@ -0,0 +1,6 @@
+# Mainline development
+Mainline development is enabled when using [GitHubFlow](../git-branching-strategies/githubflow.md) or any other strategy where you develop on `master`. The main rule of mainline development is that **master is always in a state that it could be deployed to production**. This means that pull requests should not be merged until they are ready to go out.
+
+To properly achieve mainline development you need confidence in your test suite as if it goes green against a PR then you are confident that you can merge and release that pull request. Another property of mainline development is normally that you fix going forward, not revert. When an issue is discovered with a release, add a test or some sort of check to make sure it won't happen again, fix the issue, then do a release with the fix.
+
+Like all things, it is an approach and will work for some people and not for others. GitVersion is unique in the fact that it works very well with mainline development and the version numbers it generates are *predictive* and indicate what the next version to be released is. Most other approaches require bumping the version number before the release which means that the version being built and the version number which will be deployed are often different.