Comenzamos con un desarrollador y un repositorio svn que contenía todo nuestro código:
^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1
(en ese momento esto fue una gran mejora). Después de que esto tuvo la oportunidad de crecer un poco, comenzamos a tener problemas con las dependencias circulares, los paquetes de prueba lentos y las dificultades generales para volver a usar el código (ya que, por ejemplo, el conjunto de características del sitio web1 se había introducido en el módulo genérico a).
Queriendo modularizar la base del código, y esperando que pasemos a git en breve (y después de haber leído en algún lugar que a git no le gusta svn mega-repos), hemos pasado a una estructura mucho más granular:
^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)
Esto fue conceptualmente genial. Más código modular, conjuntos de pruebas mucho más rápidos, más fáciles de documentar, etc. Hemos abierto algunos de nuestros componentes más genéricos y hemos instalado todos los módulos pip ( pip install -e .para instalarlos en developmentvirtualenv).
Creamos un ^/srv/trunkrepositorio que contiene la estructura de carpetas del entorno de tiempo de ejecución, es decir. ^/srv/trunk/libpara los módulos, /srv/trunk/srcpara los restos de ^/foo/trunk, ^/srv/trunk/wwwpara sitios web, etc.
Y finalmente (tomando una idea de forzar, con la que trabajé hace mucho tiempo [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ) creamos un "vcs- buscar "archivo de texto que enumera todos los repositorios relevantes y dónde se deben extraer en el entorno de desarrollo, y un comando correspondiente para hacerlo. Por ejemplo, una línea vcs-fetc:
svn srv/lib/module-a ^/module-a/trunk
causaría cualquiera (primera vez)
cd /srv/lib && svn co ^/module-a/trunk module-a
o (después)
cd /srv/lib/module-a && svn up
y de manera similar para los repositorios de github (tanto nuestros paquetes de proveedores propios como los modificados).
Hemos utilizado el mismo proceso vcs-fetch para crear el entorno de producción, pero rápidamente descubrimos que no tenemos forma de saber qué versión solía ejecutarse en prod después de hacer un vcs-fetch.
Con el mega-repositorio, podríamos anotar el número de revisión antes de actualizar el producto desde la troncal, y regresar fue muy sencillo svn -r nnn up .. Con código en svn y git (y un módulo en hg) - y ~ 120 repos, no es obvio cómo hacer esto ...
Leí http://12factor.net/ hoy, y el primer factor es "Una base de código", así que también me pregunto si estoy muy lejos del camino correcto aquí.
Una idea que tuve fue crear un script de despliegue que creara ruedas de "despliegue" instalables en pip y las "agrupara" en un requirements.txtarchivo. Luego, una implementación implicaría crear un nuevo virtualenv, instalar pip el archivo require.txt que enumera las ruedas de implementación y cambiar el virtualenv activo. Volver al anterior solo implicaría cambiar el virtualenv hacia atrás (pero a menos que quisiéramos mantener los virtualenvs para siempre, no nos permitiría volver a ningún punto en el tiempo, aunque en mi experiencia eso nunca ha sido necesario).
En este punto me pregunto si estoy caminando en la dirección incorrecta, o si simplemente no he caminado lo suficiente en el camino correcto ... (todo lo que leo sigue hablando de "su aplicación", y no sé cómo se traduce en ejecutar 14 sitios web fuera de la misma base de código ...)