pixelpassion / django-saas-boilerplate

A Django + django-rest-framework + Heroku + SaaS application boilerplate
MIT License
51 stars 10 forks source link

pixelpassion.io

πŸ₯œ django-saas-boilerplate

A boilerplate to get started with Django, django-rest-framework on Heroku. It is great to start a API-first SaaS-application.

Deploy

Features

Layout

django-rest-boilerplate
β”œβ”€β”€ .circleci                           // CircleCI configuration
|   β”œβ”€β”€ config.yml  
β”œβ”€β”€ .github  
|   β”œβ”€β”€ ISSUE_TEMPLATE  
|   |   β”œβ”€β”€ bug---problem.md            // A Github template for reporting bugs
|   |   └── feature_request.md          // A Github template for posting new features
|   β”œβ”€β”€ PULL_REQUEST_TEMPLATE.md        // A Github template layout for Pull requests
β”œβ”€β”€ apps  
|   β”œβ”€β”€ core                            // Django core app
|   β”œβ”€β”€ users                           // Django Users app
β”œβ”€β”€ conf                                // Django configuration folder
|   β”œβ”€β”€ urls.py                         // The main url.py file
|   β”œβ”€β”€ wsgi.py                         // The WSGI handler
|   β”œβ”€β”€ settings                        // Django settings
|   |   β”œβ”€β”€ base.py                     // General settings
|   |   β”œβ”€β”€ local.py                    // Local settings
|   |   β”œβ”€β”€ production.py               // Production settings
|   |   β”œβ”€β”€ test.py                     // Test settings
β”œβ”€β”€ devops                              // Devops + Infastructure
|   β”œβ”€β”€ Docker                          // Docker container
|   |   β”œβ”€β”€ postgres                    // Postgres Docker
|   |   β”œβ”€β”€ redis                       // Redis Docker
β”œβ”€β”€ .coveragerc  
β”œβ”€β”€ .env.example                        // Copy to .env for local development  
β”œβ”€β”€ .gitignore                          // Default .gitignore  
β”œβ”€β”€ .pre-commit-config.yaml  
β”œβ”€β”€ .prospector.yaml  
β”œβ”€β”€ LICENSE  
β”œβ”€β”€ Pipfile                             // Pipenv file  
β”œβ”€β”€ Pipfile.lock                        // Pipenv lock file  
β”œβ”€β”€ Procfile                            // Declaration of Heroku processes  
β”œβ”€β”€ README.md  
β”œβ”€β”€ app.json                            // For automated Heroku deployment  
β”œβ”€β”€ conftest.py  
β”œβ”€β”€ docker-compose.yml                  // Docker handling for local development  
β”œβ”€β”€ manage.py  
β”œβ”€β”€ pytest.ini  
β”œβ”€β”€ runtime.txt                         // Python version for Heroku deployment  
β”œβ”€β”€ setup.cfg  
β”œβ”€β”€ tasks.py  

Documentation

Read our documentation at ..

Local setup

Download & install the Docker Community edition

Run the following commands, it will build & start the needed containers (Django, Worker, Postgres DB, Redis, Mailhog):

pipenv install --dev
docker-compose up -d
./manage.py migrate
./manage.py runserver

Open your browser and go to http://localhost:8000/

Deployment

You can deploy project to Heroku using Deploy button or Heroku instructions https://devcenter.heroku.com/categories/working-with-django

Environment variables required to deploy project

Name What is it? Default
DATABASE_URL Database's url postgresql://${DB_USER}:${DB_PASSWORD}@localhost:${DOCKER_POSTGRES_PORT}/postgres for local, Heroku sets it automatically
REDIS_URL Redis's url redis://redis:${DOCKER_REDIS_PORT} for local, Heroku sets it automatically
ENV App's environment
SECRET_KEY Secret key that django requires for security Heroku sets it automatically

All other envs you can find in env.example

Install & Run Locally

This project contains docker integration. You can run it with pipenv run go-docker.

In any case before you need to write your .env file with correct variables: when using the dockerized local development setup, copy .env.local; otherwise copy .env.example to .env, and modifiy accordingly.

Add git hooks

We are using prospectr + pre-commit to make things workable and clear. Before write any code you need to install dev dependencies and run pre-commit install -f after that. Then whenever you run git commit you'll have a fancy output with checks according to our code standards.

Prepare a new branch for your work

Work on new bug/features will be done in a new branch (*) There is a convention in the name of the branches used: 1-short-description-of-purpose

Naming a Branch:

Make awesome commits

Commits are the smallest portion of code that can be reviewed and has a purpose in the codebase. Each commit counts in a branch, not only the full set of changes.

Please follow this guideline: https://udacity.github.io/git-styleguide/

To use cool github linking to the issue please add #taskNumber in the end. E.g.:

docs: add changes to the Readme #123

Documentation

Please make sure that each public class, method and function has meaningful documentation which describes the purpose of the code. To make things easier to follow we use Python annotations to the public functions and method. Cheat sheet: https://mypy.readthedocs.io/en/latest/cheat_sheet_py3.html

More info here: https://docs.python.org/3/library/typing.html