Merge pull request #315 from kinvolk/improve_docs

Improve docs

README.md

@@ -37,22 +37,21 @@ the [Omaha](https://code.google.com/p/omaha/) protocol, with special functionali
 
 Please report any issues in [here](https://github.com/kinvolk/nebraska/issues).
 
-
-## Managing Updates
-
-Read the docs on [how to manage updates](./docs/managing-updates.md).
-
 ## Code of Conduct
 
 Please refer to the Kinvolk [Code of Conduct](https://github.com/kinvolk/contribution/blob/master/CODE_OF_CONDUCT.md).
 
 ## Contributing
 
-If you want to start contributing to Nebraska, please check out the [contributing](./docs/contributing.md) documentation.
+If you want to start contributing to Nebraska, please check out the [contributing](https://kinvolk.io/docs/nebraska/latest/contributing/) documentation.
+
+### Development
+
+For a quickstart on setting up a development environment, please check the [development documentation](https://kinvolk.io/docs/nebraska/latest/development/).
 
 ### User Access
 
-For instructions on how to set up user access, please check the [authorization documentation](./docs/authorization.md).
+For instructions on how to set up user access, please check the [authorization documentation](https://kinvolk.io/docs/nebraska/latest/authorization/).
 
 ## License
 

docs/authorization.md

@@ -1,9 +1,9 @@
 ---
-title: Nebraska Authorization
+title: Deployment & Authorization
 weight: 10
 ---
 
-Nebraska uses either a noop authentication, or OAuth or Bearer tokens
+Nebraska uses either a noop authentication, OAuth or Bearer tokens
 to authenticate and authorize users. Currently, only GitHub is
 supported as an OAuth authentication backend.  [GitHub personal access
 tokens](https://github.com/settings/tokens) can be used as bearer
@@ -29,7 +29,7 @@ the `postgres` container as follows:
 
 # Deploying Nebraska for testing on local computer (noop authentication)
 
-- Go to the nebraska project directory and run `make all`
+- Go to the nebraska project directory and run `make`
 
 - Start the database (see the section above if you need a quick setup).
 

docs/contributing.md

@@ -1,50 +1,53 @@
 ---
-title: Contributing
-weight: 10
+title: Contribution Guidelines
+linktitle: Contributing
 ---
 
-Nebraska is an Open Source project and contributions are welcome. It is usually a good idea to discuss new features or major changes before submitting any code. For doing that, please file a new [issue](https://github.com/Nebraska/Nebraska/issues).
+This section has information on how to contribute to Nebraska. It assumes you have cloned
+this repository (or your own Github fork).
 
-To build the whole project (backend + frontend), you can run:
+Any contributions to the project are accepted under the terms of the project's
+license ([AGPL v3](../LICENSE)).
 
-    make
+## Code of Conduct
 
-Below you will find some introductory notes that should point you in the right direction to start playing with the Nebraska source code.
+Please refer to the Kinvolk [Code of Conduct](https://github.com/kinvolk/contribution/blob/master/CODE_OF_CONDUCT.md).
 
-## Backend
+## Development practices
 
-The Nebraska backend is written in Go. The backend source code is structured as follows:
+The Nebraska project follows the [Kinvolk Contribution Guidelines](https://github.com/kinvolk/contribution)
+which promotes good and consistent contribution practises across Kinvolk's
+projects. Before start contributing, and in addition to this section, please
+read those guidelines.
 
-- **`pkg/api`**: provides functionality to do CRUD operations on all elements found in Nebraska (applications, groups, channels, packages, etc), abstracting the rest of the components from the underlying datastore (PostgreSQL). It also controls the groups' roll-out policy logic and the instances/events registration.
+## Filing an issue or feature request
 
-- **`pkg/omaha`**: provides functionality to validate, handle, process and reply to Omaha updates and events requests received from the Omaha clients. It relies on the `api` package to get update packages, store events, or register instances when needed.
+Please use the [project's issue tracker](https://github.com/kinvolk/nebraska/issues) for filing any bugs you find or features
+you think are useful.
 
-- **`pkg/syncer`**: provides some functionality to synchronize packages available in the official Flatcar Container Linux channels, storing the references to them in your Nebraska datastore and even downloading packages payloads when configured to do so. It's basically in charge of keeping up to date your the Flatcar Container Linux application in your Nebraska installation.
+### Complex contributions
 
-- **`cmd/nebraska`**: is the main backend process, exposing the functionality described above in the different packages through its http server. It provides several http endpoints used to drive most of the functionality of the dashboard as well as handling the Omaha updates and events requests received from your servers and applications.
+If you have a complex contribution in mind (meaning changes in the architecture
+or a lot of LOC changed), it is advisable to first file a Github issue and
+discuss the implementation with the project's maintainers.
 
-- **`cmd/initdb`**: is just a helper to reset your database, and causing the migrations to be re-run. `nebraska` will apply all database migrations automatically, so this process should only be used to wipe out all your data and start from a clean state (you should probably never need it).
+## Coding style
 
-To build the backend you can run:
+The coding style for `backend` and `frontend` should be consistent.
+For helping and verifying that, we have go and js linters.
 
-    make backend
+The `backend` linter runs automatically when using the `make backend`
+command.
+For linting the `frontend`, use `make frontend-lint`.
 
-### Backend database
+The linters are also run in the CI system, so any PRs you create will be
+tested for compliance with the coding style.
 
-Nebraska uses `PostgreSQL`. You can install it locally or use the docker image available in the quay.io registry (`quay.io/flatcar/nebraska-postgres`). If you don't use the docker image provided, you'll have to set up the database yourself. By default Nebraska uses a database with the name `nebraska`, and `nebraska_tests`
-for the tests, respectively. For the main database, the full URL (with a different database name if desired) can be overridden by the environment variable
-`NEBRASKA_DB_URL`.
+To speed up a review from the project's maintainers, please make sure that
+the CI checks are passing for your PR.
 
-Note: the timezone for the Nebraska database is expected to be UTC (`set timezone = 'utc';`).
+## Commit guidelines
 
-## Frontend
-
-The frontend side of Nebraska (dashboard) is a web application built using `react` and `material-ui`.
-
-To build the webapp you have to install `node.js`. After that, you can build it using:
-
-    make frontend
-
-It is very useful to be able to quickly build the frontend while changing it during development, and for that you can use the following make target:
-
-    make frontend-watch
+For the general guidelines on making PRs/commits easier to review, please check
+out Kinvolk's
+[contribution guidelines on git](https://github.com/kinvolk/contribution/tree/master/topics/git.md).

docs/development.md

@@ -0,0 +1,67 @@
+---
+title: Development
+weight: 20
+---
+
+This section shows how to set up a development environment for Nebraska.
+Be also sure to read the [contributing](./contributing) section for the
+general guidelines when contributing to Nebraska.
+
+Nebraska needs a running `PostgresSQL` database. Apart from that, the
+recommended way to work on it, is to run the backend with the `noop`
+authentication backend, and the frontend in a "watch" mode (where it
+auto-refreshes when there are changes to the frontend).
+
+# Preparing the Database
+
+Nebraska uses the `PostgreSQL` database, and expects the used
+database to be set to the UTC timezone.
+
+By default Nebraska uses a database with the name `nebraska`, and
+`nebraska_tests` for the tests, respectively. For the main database, the full
+URL (with a different database name if desired) can be overridden by the
+environment variable `NEBRASKA_DB_URL`.
+
+For a quick setup of `PostgreSQL` for Nebraska's development, you can use
+the `postgres` container as follows:
+
+- Start `Postgres`:
+    - `docker run --rm -d --name nebraska-postgres-dev -p 5432:5432 -e POSTGRES_PASSWORD=nebraska postgres`
+
+- Create the database for Nebraska (by default it is `nebraska`):
+    - `psql postgres://postgres:nebraska@localhost:5432/postgres -c 'create database nebraska;'`
+
+- Set the timezone to Nebraska's database:
+    - `psql postgres://postgres:nebraska@localhost:5432/nebraska -c 'set timezone = "utc";'`
+
+# Development Quickstart
+
+- Go to the Nebraska project directory and run `make`
+
+- Run the backend (with the `noop` authentication): `make run-backend`
+
+- Then, in a different terminal tab/window, run the frontend: `make run-frontend`
+
+Any changes to the backend means that the `make run-backend` command should be
+run again. Changes to the frontend should be automatically re-built and the
+opened browser page should automatically refresh.
+
+# Development Concepts
+
+## Frontend
+
+The [frontend](https://github.com/kinvolk/nebraska/frontend) side of Nebraska is a web application built using `React` and `Material-UI`.
+
+## Backend
+
+The Nebraska backend is written in Go. The backend source code is structured as follows:
+
+- **`pkg/api`**: provides functionality to do CRUD operations on all elements found in Nebraska (applications, groups, channels, packages, etc), abstracting the rest of the components from the underlying datastore (PostgreSQL). It also controls the groups' roll-out policy logic and the instances/events registration.
+
+- **`pkg/omaha`**: provides functionality to validate, handle, process and reply to Omaha updates and events requests received from the Omaha clients. It relies on the `api` package to get update packages, store events, or register instances when needed.
+
+- **`pkg/syncer`**: provides some functionality to synchronize packages available in the official Flatcar Container Linux channels, storing the references to them in your Nebraska datastore and even downloading packages payloads when configured to do so. It's basically in charge of keeping up to date your the Flatcar Container Linux application in your Nebraska installation.
+
+- **`cmd/nebraska`**: is the main backend process, exposing the functionality described above in the different packages through its http server. It provides several http endpoints used to drive most of the functionality of the dashboard as well as handling the Omaha updates and events requests received from your servers and applications.
+
+- **`cmd/initdb`**: is just a helper to reset your database, and causing the migrations to be re-run. `nebraska` will apply all database migrations automatically, so this process should only be used to wipe out all your data and start from a clean state (you should probably never need it).