Drupal организация разработки

Генеральный спонсор и организатор конференции DrupalConf 2011

При поддержке:

Спонсоры

Информационные спонсоры

Сайт конференции

Drupal: организация  разработки

Почему разработчики плачут?

Drupal клевый: • гибкость• настраиваемость• собираем из функциональных блоков что угодно• мощь инструментов Views, CCK, Rules и т.д.

 В чем же проблема?

Почему разработчики плачут?

OMG, настройки в БД: • Включенные модули и их настройки • Блоки, словари, типы контента CCK• Роли пользователей, настройки прав• настройки Views, Rules и др.

 Возникновение ошибок и трата времени:• миграция изменений с сервера на сервер• миграция изменений между разработчиками

Простой workflow

1. Несколько разработчиков, каждый работает на своем локальном сервере: нужно делиться изменениями

2. Тестовый сервер: нужно переносить настройки и контент3. Боевой сервер: нужно переносить настройки, сохраняя

контент 

Что делать?

Что нам нужно:• отслеживать изменения в конфигурации• переносить изменения в конфигурации

Подходы:• работать с миграциями изменений в БД• настройки - в код (code-driven development): экосистема

Features

Drush: лучший друг разработчика

• cc - очистка кэша• dl, en, dis - работа с модулями • sql-dump, sql-sync - работа с дампами БД• rsync - синхронизация файлов• remote-backup, remote-restore - бэкапы

Migraine: наш опыт

• Migraine by Noosphere Networks http://ashearer.com/software/server-administration/migraine 

• модификация для D6 by mukesh.agarwal17 http://www.blisstering.com/migraine-synchronize-your-development-staging-and-production-sites-databases-drupal-6

• drush• скрипты для drush от Данила Семеленова

 Подробнее про Migraine• http://www.slideshare.net/drupalindia/migraine-drupal-

syncing-your-staging-and-live-sites-presentation

Что делает Migraine

Migraine: разделение таблиц• config_tables: blocks blocks_roles boxes, filters

filter_formats, imagecache_action, imagecache_preset...• content_tables*: node, node_revisions, search_dataset,

search_index, term_data, term_node... • temp_tables: accesslog, watchdog...• cache_tables: cache, cache_block, cache_filter,

cache_menu, cache_page, cache_views...• ignore_tables: ...

_______________________________________________* - все таблицы content_type_* и content_field_* определяются как контентные автоматически

Расширения Drush

Оболочка для команд Migraine

1. migrate-db-dump — создание дампа локальной БД 2. migrate-db-restore — восстановление БД из локального

дампа3. migrate - полная миграция сайта, включая исходные

файлы и БД4. sync - cинхронизация файлов локальной версии сайта с

удаленной.

Что еще нужно подготовить

1. /sites/xxxx для всех площадок2. aliases.drushrc.php: алиасы площадок @dev, @test,

@prod, реквизиты доступа (см. drush/examples/example.aliases.drushrc.php)

3. settings.php для индивидуальных настроек внутри /sites/xxxx

Migraine: workflow

Разработчик 11. Работаем над кодом и конфигурацией 2. Делаем дамп migrate-db-dump (можно повесить на pre-

commit hook для git)o  возможно, занесение новых таблиц в tables.py или

tables.php3. commit, push

 Разработчик 21. pull (возможно, разрешаем конфликты)2. Делаем migrate-db-restore3. Изменения в конфигурации мигрировали

Migraine: workflow

drush @dev migrate @test:1. drush @dev migrate-db-dump2. drush @dev sync @test3. миграция БД

 drush @dev migrate @prod:– drush @dev migrate-db-dump– drush @dev sync @prod– миграция БД (кроме содержимого контентных таблиц)

1. (возможно) изменение схемы контентных таблиц (при изменении типов данных через CCK)

Migraine: плюсы и минусы

Хорошо:• таблицы классифицированы - больше думать не надо• нет зависимости от предоставления модулями каких-то

интерфейсов для экспорта-импорта  Плохо:• в случае конфликтов разбираться в дампах тяжело,

легко ошибиться• каша остается кашей• все равно приходится думать

Features

