Новые разработчики, присоединяющиеся к проекту, часто обнаруживают, что проект не будет полностью построен на их машине, и потратятся часы на настройку проекта, чтобы можно было начать работу. Это грустно и дорого для всех заинтересованных сторон.

Это особая угроза для агентств (или где-либо с большим количеством небольших проектов), где большая команда разработчиков должна переключаться между проектами. Такие инструменты, как Vagrant и Docker, могут помочь, но они не являются панацеей, которой они кажутся [*] .

Противостоять этому, используя непрерывную интеграцию, чтобы построить свой проект с нуля. Тогда любые изменения, которые нарушают процесс сборки (например, изменения схемы базы данных не применяются правильно), будут обнаружены раньше. Новые члены команды получат лучшие пять, когда их среда разработки будет создана и заполнена образцами данных через шестьдесят секунд после клонирования репо.

$ make

# Build a working version of the project
build: clean virtualenv database

# Delete all temporary or untracked files
clean:
    -find . -type f -name "*.pyc" -delete
    -rm -rf www/public/media/*

# Update the virtualenv
virtualenv:
    pip install -r www/deploy/requirements.txt

# Create a database populated with data
database:
    python www/manage.py reset_db --router=default --noinput
    python www/manage.py syncdb --noinput
    python www/manage.py migrate
    # Load any project fixtures to pre-populate the initial database
    python www/manage.py loaddata fixtures/*.json

test:
    cd www && py.test

ci: test database

language: python

python:
  - '2.7'

install:
  - make virtualenv

# Use the same database as used in production
before_script:
  - psql -c 'CREATE ROLE test_role login createdb superuser;' -U postgres
  - psql -c 'CREATE DATABASE test_db OWNER test_role;' -U postgres

script:
  - make ci

Джанго-специфичные проблемы

For the record, here’s some of the build issues we’ve encountered in Django projects (both internal and external) Most stem from South migrations, which worked fine when applied piecemeal by the incumbent team but fail when run on a blank database. For instance:

• Migrations fail to apply as there are dependencies between migrations which haven’t been captured. This is easily solved by employing South’s support for dependent migrations (eg adding depends_on to the relevant migration class).
• Migrations fail as they import models directly rather than using the reconstituted models that South provides. This is a beginner mistake really but still quite common. Fortunately, it’s trivial to fix.
• Migrations import and call functions that are no longer defined (but did exist when the migration was originally written).
• Migrations create instances of models from other apps where South’s serialised version is out of sync with the database schema. This can be tricky to fix as you can get circular dependencies between migrations. Often you’ll need to rewrite migrations to create models in the migrations of their own apps.

Andrew Ingram has written up an excellent summary of common South pitfalls.