Django Boston


Staying Sane While Taking Over An Existing Django Codebase


Matt Makai / @mattmakai

Matt Makai


 {'name': 'Matt Makai',
  'occupation': 'Full stack developer',
  'specialties': ['Python',
                  {'Django': 'since 0.96'},
                  'data visualization',
                  'prototypes',
                  'oh crap! moments'],
  'normal_location': 'Washington, DC', 
 }

Coding Across America?

  • Road tripping 30 cities in 5 months
  • Talk with devs from all city types
  • Write about problems being solved with software
  • Connect people in different locations

March 9 - August 9

Meeting startups

Coding

Getting out of the building

Miles driven

Taking Over Existing Django Codebases

Where's this talk coming from?

  • Several recent client engagements
  • Fixes and enhancements estimation are hard
  • Trial and error
  • Where do you start?

Why should you care?

  • Evaluate potential client engagement
  • Jump into established project
  • Improve your existing codebase

Approach

  • Codebase
  • Deployment
  • Services
  • Resources

Approach

  • Codebase
  • Deployment
  • Services
  • Resources

Codebase

Determine

  • Obtain code
  • README
  • Project structure
  • Dependencies
  • Settings.py configuration
  • Data
  • Tests

Example project

Obtaining the code

It is in version control, right?

Clone repo

git clone git@github.com:makaimc/pd.git

README

  1. Purpose, goals
  2. Important links - wiki, prod, staging sites
  3. Getting started (Vagrant, virtualenv)
  4. Special instructions (Solr, db replication)
  5. Deployment

Project structure

cd pd; ls -ltra

Project structure: 1.3-



    project_root
     |- settings.py
     |- urls.py
     |- wsgi.py
     |- manage.py
     |- requirements.txt
     |- app1/
     |- app2/
     |- app3/

Project structure: 1.4+



    project_root
     |- project_name/
         |- settings.py
         |- urls.py
         |- wsgi.py
     |- manage.py
     |- requirements.txt
     |- app1/
     |- app2/
     |- app3/

Project structure: custom



    project_root
     |- settings.py
     |- urls.py
     |- wsgi.py
     |- manage.py (modified)
     |- env/
         |- requirements.txt
     |- apps/
         |- app1/
         |- app2/
         |- app3/

Dependencies

That's what we want to see

Why peg?

Settings configuration

  • settings.py
  • manage.py mangling?
  • local_settings.py.template
  • environment variables

Environment variables

Local env variable setting

Let's get up and running

  • manage.py
  • syncdb / migrate
  • test
  • runserver

Data

  • data generation scripts (.py?)
  • fixtures (.json)
  • database dump (.sql)
  • production database replication scripts

grep -r fixtures.json *.py

find . -name '*.json'

Tests

  • No tests
  • Simple tests
  • Multiple test suites
  • Custom test runners
  • Coverage reports and test checks

One tests file



    project_root
     |- app1/
        |- tests.py
        |- fixtures/fixture.json

more tests.py

No wonder the tests passed...

Multiple tests files in subdirectory



    project_root
     |- app1/
        |- tests/
            |- frontend-tests.py
            |- backend-tests.py
            |- smoke-tests.py
            |- mocked-tests.py
        |- fixtures/fixture.json

Test runner

  • Standard Django test runner
  • django-nose
  • django-jenkins
  • Custom test runner

Testing philosophy

  • Get tests running
  • Add coverage.py, if necessary
  • Figure out code coverage
  • Add tests while exploring code
  • Review increased coverage w/client or team

Review

  • Obtain code
  • README
  • Project structure
  • Dependencies
  • Settings.py configuration
  • Data
  • Tests

Deployment

Scripts

  • shell scripts
  • Fabric
  • Capistrano
  • Ansible

Documentation

  • Sphinx documentation
  • IP addresses
  • Usernames, passwords
  • Purposes of various users
  • Authentication schemes

Testing access

  • SSH
  • virtualenv
  • manage.py shell

Services

Services questions to ask

  • What services are used?
  • How are the services tested locally?
  • Who controls the user names and passwords?
  • Do the services cover full range of purposes? (debugging, user engagement, payments, etc)

Resources

Resources

?

Thank you!