Мне нужно привести сайт к управлению версиями и настроить среду непрерывной интеграции


41

Я - предприниматель с проектом Drupal 6x, который начался достаточно маленьким, чтобы не нуждаться в контроле версий (для разработчиков), но теперь я убежден, что без него нет пути. Существует обширная документация по JIRA, дополненная хорошо написанными пользовательскими историями, охватывающими все. Я прочитал немного о том, как это можно сделать, и придумал следующий план -

  1. Отделение кода сайта от базы данных с помощью модулей
    1. контекст
    2. особенности
    3. Сильная рука
    4. Profiler
  2. Поместите код в репозиторий SVN и создайте промежуточный сайт
  3. Создайте зеркало промежуточного сервера на производственном сервере EC2
  4. Создавайте тесты Selenium и запускайте их в облаке, используя Saucelabs
  5. Создайте рабочий процесс сборки в JIRA Studio, используя Elastic Bamboo для запуска автоматических обновлений
  6. Обновление и установка профилей с помощью Drush Make
  7. Запускайте обновления на производственном сервере (я не знаю как)

Для начала я составил список из 50 «функций», каждая из которых имеет свои компоненты (представления, типы контента, модули и т. Д.). Это, несомненно, будет непросто, поскольку сайт содержит около десятка пользовательских модулей и веб-служб, не говоря уже о еще десятках экземпляров «приложения» типа контента, содержащих пользовательский код (большинство из которых я хотел бы преобразовать в обновляемые представления или модули). , Хорошо, что сайт еще не запущен, поэтому риск все еще ограничен.

У кого-нибудь есть опыт в создании чего-то подобного? С какими подводными камнями и ограничениями мне следует столкнуться? Я был бы очень признателен за любые предложения по улучшению / исправлению вышеуказанного плана, а также за любые идеи или советы, которые вы, эксперты, могли бы дать мне.


Это очень интересный вопрос. Это то, что я думал о реализации на моем сайте, но сдался, потому что это не показалось эффективным. Если вы прошли через это, пожалуйста, дайте нам свой вклад.
Tivie

3
Определенно интересный вопрос, но также трудно ответить. Вы задаете несколько вопросов, поэтому трудно дать вам полный / лучший ответ. Только один совет: ИМХО, ни один проект не слишком мал для контроля версий. Особенно сейчас с распределенными VCS, такими как git, требуется 5 секунд, чтобы поместить ваш код в локальный репозиторий. См. Также drupal.stackexchange.com/questions/316/…
Бердир

Оглядываясь назад, действительно, ни один проект не является слишком маленьким для контроля версий (если бы я только знал это тогда). Я прошел по этой ссылке, и это поднимает еще один важный вопрос. Если мы хотим извлечь ядро ​​Drupal из своего собственного репозитория git, следует ли нам использовать git для проектов Drupal вместо SVN? Причина, по которой мы используем SVN, заключается в том, что в JIRA Studio есть встроенная поддержка для него, что важно для нас, учитывая, что мы хотим использовать функции автоматической сборки JIRA (Elastic Bamboo). Извините за множественные вопросы :-(
druflex

ОБНОВЛЕНИЕ: После проверки кода было установлено, что в проекте много пользовательского кода, который будет действительно трудно экспортировать с использованием функций. Таким образом, перед нами следующие варианты: (1) Завершить и выпустить как есть, и начать параллельную разработку в D7, используя надлежащий контроль версий. Это означает, что спор базы данных позже. Страшно. (2) Верните важные функции в D6, отпустите, затем выполните непрерывную интеграцию. (3) Верните важные функции в D7, отпустите, затем выполните непрерывную интеграцию. Главный вопрос - сколько времени займет каждый из этих вариантов. Если бы вы были мной, за что бы вы проголосовали?
druflex

Ответы:


23

Хорошо, я попробую :) Я не смогу полностью ответить на ваш вопрос, но, возможно, дам вам несколько интересных советов. Обратите внимание, что моя нумерация не в прямом ответе на вашу :)

  1. Как я уже упоминал в комментарии, ни один проект не является слишком маленьким для контроля версий. Я лично рекомендую Git. Причины - просто потрясающая скорость (время ожидания в git измеряется в миллисекундах, а не секундах) и огромное количество функций. Это может быть немного трудно подобрать из-за странных имен и аргументов, но следующая документация объясняет многие из них действительно хорошими: http://www.eecs.harvard.edu/~cduan/technical/git/ . Другая причина в том, что теперь он используется drupal.org, поэтому знание git поможет вам, когда вы захотите внести свой вклад (предоставление исправлений, тестирование исправлений, выпустить модули, ...)

  2. Тем не менее, если вы хотите по какой-то причине использовать SVN (например, интеграцию со службами, которые вы планируете использовать), то сделайте это. SVN тоже работает разумно и намного лучше, чем отсутствие контроля версий. (Если вы не спросите Линуса Торвальдса ..). Кроме того, часто есть способы перехода с одной VCS на другую, если вы передумаете. SVN -> Git работает хорошо, например.

  3. В-третьих, подойдите к этому шаг за шагом. Не пытайтесь делать все сразу. Дайте вам (и вашим разработчикам) время, чтобы изучить новые инструменты.

  4. Переход с Drupal 6 на Drupal 7 - это не тривиальная вещь. Особенно с большим количеством нестандартного кода. Обратите внимание только на то, что существует множество изменений API и новых концепций (таких как система сущностей / полей), но есть также момент, когда многие добавленные модули еще не полностью готовы.

  5. Управление развертыванием является одним из слабых мест Drupal, который также не сильно изменился в Drupal 7. Мы знаем о проблеме, и люди прилагают все усилия, чтобы решить ее для Drupal 8: http://groups.drupal.org / build-systems-change-management / cmi . Особенности и т. Д. Помогают, но это не серебряная пуля. Не все может быть экспортировано как функция.

  6. Есть также несколько опций Drupal для развертывания промежуточных / производственных сайтов. Pantheon (все еще в бета-версии) и Acquia Dev Cloud стоит попробовать.

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

Итак, вот моя рекомендация для обновленного вопроса в комментарии:

Закончите и выпустите как есть, но начните использовать VCS (систему контроля версий) для Drupal 6 сейчас. Создайте промежуточную среду для своего сайта. Посмотрите, какие (предоставленные) модули вы используете, и проверьте, возможен ли в данный момент порт для Drupal 7. Не стоит недооценивать время, которое займет. Также начните улучшать процесс тестирования / развертывания, начиная с того, что, по вашему мнению, принесет вам наибольшую выгоду / стоимость.

Вы также можете создать более конкретные дополнительные вопросы или посмотреть те, которые уже существуют. Как видите, даже если дать только несколько подсказок на такой вопрос, это может стать огромным и занять довольно много времени.


Большое спасибо за такой замечательный исчерпывающий ответ. Я в значительной степени решил, что именно вы рекомендуете. Даже включая Git. Я перенесу JIRA с хостинга на автономный, чтобы я мог использовать плагин Git. Так что D6 это так. Выпустите текущую версию прямо сейчас и начните воссоздавать надлежащую копию лучших практик параллельно, используя как можно больше существующего кода. Еще раз спасибо за поддержку. Ура!
druflex

+1 Хороший совет, всесторонний, практичный на улице и реальный. Вы говорите из опыта. Спасибо.
therobyouknow
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.