Я - предприниматель с проектом Drupal 6x, который начался достаточно маленьким, чтобы не нуждаться в контроле версий (для разработчиков), но теперь я убежден, что без него нет пути. Существует обширная документация по JIRA, дополненная хорошо написанными пользовательскими историями, охватывающими все. Я прочитал немного о том, как это можно сделать, и придумал следующий план -
- Отделение кода сайта от базы данных с помощью модулей
- Поместите код в репозиторий SVN и создайте промежуточный сайт
- Создайте зеркало промежуточного сервера на производственном сервере EC2
- Создавайте тесты Selenium и запускайте их в облаке, используя Saucelabs
- Создайте рабочий процесс сборки в JIRA Studio, используя Elastic Bamboo для запуска автоматических обновлений
- Обновление и установка профилей с помощью Drush Make
- Запускайте обновления на производственном сервере (я не знаю как)
Для начала я составил список из 50 «функций», каждая из которых имеет свои компоненты (представления, типы контента, модули и т. Д.). Это, несомненно, будет непросто, поскольку сайт содержит около десятка пользовательских модулей и веб-служб, не говоря уже о еще десятках экземпляров «приложения» типа контента, содержащих пользовательский код (большинство из которых я хотел бы преобразовать в обновляемые представления или модули). , Хорошо, что сайт еще не запущен, поэтому риск все еще ограничен.
У кого-нибудь есть опыт в создании чего-то подобного? С какими подводными камнями и ограничениями мне следует столкнуться? Я был бы очень признателен за любые предложения по улучшению / исправлению вышеуказанного плана, а также за любые идеи или советы, которые вы, эксперты, могли бы дать мне.
источник
Ответы:
Хорошо, я попробую :) Я не смогу полностью ответить на ваш вопрос, но, возможно, дам вам несколько интересных советов. Обратите внимание, что моя нумерация не в прямом ответе на вашу :)
Как я уже упоминал в комментарии, ни один проект не является слишком маленьким для контроля версий. Я лично рекомендую Git. Причины - просто потрясающая скорость (время ожидания в git измеряется в миллисекундах, а не секундах) и огромное количество функций. Это может быть немного трудно подобрать из-за странных имен и аргументов, но следующая документация объясняет многие из них действительно хорошими: http://www.eecs.harvard.edu/~cduan/technical/git/ . Другая причина в том, что теперь он используется drupal.org, поэтому знание git поможет вам, когда вы захотите внести свой вклад (предоставление исправлений, тестирование исправлений, выпустить модули, ...)
Тем не менее, если вы хотите по какой-то причине использовать SVN (например, интеграцию со службами, которые вы планируете использовать), то сделайте это. SVN тоже работает разумно и намного лучше, чем отсутствие контроля версий. (Если вы не спросите Линуса Торвальдса ..). Кроме того, часто есть способы перехода с одной VCS на другую, если вы передумаете. SVN -> Git работает хорошо, например.
В-третьих, подойдите к этому шаг за шагом. Не пытайтесь делать все сразу. Дайте вам (и вашим разработчикам) время, чтобы изучить новые инструменты.
Переход с Drupal 6 на Drupal 7 - это не тривиальная вещь. Особенно с большим количеством нестандартного кода. Обратите внимание только на то, что существует множество изменений API и новых концепций (таких как система сущностей / полей), но есть также момент, когда многие добавленные модули еще не полностью готовы.
Управление развертыванием является одним из слабых мест Drupal, который также не сильно изменился в Drupal 7. Мы знаем о проблеме, и люди прилагают все усилия, чтобы решить ее для Drupal 8: http://groups.drupal.org / build-systems-change-management / cmi . Особенности и т. Д. Помогают, но это не серебряная пуля. Не все может быть экспортировано как функция.
Есть также несколько опций Drupal для развертывания промежуточных / производственных сайтов. Pantheon (все еще в бета-версии) и Acquia Dev Cloud стоит попробовать.
Непрерывная интеграция, автоматизированное тестирование важны и действительно полезны, но также требуют времени для настройки, написания тестов и так далее. Время, которое вы можете или не можете иметь в этот момент. Но особенно автоматизированные тесты - это область, в которой легко проводить постепенные улучшения. После того, как вы настроили среду для их запуска, вы можете писать все больше и больше тестов, если позволяет время.
Итак, вот моя рекомендация для обновленного вопроса в комментарии:
Закончите и выпустите как есть, но начните использовать VCS (систему контроля версий) для Drupal 6 сейчас. Создайте промежуточную среду для своего сайта. Посмотрите, какие (предоставленные) модули вы используете, и проверьте, возможен ли в данный момент порт для Drupal 7. Не стоит недооценивать время, которое займет. Также начните улучшать процесс тестирования / развертывания, начиная с того, что, по вашему мнению, принесет вам наибольшую выгоду / стоимость.
Вы также можете создать более конкретные дополнительные вопросы или посмотреть те, которые уже существуют. Как видите, даже если дать только несколько подсказок на такой вопрос, это может стать огромным и занять довольно много времени.
источник