apk

hg -> project tree with a solid YAML-based configuration -> python-doit tasks -> nose tests -> packaging (python-doit) -> fabric deployment -> version update && data migration (python-doit).

Для «сборки» использую buildout. По сравнению с virtualenv приходится меньше действий делать руками, все более-менее стандартизировано.

Для CI пока не использую ничего. :( Запускаю тесты руками перед push'ем в репозиторий.

Для развертывания своих web-проектов на сервер используют virtualenv и pip. Зависимости обычно перечислены в файлике в формате pip.
при этом разворачиваие проекта сводится к набору команд:
svn\git clone to <proj_dir>
virtualenv <env_dir>
source <env_dir>/bin/activate
pip install -r <proj_dir>/requrements.pip

Код, запускающий проект на боевом сервере должен при этом учитывать наличие виртуального окружения. Если использовать апач и wsgi — тут описано, как должен выглядеть скрипт

Зачем все эти пляски с virtualenv?
Это все нужно, чтобы на одном и том же сервере спокойно работали несколько проектов с различными версиями зависимых программ. (например у каждого проекта может быть своя версия django)

CI для питона тема больная, ибо все более менее серьзеные решения написаны на Java и ориентированы соответственно на Java-разработку. Мы используем Bamboo, просто потому что он интегрируется с JIRA, но ничего готового (например установки зависимостей через pip) у него для питона нет.

Что касается развертывания проектов, то тут есть варианты, в зависимости от ваших религиозных убеждений:
1. <3 Ruby? — chef или puppet — бонусом получите пачку готовых решений на все случаи жизни, например создание баз в постгресе или установка зависимостей через apt
2. Fabric

Для последнего товарищи из ffunction пилят некий аналог chef'a под названием cuisine, хотя до удобства использования там еще ой как далеко.