Ojakoo
154 lines
4.6 KiB
Markdown
154 lines
4.6 KiB
Markdown
# Web 2.0 Backend
|
|
|
|
[Django](https://www.djangoproject.com/) backend containing multiple small applications and api for Next.js frontend.
|
|
|
|
* **Web app:** Backend for the main website.
|
|
* **Member register:** Data table app for viewing and modifying the member register, member applications and membership payments.
|
|
* **Kaehmy:** Form for creating and listing kaehmys
|
|
* **Ohlhafv:** Form for creating and listing ohlhafv challenges.
|
|
* **Infoscreen:** Angular-based slideshow app for the guild room's screens.
|
|
## Installation
|
|
|
|
Set up your SSH key authentication in GitLab Profile Settings. Then clone the repository and checkout the development branch:
|
|
|
|
```bash
|
|
git clone git@gitlab.com:sahkoinsinoorikilta/vtmk/web2.0-backend.git
|
|
cd web2.0-backend
|
|
git checkout develop
|
|
```
|
|
|
|
Copy env file for local use:
|
|
```bash
|
|
cp .env.dev .env
|
|
```
|
|
|
|
### Poetry
|
|
|
|
For depedencies and virtual environment, we use [poetry](https://python-poetry.org/).
|
|
|
|
First install [python](https://wiki.python.org/moin/BeginnersGuide/Download). Then install poetry:
|
|
|
|
```bash
|
|
python3 -m pip install poetry
|
|
```
|
|
|
|
The easiest integration with VSCode is to have poetry install virtual environment in project folder, configured with CMD
|
|
|
|
```bash
|
|
python3 -m poetry config virtualenvs.in-project true
|
|
```
|
|
|
|
### Node
|
|
|
|
We use Node.js for few development tasks, like linting. Easiest way to install Node is [nvm](https://github.com/nvm-sh/nvm). After installing install dependencies:
|
|
|
|
```
|
|
npm install
|
|
```
|
|
|
|
TODO: List scripts
|
|
|
|
### Database
|
|
|
|
To run a local development database **[docker](https://docs.docker.com/engine/install/)** is recommended. If you want to additianally use a db management tool **[pgAdmin](https://www.pgadmin.org/download/)** is nice.
|
|
|
|
After installing docker use the following to create a database:
|
|
```bash
|
|
docker run --name postgres:12 -e POSTGRES_PASSWORD=postgres -p 5432:5432 -d postgres:12
|
|
```
|
|
|
|
## Development
|
|
|
|
Activate virtual environment in shell
|
|
|
|
```bash
|
|
python3 -m poetry shell
|
|
```
|
|
|
|
Install dependencies
|
|
|
|
```bash
|
|
poetry install
|
|
```
|
|
|
|
### Initializing data
|
|
|
|
Run the following `manage.py` commands to initialize a new database. Do not run these in production without thinking!
|
|
|
|
```bash
|
|
python manage.py migrate # run migrations
|
|
python manage.py createdefaultadmin # creates an admin user
|
|
python manage.py initialize # creates user groups
|
|
python manage.py createdummydata # creates dummy members to the member register
|
|
```
|
|
|
|
### Running
|
|
|
|
```bash
|
|
python manage.py runserver
|
|
```
|
|
|
|
Visit [https://localhost:8000](https://localhost:8000) in your browser!
|
|
|
|
Using address `0.0.0.0` will bind to all IP addresses. Using `localhost` will only bind to your machine.
|
|
|
|
```bash
|
|
python manage.py runserver 0.0.0.0:8000
|
|
```
|
|
|
|
### Development workflow
|
|
|
|
When you start working on a feature, create a feature branch for your changes. These feature branches should be prefixed with `feature`.
|
|
|
|
Example of creating a feature branch:
|
|
|
|
```bash
|
|
git checkout -b feature-branch-name
|
|
```
|
|
|
|
When your changes are ready and the code works without errors, submit a merge request to `develop` in GitLab. Another developer reviews your changes and runs the merge. Feature branches should be closed on merge.
|
|
|
|
Bugfixes do not need their own feature branches and can be pushed straight to `develop`, but if the fix needs a notable amount of work, it should be done in a `bugfix` branch instead.
|
|
|
|
Merge requests to `master` should be reviewed by multiple developers. Only a moderator can accept merge requests to `master`.
|
|
|
|
### Linting
|
|
|
|
Lint python files using `black` with
|
|
|
|
```bash
|
|
npm run lint:py # check changes
|
|
npm run lint:py:fix # fix errors
|
|
```
|
|
|
|
Lint javascript and markdown using `eslint` and `remark` with
|
|
|
|
```bash
|
|
npm run lint:md # markdown
|
|
npm run lint:js # javascript
|
|
```
|
|
|
|
Use an editor with linting capabilities to write pretty code that passes linting. Examples include _VSCode_, _Atom_ and _Pycharm_.
|
|
|
|
### Unit tests
|
|
|
|
Run unit tests with
|
|
|
|
```bash
|
|
python manage.py test
|
|
```
|
|
|
|
Due to the mostly static nature of the project, most elements are difficult to properly unit test. If you write code with actual logic, make sure to write at least one unit or integration test that tests your code's core functionality.
|
|
|
|
Tests are located in `tests.py` under every subproject.
|
|
|
|
## Production
|
|
|
|
Project is run in production with Docker. See `Dockerfile` for details.
|
|
|
|
For more information about deployment check **[infra](https://gitlab.com/sahkoinsinoorikilta/vtmk/infra)** repository.
|
|
|
|
## GitLab CI
|
|
|
|
All pushed changes go through the GitLab Continuous Integration, which consists of automated unit testing and linting. Make sure your changes pass both before merging to `develop` or `master`.
|