Ми розпочали роботу з одним розробником і одним svn repo, що містить весь наш код:
^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1
(на той час це було велике поліпшення). Після цього отримали шанс трохи збільшитися, у нас виникли проблеми з круговими залежностями, повільними тестуваннями та загальними труднощами з повторним використанням коду (оскільки, наприклад, набір функцій website1 проник у загальний модуль-a).
Бажаючи модулювати кодову базу і очікуючи, що незабаром ми перейдемо до git (і прочитавши десь, що git не любить svn mega-repos), ми перейшли до набагато більш детальної структури:
^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)
Це було концептуально чудово. Більш модульний код, набагато швидші тестові набори, легше документувати і т. Д. Ми відкрили джерело деяких наших більш загальних компонентів і зробили всі модулі pip інстальованими (використовуючи їх pip install -e .для встановлення у developmentvirtualenv).
Ми створили ^/srv/trunkсховище, що містить структуру папок середовища виконання, тобто. ^/srv/trunk/libдля модулів, /srv/trunk/srcдля залишків ^/foo/trunk, ^/srv/trunk/wwwдля веб-сайтів тощо.
І нарешті (взявши ідею від perforce, з якою я працював дуже давно [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ) ми створили "vcs- отримати "текстовий файл, у якому перераховані всі відповідні репозиції та де їх слід перевірити у середовищі розробників, та відповідну команду для цього. Наприклад рядок vcs-fetc:
svn srv/lib/module-a ^/module-a/trunk
спричинить або (вперше)
cd /srv/lib && svn co ^/module-a/trunk module-a
або (згодом)
cd /srv/lib/module-a && svn up
і аналогічно для github repos (як наш власний, так і змінений / незмінний пакет постачальників).
Ми використовували той же процес vcs-fetch для створення виробничого середовища, але ми швидко з'ясовуємо, що ми не можемо знати, яку версію використовували в prod після виконання vcs-fetch.
За допомогою мега-репо ми могли просто відзначити номер редакції перед оновленням продукту з магістралі, а повернення назад було просто svn -r nnn up .. З кодом і svn, і git (і одного модуля в hg) - і ~ 120 repos, не очевидно, як це зробити ..
Я читаю http://12factor.net/ сьогодні, і перший фактор - "Одна кодова база", тому мені також цікаво, чи я тут відправився від правильного шляху?
Однією з моїх ідей було створити сценарій розгортання, який створив би встановлені в pip "розгортання" колеса і "зв'язав" їх разом у requirements.txtфайл. Потім розгортання передбачає створення нового virtualenv, встановлення на pip-файл вимоги.txt, в якому перераховуються колеса розгортання, та переключення активних virtualenv. Повернення до попереднього означало б просто переключення virtualenv назад (але якщо ми не хотіли зберегти virtualenvs назавжди, це не дозволило б нам повернутися в будь-який момент часу - на мій досвід, який ніколи не був потрібний).
У цей момент мені цікаво, чи я йду в неправильному напрямку, чи просто не пройшов достатньо далеко по правильному шляху ..? (усе, що я читаю, продовжує говорити про "ваш додаток", і я не знаю, як це перекладається на запуску 14 веб-сайтів з тієї ж бази коду ...)