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

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

Спонсоры Информационные спонсоры Сайт конференции

Почему разработчики плачут? 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 модификация для D6 by mukesh.agarwal17 development-staging-and-production-sites-databases- drupal-6 drush скрипты для drush от Данила Семеленова Подробнее про Migraine 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: @prod, реквизиты доступа (см. drush/examples/example.aliases.drushrc.php) 3.settings.php для индивидуальных настроек внутри /sites/xxxx

Migraine: workflow Разработчик 1 1.Работаем над кодом и конфигурацией 2.Делаем дамп migrate-db-dump (можно повесить на pre- commit hook для git) o возможно, занесение новых таблиц в tables.py или tables.php 3.commit, push Разработчик 2 1.pull (возможно, разрешаем конфликты) 2.Делаем migrate-db-restore 3.Изменения в конфигурации мигрировали

Migraine: workflow migrate-db-dump 3.миграция БД migrate-db-dump –миграция БД (кроме содержимого контентных таблиц) 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.pull 2.Установка/Обновление из кода 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.inc 4.drush en feature_name 5.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 all hook_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

Контакты Анна Федорук

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

Спонсоры Информационные спонсоры Сайт конференции