Files
web2.0-backend/readme.md
T
Jan Tuomi bd94ab8e33 Write some stuff in the readme
Also make a package.json for npm deps
2017-05-21 22:56:28 +03:00

152 lines
3.4 KiB
Markdown

# SIKWEB 2.0
A modern web app using a Django backend and an Angular frontend.
## Components
### Infoscreen
Angular-based slideshow app for the guild room's screens.
### Member register
Data table app for viewing and modifying the member register, member applications and membership payments.
### Web app
Mostly static website with an event calendar.
## Accessing the source
### Clone this repository and enter it
Set up your SSH key authentication in GitLab Profile Settings. Then clone the repository and checkout the development branch:
```
git clone git@sika.sahkoinsinoorikilta.fi:vtmk/web2.0.git
cd web2.0
git checkout develop
```
## Install dependencies
### Dependency list
* Python >3.5
* PostgreSQL >9.5
* pip3
* virtualenv
* npm
Install with apt:
```
sudo apt install python3
sudo apt install python3-pip
sudo apt install postgresql
sudo pip3 install virtualenv
sudo apt install npm
```
More info about PostgreSQL at:
https://www.postgresql.org/
These packages might be needed on certain platforms:
* python3-dev
* libffi-dev
* python3-cffi
* libssl-dev
## Create a virtual environment for python
Create a virtualenv in the parent directory.
```
virtualenv -p python3 ../virtualenv.sikweb
```
## Activate virtualenv
Assuming we are at the root of this repository and virtualenv is one level above.
```
. ../virtualenv.sikweb/bin/activate
```
## Run install wizard
Run the install wizard with
```
bash setup.sh
```
and follow the instructions.
## Running
### Use runserver command
```
python manage.py runserver 0.0.0.0:8000
```
Using address 0.0.0.0 will bind to all IP addresses.
### Visit the page
Visit https://localhost:8000 in your browser!
## Development workflow
When pulling changes from the server, use `rebase` instead of `merge` for a nice and clean linear history.
Example of pulling with rebase:
```
git pull --rebase
```
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:
```
git checkout -b feature-error-page
```
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 `pep8` with
```
pep8 --config=setup.cfg --count .
```
Lint javascript using `eslint` with
```
eslint .
```
Use an editor with linting capabilities to write pretty code that passes linting. Examples include _Atom_ and _Pycharm_.
### Unit tests
Run unit tests with
```
python manage.py test -v 2
```
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.
### 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`.