Code-driven development!

Конфигурация - в код! 

Features так или иначе умеют: типы нод, поля CCK,

таксономия, imagecahe, роли и права, Views, Rules...

Features: экосистема

• Features • Ctools exportables• Strongarm - переменные • Boxes - кастомные блоки (альтернатива стандартному

add block) • Context - блоки, breadcrumbs и т.д. • Diff - инструмент для работы с различиями в состояниях

feature

Анатомия feature

feature - это модуль• feature_name.info - мета-информация, зависимости• feature_name.module - место для кастомного кода• feature_name.features.inc • feature_name.install

 Фрагменты конфигурации:

• feature_name.context.inc • feature_name.features.content.inc• feature_name.views_default.inc• feature_name.features.user_permission.inc• ...

Возможные состояния feature

Features сравнивает для feature: • состояние кода (1)• предыдущее состояние кода (2)• актуальное состояние (обычно в БД) (3)

 В зависимости от разницы между ними:• Default: (1) == (3) или (3) не существует, для обновления

feature достаточно обновления кода• Overridden: (1)!=(3), для обновления feature нужно

сделать revert •  Needs review: (1)!=(2)!=(3), для обновления нужно

разбираться вручную• Rebuildable (для faux-exportables): (1)!=(3), (3)==(2)

Workflow отдельно взятой feature

Разработчик 1 1. Создание2. Включение3. Работа по изменению конфигурации4. Обновление кода5. commit, push

 Разработчик 2 1. pull2. Установка/Обновление из кода3. Конфигурация перенесена!

Управление Features

• Веб-интерфейс• Drush

• drush features (fl) - список всех доступных feature• drush features-export (fe) [feature name] [component list]

- создание новой feature с указанными компонентами• drush features-update (fu) [feature name] - из БД в код• drush features-revert (fr) [feature name] - из кода в БД• drush features-diff (fd) [feature name] - различия между

состоянием в кодe и в БД

Feature: без UI

Создание 1. feature_name.info: мета-информаци, зависимости и т.д.2. feature_name.module:

include_once('feature_name.features.inc');3. feature_name.features.inc4. drush en feature_name5. drush fu feature_name

Добавление чего-нибудь1. Добавляем зависимость в .info (например: features[views]

[] = "view_news")2. drush fu feature_name

Подумаем о других

Изменения не сводятся только к конфигурации. Но feature - модуль, поэтому есть hook_install() и hook_update(). • включение модулей• добавление ролей• добавление словарей• любой код• ...

hook_update() - делимся с теми, кто работает параллельноdrush updatedb -y && drush cc allhook_install() - делимся с новыми разработчиками

Controller Feature: центр управления всем остальнымВключаются все остальные features:dependencies[] = "feature_name_1"dependencies[] = "feature_name_2"... hook_update и hook_install - отражают общие изменения в состоянии системыfunction feature_controller_update_6003() {$return = array();$modules = array('feature_name_1', 'feature_name_2');drupal_install_modules($modules);$return[] = array('success' => TRUE, 'query' => 'Enabling some cool features');return $return;}

Features: собираем все вместе

1. project.profile: включаем необходимые модули и Controller Feature

2. Работаем: пишем код, добавляем модули, меняем структуру и настройки, разрабатываем и подключаем новые features.

3. Поддерживаем актуальность .install Controller Feature (пишем код вручную).

4. Поддерживаем актуальность кода остальных features (drush fu feature_name)

5. Вся история в репозитории в виде кода!

Features

Хорошо:• с кодом легко работать в системе контроля версий• законченные куски функционала, которые можно

использовать повторно• красиво

  Плохо: • требует больше внимания к вынесению изменений в

код • на самом деле сложно правильно разделить на куски из-

за зависимостей• не все компоненты exportable (решаемо)

Credits

• http://nuvole.org/blog/code-driven-development• http://developmentseed.org/blog

Контакты

Анна Федорук [email protected] http://devteam.sterno.ru/@sternodevteam

Генеральный спонсор и организатор конференции DrupalConf 2011

При поддержке:

Спонсоры

Информационные спонсоры

Сайт конференции