Сборка, непрерывная интеграция, развертывание в проектах на python?

Question

[apk]

Вопрос такой, какие инструменты принято и удобно использовать для сборки проектов на python, какие CI предпочитает сообщество python разработчиков, что используется для развертывания кода на серверах.
Больше интересен опыт web проектов, но буду рад примерам из других областей.

Comments

[Fak3]

что вы понимаете под «сборкой проектов на python»?

[apk]

Под сборкой имелись ввиду инструменты по типу make/rake/ant/maven при помощи которых описываются правила по которым запустились бы тесты, проверился код на стандарты, подставились нужные значения в конфигурационных файлах и т.п.

Answer 1

[bobry]

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

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

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

Answer 2

[Fak3]

Для развертывания своих 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)

Comments

[bobry]

А как с базами обходитесь? если используете версии схемы, то как проводите миграции (в смысле делаете ли автоматический backup, и откат на старую версию в случае неудачи)?

[Fak3]

Для django управлять версиями схемы БД можно с помощью south. Если изменилась схема после очередного git pull — произносятся два заклинания в консоли
./manage.py schemamigration <app_name> --auto
./manage.py migrate <app_name>

если что-то не так — можно откатиться
./manage.py migrate <app_name> --list # посмотреть как называется стабильная версия
./manage.py migrate <app_name>

[bobry]

Увы south оперирует только миграциями, а не наборами миграция — т.е. если между релизами у вас накопилось 10 миграций, и ./manage.py migrate поломался на 8й, то south не откатится на 7 миграций назад.

[Fak3]

у меня ошибка в предыдущем комменте — последняя строчка
./manage.py migrate <app_name>
@bobry: не понял, а что мешает откатиться на 7 миграций назад?

[Fak3]

ох. хабр не хочет показывать «version» в угловых скобках… к чему бы это?
./manage.py migrate <app_name> version

[bobry]

Я бы хотел чтобы это проходило в автоматическом режиме, ручками то откатить ничего не мешает.

[Павел Загребелин]

зачем делать schemamigration после pull, если можно коммитить и файлы миграции?

[Fak3]

Ну да, если хранить в VCS и файлы миграции, то schemamigration делается не на продакшн-сервере, а в другом месте.
Это немного удобней, но когда миграций накопится очень много их надо наверное чистить, и south начнет возмущаться про удаленные файлы миграций.

[bobry]

Я думал наличие миграций в репозитории подразумевается; генерация миграций на сервере во-первых не подразумевает использование datamigrations, а во-вторых просто опасная штука — мало ли чего там south думает про вашу схему.

Answer 3

[Евгений]

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

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

Answer 4

[Maxim Avanov]

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).

Answer 5

[shsmad]

git/hg/svn?

Comments

[shsmad]

по крайней мере часто используется система контроля версий + самописные скрипты для крона, которые деплоят

[apk]

да про системы контроля версий все понятно, bazzar еще для python проектов популярен. вопрос не в том

[shsmad]

а как таковых систем CI промышленного масштаба вроде и нет :(

[shsmad]

а вот вспомнил, у нас для не-web проектов вообще система ebuild-ов развернута.

Answer 6

[Vas3K]

В качестве CVS использую git, для быстрого развертывания на боевой сервер — небольшой скрипт с вызовом rsync. Вроде вся магия.