Автоматизация управления релизами, структурирование проекта Django

01.07.2009 15:18 | 1 комментарий | 0 пингбэков | Django, управление проектом

Наверное одно из самых важных в эффективной работе непосредственно над реализацией задуманного проекта — структурирование данных и файлов.

Разработчик интуитивно понимает нахождение и функцию того или иного модуля проекта. Уменьшается порог вхождения для стороннего разработчика.
Системный администратор может следить за изменениями версии проекта и с легкостью обновлять код на тестовых и боевых серверах вручную или автоматическими средствами.

В своих проектах я использую следующую структуру, частично позаимствованную у проекта Twisted

. (корень проекта)

burus$ ls -l1 .
__init__.py
admin
config
init_db.mysql
manage.py
patch-х.х.х.mysql
patch-after-first-install.mysql
src
topfiles

ADMIN

Скрипты для разработчика проекта, в частности скрипт cpyrght и release.

/admin/cpyrght — позволяет добавлять строчку о авторском праве в исходный файл

/admin/release — скрипт автоматизации создания тэгов и релизов проекта

burus$ ./admin/release
Django project auto release tool usage:

$ release options

    options:
        -c comment, --commit-changes=comment : Commit latests changes,
                                           edit CHANGELOG and VERSION files
        -t, --tag                            : Make TAG from current repository version
        -r, --release                        : Make TAG and TALLBAR from current repository
                                           version
        -h, --help                           : Print usage help

CONFIG

Директория с файлами настройки проекта системным администратором.

burus$ ls -l1 config/
__init__.py
includes
settings.py

includes содержит различные HTML шаблоны, в которых могут изменять контент без ведома программиста. Например это блоки рекламы, шапка, нижний блок сайта и т.п.
settings.py — параметры и переменные для настройки системы, программист должен отделить скрытые параметры системы от переменных для настройки приложения в боевых/тестовых условия. Публичные или скорее защищенные параметры. Это нужно чтобы не злить администратора кучей бесполезного для него кода и условными обозначениями, ведь у него может быть множество подотчетных проектов на разных языках и платформах. Без фанатизма =).

Пример config/settings.py

burus$ cat config/settings.py
DEBUG = True # turn off for the perfomance in the production server

DOMAIN = 'django.local.lh'
STATIC_URL = 'static.local.lh'

CACHE_BACKEND = 'memcached://127.0.0.1:11211/'
CACHE_TIMEOUT = 1*60 # seconds

PROJECT_ADMINS = ('support@domain.com',)

DATABASE_ENGINE = 'mysql'    # 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
DATABASE_NAME = 'django-example'      # Or path to database file if using sqlite3.
DATABASE_USER = 'django'             # Not used with sqlite3.
DATABASE_PASSWORD = '***'         # Not used with sqlite3.
DATABASE_HOST = '127.0.0.1'             # Set to empty string for localhost. Not used with sqlite3.
DATABASE_PORT = ''             # Set to empty string for default. Not used with sqlite3.

Скрипты xSQL

В корне проекта есть скрипты для установки иили модификации базы данных. Постфикс файла устанавливается в зависимости от используемой базы данных, чтобы проект можно было адаптировать к любой базе без особых усилий, не вспоминая что изменялось под тот или иной движок.

init_db.mysql — скрипт создания базы данных.
patch-х.х.х.mysql — патч базы с учетом версии релизв в котором изменения вступают в силу.
patch-after-first-install.mysql — патч на базу, который применяется сразу после запуска ./manage.py syncdb в первый раз. Бывают проекты в которых сразу же нужно добавить в базу свои UNIQUE INDEX для генерации Exception и/или PL/SQL процедуры.

После использования патча и перехода на новую версию, старый патч удаляется вручную. На самом деле он остается в системе контроля версии (svn, cvs, mercurial, etc…), а в новой версии ПО в нем обычно уже нет необходимости.

SRC

В этой директории исходный код, который обновляется программистом от версии к версии. Код изолируется для того чтобы облегчить управление проектом и предостеречь путаницу с файлами конфигурации. Стандартный набор директории по умолчанию:

burus$ ls -l1 src/
__init__.py
_version.py
app
lib
settings.py
templates
urls.py

_version.py — создается автоматически в ходе использования скрипта /admin/release
app — одно из наших приложений с собственным urls.py, models.py, view.py, admin.py, forms.py и т.д.
lib — библиотека общих утилит, декораторов и всяких вкусностей для нашего проекта. В этой директории хранится скрипт для управления версией проекта и обновления списка changelog. (decorators.py, version.py)
settings.py — классический файл конфигурации проекта
templates — директория для хранения шаблонов наших приложений и общих шаблонов проекта.
urls.py — файл для управление первичным распределением URI между приложениями.

TOPFILES

Это временная директория для хранения информационных файлов, которые редактирую вручную или автоматически, при помощи /admin/release.

burus$ ls -l1 topfiles/
CHANGELOG
CHECKLIST
INSTALL
LICENSE
README
VERSION
init.d
setup.py

Большинство этих файлов будут находиться в корне проекта после создания tallbar релиза и не требуют комментариев. init.d — скрипт автозапуска приложения, после инсталляции перекочует в /etc/init.d/projet_name, где имя присваивается автоматически по названию проекта(директории). CHECKLIST — краткое пособие для black box тестирования.

Заключение

Данный подход позволяет значительно сократить время на сборку и модификацию релиза проекта.
Changelog сохраняется один к одному по комментариям в commit операции. Комментарии рекомендую делать в виде идентификаторов задач в системе Trac, JIRA и т.п.. Такой подход увеличит срок ващей жизни пощадив нервы, когда вам придется быстро откатиться на старую версию и/или найти разницу в коде связанную с определенной задачей.
Удобно критиковать код и ход выполнения проекта.
commit нужно делать через скрипт /admin/release, чтобы сохранялись логи изменения кода в src/_version.py.
Когда вы делаете тэг проекта “/admin/release -t”, автоматически обновляются файлы VERSION, CHANGELOG, _version.py и создается тэг в ветке репозитория tags/x.x.x.

Скачать

Примеры исходного кода можно скачать и посмотреть тут dajngo auto release example или сразу тут

hg clone https://django-auto-release-example.googlecode.com/hg/ django-auto-release-example

Надеюсь мой опыт пригодится вам. На данном этапе не работает setup.py и авто tallbar, нет универсализации под mercurial, но в ближайшее время я обновлю код и сделаю первый его релиз для публичного использования. Не хочу слушать про EGG и “блага” от Zope3 =).

Добавить пост в: