docs: docs update on contributing and travis (#1527)

* docs: docs update on contributing and travis

CONTRIBUTING.md

@@ -1,26 +1 @@
-## So you want to **clone** the project and figure out **what** to do...
-* The good practice is to: 
-    * Fork the project on your account
-    * Clone your repo using HTTPS
-    * Work on a new git branch.
-    * Need help with [git](https://git-scm.com/docs/gittutorial)?
-* The [issues are listed on ocadotechnology/aimmo](https://github.com/ocadotechnology/aimmo/issues). 
-It's even better if you're using [ZenHub](https://www.zenhub.com/) because it will allow you to look at a [Kanban-ish board](https://github.com/ocadotechnology/aimmo/issues#boards) for the project.
-Check the list selected as ["good first issue" here](https://github.com/ocadotechnology/aimmo/contribute).
-## Now you want to **test** your changes and **run** the project locally...
-* To work on the project, you can use whichever editor you like. Recommended: [VSCode](https://code.visualstudio.com/) with [black formatter](https://black.readthedocs.io/en/stable/) installed.
-* Follow the [setup guideline here](https://github.com/ocadotechnology/aimmo/blob/development/docs/usage.md).
-* You can test your change by running the test suite: `pytest`.
-* Don't forget to add comments if you think they will help other people to understand your code.
-
-## Great, you can **push** your changes, open a **Pull Request**, and someone in the core team will **review** it...
-
-- Your PR title must follow the [semantic PR](https://github.com/zeke/semantic-pull-requests). Basically use `feat:` prefix for feature, and `fix:` prefix for bug fixes.
-- Your PR should be connected to a corresponding ZenHub issue.
-- All required status checks must pass.
-- We use [Reviewable](https://reviewable.io/) for code reviews. Keep an eye on notifications from reviewable. You might need to go back, revise your code and push the changes again. Repeat until the PR is accepted.
-## When a PR is accepted
-
-- It will be merged into the  development branch and will get deployed into [the staging server](https://staging-dot-decent-digit-629.appspot.com/)
-
-- Eventually, what's on staging will make its way up to [production](https://www.codeforlife.education/). Congrats! 🎉
+Please review our contributing documentation at https://docs.codeforlife.education/

docs/deployment/deployment-events.md

@@ -1,16 +1,20 @@
 # Deployment Events
 
+**_We have moved to using Github actions for our CI. This sections needs updating._**
+
+---
+
 We use Travis for contiguous integration. Travis CI is the first step in our integration pipeline. Each time a push is made Travis runs all our tests. We are currently in the process of migrating our coverage reports from [coveralls.io](https://coveralls.io/) to [codecov.io](https://codecov.io/).
 
 Our package Django app `aimmo` is deployed to [Pypi](https://pypi.python.org/pypi/aimmo) and we use [Versioneer](https://github.com/warner/python-versioneer) for package versioning.
 
-The rest of the components are Dockerised. Travis CI automatically recognises the **Dockerfiles** inside of each of the modules and pushes the newly created images to the **Docker Hub Registry**. Each of the components are then pulled automatically by the Google Cloud Container Engine. 
+The rest of the components are Dockerised. Travis CI automatically recognises the **Dockerfiles** inside of each of the modules and pushes the newly created images to the **Docker Hub Registry**. Each of the components are then pulled automatically by the Google Cloud Container Engine.
 
 After all the Travis processes are finished, a curl request is made to SemaphoreCI. SemaphoreCI is responsible for orchestrating the deployment processes for all the Code For Life repositories. The Django application `aimmo` is installed directly from Pypi together with all the other modules. Due to the modularity of Django, the aimmo app can be just plugged inside the bigger Django project. _Currently, the pulled version in production will be the latest stable release._
 
 The application is then deployed to the Google Cloud. This finishes our build.
 
-Once the application is deployed to the Google Cloud, it needs to find the other services. The discovery of the game services provided is done using a hook that can be found in [this repository](https://github.com/ocadotechnology/codeforlife-deploy-appengine). 
+Once the application is deployed to the Google Cloud, it needs to find the other services. The discovery of the game services provided is done using a hook that can be found in [this repository](https://github.com/ocadotechnology/codeforlife-deploy-appengine).
 
 ```python
 AIMMO_GAME_SERVER_LOCATION_FUNCTION = lambda game: ('http://staging.aimmo.codeforlife.education', "/game/%s/socket.io" % game)

docs/life-cycle-of-a-code-change.md

@@ -1,16 +1,20 @@
 # Life cycle of a code change
+
 Once you're confident with the changes implemented in your local branch, you should push them and open a GitHub pull request that can be reviewed and approved. **Note that** this should be a `semantic` pull request.
 
 ## Development to Staging
+
 The branch is ready to be merged into the `development` branch when all changes are reviewed and there are no conflicts or blocking errors.
 
-After the PR is merged in, a `development` build starts and a beta release may or may not be created depending on the semantic PR title (see [semantic release notes](https://github.com/semantic-release/semantic-release)). The version is updated (with the format `b<TRAVIS_BUILD_NUMBER>`) and the following are built and pushed:
-* aimmo `PyPi` package (beta)
-* `Docker` images: aimmo-game, aimmo-game-creator and aimmo-game-worker (beta)
+After the PR is merged in, a `development` build starts and a beta release may or may not be created depending on the semantic PR title (see [semantic release notes](https://github.com/semantic-release/semantic-release)). The version is updated and the following are built and pushed:
+
+- aimmo `PyPi` package (beta)
+- `Docker` images: aimmo-game, aimmo-game-creator and aimmo-game-worker (beta)
 
 Once the new beta version is released on PyPi and Docker Hub, Semaphore CI is notified and deploys it to our staging server, where the code changes will be tested further. See more details in our deploy app engine [documentation](https://github.com/ocadotechnology/codeforlife-deploy-appengine/blob/master/docs/life-cycle-of-a-code-change.md).
 
 ## Staging to Production
+
 Once the changes on `development` are stable, this branch is merged into the `master` branch, updating it with the latest beta release. This triggers a `master` build and creates a release version. Deployment to production is manually triggered on Semaphore CI.
 
 After a successful deployment, the `master` branch has to be merged back into the `development` one to ensure that the latter is up-to-date and ready for the next release.