Я работаю над своим первым проектом Drupal на XAMPP в своем MacBook. Это прототип и получает положительные отзывы от моего клиента.
Я собираюсь развернуть проект на Linux VPS две недели спустя. Есть ли лучший способ, чем "переделать все на сервере с нуля?"
Спасибо
Несколько советов:
Используйте источник управления, а не FTP/и т.д., для файлов. Неважно, что вы используете; мы склонны разворачивать учетную запись subversion Unfuddle.com для каждого клиента, чтобы у них было место для регистрации ошибок, но критический первый шаг - получить полное исходное дерево вашего сайта в управление версиями. Когда изменения производятся на сервере тестирования или промежуточном сервере, вы видите, работают ли они, вы фиксируете, а затем обновляетесь на реальном сервере. Откат и развертывание много, проще. Для кластеров нескольких веб-узлов вы можете повторить процесс или rsync с одного "канонического" сервера.
Если вы используете SVN, вы также можете использовать CVS-проверки Drupal и других модулей/тем, и метаданные SVN/CVS будут счастливы жить рядом друг с другом.
Для громоздких папок, таких как каталог файлов, используйте символическую ссылку в "правильном" местоположении, чтобы указать на серверную директорию за пределами webroot. Это позволяет вашему репозиторию управления версиями включать весь код и символическую ссылку, а не весь код и все файлы, которые пользователи загрузили.
Базы данных сложнее; очистка базы данных dev/промежуточной базы данных и ее перенос на живое является самым простым для первоначального развертывания, но при выполнении инкрементных обновлений БД есть несколько морщин, если пользователи на реальном сайте также генерируют контент.
В прошлом году я сделал презентацию лучших практик внедрения Drupal. Не стесняйтесь проверять слайды.
Features.module - чрезвычайно мощный инструмент для управления изменениями конфигурации Drupal.
Типы контента, параметры CCK, представления, переменные Drupal, контексты, предустановки Imagecache, меню, таксономии и разрешения могут быть включены в функцию, которая может быть проверена в контроле версий. Оттуда, развертывание нового сайта или нажатие изменений на существующий легко управляется с помощью пользовательского интерфейса функций или Drush.
Убедитесь, что вы установили Strongarm.module для экспорта конфигурации drupal, которая хранится в вашей таблице переменных. Вы можете также статический контент/узлы (то есть: о нас, faqs и т.д.) В "Возможности", установив uuid_features.module.
Руки вниз, это лучший способ работать с другими разработчиками на том же сайте и перемещать ваш сайт от разработки до тестирования на стадию и производство.
Мы провели обширную дискуссию об этом на моем рабочем месте, и то, как мы, наконец, остановились, заключалось в том, что он продвигал обновления кода (включая модули и темы) от разработки до постановки на производство. Мы используем Subversion для этого, и он хорошо работает до сих пор.
Что особенно важно, так это то, что вы автоматизируете процесс отталкивания базы данных от производства, чтобы ваши разработчики могли хранить свои копии базы данных как можно ближе к производству. В критически важной среде вы хотите быть абсолютно уверенным, что обновление модуля не будет вставлять вашу базу данных. Мы используем следующий процесс:
И что это. Одна вещь, которую вы никогда не можете ожидать от среды сообщества, такой как Drupal, - это возможность переместить вашу базу данных с тестирования на производство после того, как вы начнете жить. С этого момента все перемещения базы данных происходят от производства до тестирования, что несколько усложняет процесс развертывания. Быть осторожен!:)
Я удивлен, что никто не упомянул модуль Deployment. Вот выдержка из его страницы проекта:
..., позволяющий пользователям легко создавать контент с одного сайта Drupal на другой. Развертывание автоматически управляет зависимостями между объектами (например, node ссылок). Он разработан, чтобы иметь богатый API, который может быть легко расширен, чтобы использоваться в различных ситуациях размещения контента.
Мы активно используем модуль Features для захвата функций, а затем легко устанавливаем их на месте производства.
Я не работаю с Drupal, но я много работаю с Joomla. Я развертываю, архивируя все файлы в корневом каталоге (tar и gzip в моем случае, но вы можете использовать zip), а затем загружать и расширять этот архив на рабочем сервере. Затем я беру SQL-дамп (mysqldump -u user -h host -p databasename > dump.sql), загружаю его и использую обратную команду для вставки данных (mysql -u produser -h prodDBserver -p prodDatabase < dump. SQL). Если у вас нет доступа к оболочке, вы можете загружать файлы по одному и писать PHP script для импорта dump.sql.
Любая система управления версиями (GIT, SVN) + Features модуль для развертывания кода Drupal + пользовательских настроек (типы контента, пользовательские поля, зависимости модулей, представления и т.д.).
Как Deploy модуль все еще находится в режиме разработки, поэтому вы можете использовать Node export в Drupal 7 для развертывания вашего контента/узлов.
Если вы новичок в развертывании (и или Drupal), тогда обязательно сделайте все в одном компе. Вы должны быть очень осторожны, когда есть пользователи, которые влияют на контент во время работы над другой копией.
Можно оставить таблицы, которые относятся к фактическому содержанию, таксономии, пользователям и т.д., а не к их структуре. Затем нажмите те, которые связаны с конфигурацией. Однако это добавляет порядок сложности.
Извините, если развертывание для вас - что-то старое, поэтому это смутно оскорбительно.
Хорошей стратегией, которую я нашел и которой я в настоящее время реализую, является использование комбинации модуля развертывания для переноса моего контента, а затем drush вместе с dbscripts для объединения и обновления ядра и модулей. Он заботится о слиянии с базой данных, даже если у вас есть живое содержимое, безопасность и обновления модулей, и в настоящее время у меня есть моя настройка для работы с svn.