Мені потрібно привести сайт до контролю версій та створити середовище безперервної інтеграції

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

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

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

Хтось має досвід робити щось подібне? З якими підводними каміннями та обмеженнями слід очікувати зустрічі? Я дуже вдячний будь-яким пропозиціям щодо вдосконалення / виправлення вищезазначеного плану, або будь-яке розуміння та поради, які ви, можливо, вам запропонували для мене.

Гаразд, я спробую це :) Я не зможу повністю відповісти на ваше запитання, але, можливо, дам вам кілька цікавих підказок. Зауважте, що моя нумерація не відповідає прямо вашим :)

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

2. Однак, якщо ви хочете використовувати SVN з якихось причин (наприклад, інтеграцію з сервісами, які ви плануєте використовувати), тоді перейдіть до цього. SVN теж добре працює і є набагато кращим, ніж відсутність контролю джерел. (Якщо ви не запитаєте Лінуса Торвальдса ..). Крім того, часто існують способи переходу з одного ДКС на інший, якщо ви передумали. SVN -> Git працює добре, наприклад.

3. По-третє, підходьте до цього крок за кроком. Не намагайтеся робити все відразу. Дайте вам (та вашим розробникам) час вивчити нові інструменти.

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

5. Управління розгортанням - одна із слабких сторін Drupal, яка також не змінилася настільки сильно в Drupal 7. Ми знаємо про проблему, і люди наполегливо працюють над тим, щоб вирішити це для Drupal 8: http://groups.drupal.org / build-системи-управління змінами / cmi . Особливості тощо допомагають, але це не срібна куля. Не все можна експортувати як функцію.

6. Існує також кілька варіантів Drupal-specifc для розгортання постановочних / виробничих майданчиків. Пантеон (все ще знаходиться в бета-версії) та хмара Acquia Dev, можливо, варто перевірити.

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

Отже, ось моя рекомендація щодо оновленого питання в коментарі:

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

Ви також можете створити більш конкретні подальші запитання або подивитися ті, які вже є. Як бачите, навіть лише дати декілька підказок на таке питання може стати величезним і зайняти зовсім небагато часу.