Feature/docs (#165)

* initial readthedocs commit

* docs moved to sphinx / rst / read the docs

docs/building/building.rst

@@ -0,0 +1,12 @@
+Building
+========
+
+* You'll generally want to run the `./build.ps1` script. This will compile, run unit and acceptance tests and build the output packages locally. Output will got to the `./artifacts` directory.
+
+* You can view the current commit's `SemVer <http://semver.org/>`_ build information by running `./version.ps1`.
+
+* The other `./*.ps1` scripts perform subsets of the build process, if you don't want to run the full build.
+
+* The release process works best with GitFlow branching; this allows us to publish every development commit to an unstable feed with a unique SemVer version, and then choose when to release to a stable feed.
+
+* Alternatively you can build the project in VS2017 with the latest .NET Core SDK.

docs/building/overview.rst

@@ -0,0 +1,4 @@
+Overview
+========
+
+This document summarises the build and release process for the project. The build scripts are written using `Cake <http://cakebuild.net/>`_, and are defined in `./build.cake`. The scripts have been designed to be run by either developers locally or by a build server (currently `AppVeyor <https://www.appveyor.com/>`_), with minimal logic defined in the build server itself.

docs/building/releaseprocess.rst

@@ -0,0 +1,23 @@
+Release process
+===============
+
+This section defines the release process for the maintainers of the project.
+* Merge pull requests to the `release` branch.
+
+* Every commit pushed to the Origin repo will kick off the `ocelot-build <https://ci.appveyor.com/project/TomPallister/ocelot-fcfpb>`_ project in AppVeyor. This performs the same tasks as the command line build, and in addition pushes the packages to the unstable nuget feed.
+
+* When you're ready for a release, create a release branch. You'll probably want to update the committed `./ReleaseNotes.md` based on the contents of the equivalent file in the `./artifacts` directory.
+
+* When the `release` branch has built successfully in Appveyor, select the build and then Deploy to the `GitHub Release` environment. This will create a new release in GitHub.
+
+* In Github, navigate to the `release <https://github.com/TomPallister/Ocelot/releases>`_. Modify the release name and tag as desired.
+
+* When you're ready, publish the release. This will tag the commit with the specified release number.
+
+* The `ocelot-release <https://ci.appveyor.com/project/TomPallister/ocelot-ayj4w>`_ project will detect the newly created tag and kick off the release process. This will download the artifacts from GitHub, and publish the packages to the stable nuget feed.
+
+* When you have a final stable release build, merge the `release` branch into `master` and `develop`. Deploy the master branch to github and following the full release process as described above. Don't forget to uncheck the "This is a pre-release" checkbox in GitHub before publishing.
+
+* Note - because the release builds are initiated by tagging a commit, if for some reason a release build fails in AppVeyor you'll need to delete the tag from the repo and republish the release in GitHub.
+
+

docs/building/tests.rst

@@ -0,0 +1,24 @@
+Tests
+=====
+
+The tests should all just run and work apart from the integration tests which need the following 
+environmental variables setting. This is a manual step at the moment.
+
+    ``OCELOT_USERNAME=admin``
+
+    ``OCELOT_HASH=kE/mxd1hO9h9Sl2VhGhwJUd9xZEv4NP6qXoN39nIqM4=``
+
+    ``OCELOT_SALT=zzWITpnDximUNKYLiUam/w==``
+
+On windows you can use..
+
+    ``SETX OCELOT_USERNAME admin``
+
+On mac..
+    
+    ``export OCELOT_USERNAME=admin``
+
+I need to work out a nicer way of doing this in the future.
+
+
+