Чи потрібно джерелом керованих модулів керувати в моєму проекті?

Мені сказали, що під час розробки я повинен контролювати все, що знаходиться sites/в моєму сховищі коду (наприклад, SVN).

Якщо припустити, що я ніколи не торкаюся жодного модуля, який я використовую ( ctoolsі viewsт. Д.), Але буду створювати лише власну тему, чи варто все-таки це робити?

Або мені просто джерело контролювати все, що в ньому sites/all/themes/?

Дякую

— cherouvim
джерело

Відповіді:

У моїй команді ми перейшли до пошуку лише того, що є специфічним для нашого поточного проекту. Якщо ми використовуємо перегляди, наприклад, додати відповідний запис в нашому Drush макіяж -файл і версію , що , але не сам модуль.

Це залишає нам дуже невеликий сховище, що складається з будь-яких спеціальних модулів, специфічних для поточного сайту, поточної теми та функцій експорту.

Якщо ви абсолютно не можете використовувати друк і друкувати, я не розумію, чому слід керувати кодом управління версіями, який добре розроблений десь в іншому місці. І якщо ви маєте намір зламати один з модулів, тоді вам слід додати, що це як підмодуль , знову ж таки, не версійний код у власному репо. (Я вважаю, це називається відділенням постачальників у SVN).

Редагувати: Щоб отримати детальнішу інформацію та більш розширені налаштування, ви можете ознайомитись із цим сховищем: git@github.com: letharion / Drupal-build-scriptpts.git Сценарії написані bash для підтримки робочого процесу моїх команд, який включає в себе будівлю профіль базової установки ( NodeStream ), а потім наш профіль для цього сайту, файл файлів для кожного профілю, гачки для застосування патчів або внесення інших змін на окремі етапи збирання тощо. Я сподіваюся, що знайду час переосмислити -запишіть це як розширення барабану найближчим часом.

— Летаріон
джерело

Дякуємо за ваше детальне пояснення. Так, я використовую барабан і планую максимально автоматизувати. І я не планую змінювати будь-який код у основних або допоміжних модулях.

— cherouvim

+1 версія версії make файла - чудова ідея, думаю, я буду робити це в майбутньому;)

— Clive

@Letharion Я не зовсім розумію, як це працює при розробці одного і того ж сайту з різними розробниками одночасно? AFAIK барабан завжди завантажує всі залежності і намагається замінити сайти / за замовчуванням, навіть якщо ці модулі вже були D / L'd, чи є якийсь недокументований варіант завантажувати лише оновлені / нові модулі? Іншими словами: я розумію перевагу використання Drush make для встановлення заново, але як ви використовуєте її для підтримки синхронізованих залежностей модулів у розподіленій команді?

— Крейдерс

Я використовую цей підхід вже більше року, але зараз запитую, чи дійсно краще, ніж просто мати все репо, коли працюєте з іншими розробниками, які, можливо, не будують платформу щодня. Крім того, цей підхід насправді не сумісний із тим, як Acquia структурує свої репости для хмарного хостингу.

— Девід Мейстер

Як відповідь на відповідь @ Letharion, внесення всього SVN має сенс для деяких організацій, і це дійсно залежить від того, як ви робите свою розсилку. Розміщення модулів та тем у форматі SVN може мати сенс, якщо вам колись доведеться повернутися "назад у часі" та переглянути стару версію сайту.

Один із прикладів цього є корисним, коли ви підозрюєте про помилку в модулі contrib або спостерігаєте різну поведінку. Можливість відновити повну версію з минулого може допомогти.

Я також вважаю зручним зробити повний знімок сайту у SVN, коли мені потрібно розібратися, що клієнт зробив на сайті. Я можу зробити повний знімок їх версії та вставити її у SVN як гілку та порівняти.

— mpdonadio
джерело

Для того, щоб повернутися "назад у часі", мені також знадобиться відповідна повна резервна копія бази даних. Оскільки деякі параметри та конфігурації є в БД. Це так?

— cherouvim

Так. Модуль резервного копіювання та міграції та / або резервне копіювання архівів - ваш друг тут.

— mpdonadio

Використання цього методу дозволяє клонувати всю установку з контролю версій та резервної копії, що може бути дуже корисно для розробки та налагодження живих сайтів.

— кейт