Buzzdetect development documentation¶
Development as we do it consists of several phases: unit testing, local testing, documentation and deployment. This chapter describes how to proceed with these different phases of development.
Building this documentation¶
Install Sphinx and run make html
in the docs/
directory of the
project’s repository.
Install for development¶
While it’s perfectly feasible to build a virtualenv manually for development purposes, it’s also possible to use the development server with docker.
Step 0: Install and run Postgres, Redis and Buzzdetect Dockers¶
Command for postgres:
docker run -d --name pg -e POSTGRES_PASSWORD=postgres postgres
Command for Redis:
docker run -d --name redis redis
Step 1: Configure Postgres, launch with bash and create a base¶
Command to create a database named buzzdetect in the container:
docker exec -it pg su postgres -c "createdb -E UTF-8 buzzdetect"
Step 2: Migrate database¶
Command to execute new schema migrations:
docker exec bdWeb buzzdetect migrate
Step 3: Launch Buzzdetect web interface¶
Command to run the web interface in docker:
docker run -d \
--name bdWeb \
--link redis \
--link pg \
-e DEBUG=1 \
-e POSTGRES_HOST=pg \
-e POSTGRES_USER=postgres \
-e POSTGRES_PASSWORD=postgres \
-e REDIS_URL=redis://redis:6379/0 \
--publish 8000:8000 \
bd buzzdetect runserver 0:8000
SOCIAL_AUTH_* and API_KEY settings are optional for development, but necessary for buzzdetect to operate fully which ie. facebook posts monitoring services.
Running tests¶
The gitlab-ci-multi-runner
command allows to run jobs defined in
.gitlab-ci.yml
like the ci server would:
gitlab-ci-multi-runner exec docker test
It in turn runs tox, so you can run tox directly without docker too unless you’re trying to debug a test that passes locally but not on the CI server, which should be rare.