The DriveBC application is composed of several Docker containers: Django backend, PostGIS database, Redis cache, and a frontend application built using React served on Node.js.
- Install Docker Desktop for your OS**
- Clone or download the project
- Setup environment variables
- Run docker-compose, 'cd DriveBC.ca && docker-compose up -d --build'
- The following should be reachable:
- Frontend: http://localhost:3000
- Backend at http://localhost:8000/, returns 404 as the root url does not serve anything
- API endpoints at http://localhost:8000/api/*/, i.e. http://localhost:8000/api/webcams/
- Django admin: http://localhost:8000/drivebc-admin/, use username/password set in .env for login
** You will need to install or update to WSL 2 on Windows (wsl --install or wsl --update)
Environments are configured via environment variables passed to Docker Compose in a .env file. Copy and rename ".env.example" into ".env" in the same directory and replace values according to your target environment.
**Variables with security implications are defaulted to production safe values. Replace or disable them accordingly to ensure that your local environment runs.
Secrets and keys:
DRIVEBC_ROUTE_PLANNER_API_AUTH_KEY
- Auth key for DriveBC Route Planner APISECRET_KEY
- Secret key for Django backend to create hashes for various security implications. Set to any value for development, or refer to .env.example on random key generation
Django:
DEBUG
** - Enable or disable Django debug mode, set to "true" for developmentDJANGO_ALLOWED_HOSTS
- Comma-separated list of strings representing the host/domain names that this Django site can serveDJANGO_CORS_ORIGIN_WHITELIST
- Comma-separated list of hosts which are trusted origins for unsafe requests i.e. POSTDJANGO_SUPERUSER_USERNAME
- Django superuser usernameDJANGO_SUPERUSER_EMAIL
- Django superuser emailDJANGO_SUPERUSER_PASSWORD
- Django superuser passwordDJANGO_CSRF_COOKIE_SECURE
** - See Django documentation, set to "false" for developmentDJANGO_SECURE_SSL_REDIRECT
** - See Django documentation, set to "false" for developmentDJANGO_SESSION_COOKIE_SECURE
** - See Django documentation, set to "false" for developmentDB_NAME
- database name for connection config in django. Use the same value as POSTGRES_DB for development.DB_USER
- database user for connection config in django. Use the same value as POSTGRES_USER for development.DB_PASSWORD
- database password for connection config in django. Use the same value as POSTGRES_PASSWORD for development.DB_HOST
** - Database hostDB_PORT
- Database host port
Postgres:
POSTGRES_DB
- Name of default database created when the PostGIS image is first started. See documentation.POSTGRES_USER
- Name of superuser created when the PostGIS image is first started. See documentation.POSTGRES_PASSWORD
- Password for the user created above. See documentation.
Redis:
REDIS_HOST
** - Redis hostREDIS_PORT
- Redis host port
Node:
NODE_ENV
- Environment for Node.JS server to build againstNODE_OPTIONS
- See Node.js documentation
** You may run into host/port conflicts with different Postgres or Redis instances if you use 'localhost' and default ports. To work around this, set the hosts to the name of the instances i.e. DB_HOST=db REDIS_HOST=redis, or use a different host port in the docker compose file i.e. "8080:5432" for postgres.
Pre-commit hooks run various code formatters and linters. Some (black, prettier) will automatically reformat your code. If you're using Visual Studio code with the recommended extensions, the pre commit hook formatting should match editor output.
- Install pre-commit (
brew install pre-commit
using homebrew) - Setup the pre-commit and commit message git hooks in the local repository:
pre-commit install --hook-type pre-commit --hook-type commit-msg
See the Backend README for details on setting up and building the backend.
See the Frontend README for details on setting up and building the frontend.
This release pipeline is designed to ensure that
- Push to Main will automatically trigger a build and release to the dev environment
- You can push to dev from a branch, by running the
1. Build & Deploy to Dev
workflow and selecting your branch
- When you are ready to release to the Test environment, run the
2. Create Tag & Build/Deploy to Test
workflow.- It will force you to give a tag number which should be in the format
project year.sprint.version
. Project inception was 2023 which was 0, so a tag would be1.26.0
for the first release of Sprint 26 in 2024. - You can also trigger it by creating a tag using the CLI as long as it starts with
v
- It will force you to give a tag number which should be in the format
- This workflow will then create the tag and automatically release it to the Test environment. It is based on the code from Main branch
- When you are ready to release to the UAT environment, run the
3. Create Tag & Build/Deploy to UAT
workflow.- It will force you to give a tag number which should be in semver format and start with
r
to indicate it's a release - You can also trigger it by creating a tag (make sure you are on the release branch) using the CLI as long as it starts with
r
- It will force you to give a tag number which should be in semver format and start with
- This workflow will then create the tag and automatically release it to the UAT environment. It is based on the tag you created.
- When you are ready to promote from UAT to Prod, we need to create a new Release in Github.
- Go to the main page https://github.com/bcgov/DriveBC.ca
- Click Releases
- Click
Create a new Release
- Choose the tag you would like to release (Should start with
r
for release) - For Previous Tag, select the tag that is currently in production
- Click
Generate Release Notes
which will create the release name and add a URL for a changelog - Click Publish Release
- This will automatically trigger the
4. Promote from UAT to Prod
workflow which will promote the UAT images to Prod