Nous avons commencé avec un développeur et un repo svn contenant tout notre code:
^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1
(à l'époque, c'était une grande amélioration). Après que cela ait eu la chance de se développer un peu, nous avons commencé à avoir des problèmes avec les dépendances circulaires, les suites de tests lentes et les difficultés générales à réutiliser le code (car par exemple, l'ensemble des fonctionnalités de website1 s'était glissé dans le module-a autrement générique).
Voulant modulariser la base de code, et nous attendons à ce que nous passions à git sous peu (et ayant lu quelque part que git n'aime pas svn mega-repos), nous sommes passés à une structure beaucoup plus granulaire:
^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)
C'était génial conceptuellement. Plus d'un code modulaire, beaucoup plus rapide test-suites, plus facile à documents, etc. Nous open source certains de nos composants plus génériques, et fait tous les modules pip installable ( en utilisant pip install -e .pour les installer dans le developmentvirtualenv).
Nous avons créé un ^/srv/trunkréférentiel contenant la structure des dossiers de l'environnement d'exécution, c'est-à-dire. ^/srv/trunk/libpour les modules, /srv/trunk/srcpour les restes de ^/foo/trunk, ^/srv/trunk/wwwpour les sites Web etc.
Et enfin (en prenant une idée de perforce, avec laquelle j'ai travaillé il y a très longtemps [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ), nous avons créé un "vcs- fetch "fichier texte qui répertorie tous les dépôts pertinents et où ils doivent être récupérés dans l'environnement de développement, et une commande correspondante pour le faire. Par exemple, une ligne vcs-fetc:
svn srv/lib/module-a ^/module-a/trunk
causerait soit (première fois)
cd /srv/lib && svn co ^/module-a/trunk module-a
ou (après)
cd /srv/lib/module-a && svn up
et de même pour les dépôts github (à la fois nos propres packages de fournisseurs et ceux modifiés / non modifiés).
Nous avons utilisé le même processus vcs-fetch pour créer l'environnement de production, mais nous découvrons rapidement que nous n'avons aucun moyen de savoir quelle version était utilisée dans prod après avoir effectué vcs-fetch.
Avec le méga-repo, nous pouvions simplement noter le numéro de révision avant de mettre à jour la prod à partir du tronc, et revenir en arrière était simple svn -r nnn up .. Avec du code à la fois dans svn et git (et un module dans hg) - et ~ 120 repos, il n'est pas évident de le faire.
J'ai lu http://12factor.net/ aujourd'hui, et le premier facteur est "une base de code" donc je me demande aussi si je suis loin du bon chemin ici?
Une idée que j'avais était de créer un script de déploiement qui créerait des roues de «déploiement» installables par pip et les regrouperait dans un requirements.txtfichier. Un déploiement impliquerait alors la création d'un nouveau virtualenv, l'installation par pip du fichier requirements.txt répertoriant les roues de déploiement et la commutation du virtualenv actif. Revenir au précédent impliquerait simplement de basculer le virtualenv en arrière (mais à moins que nous voulions garder les virtualenvs pour toujours, cela ne nous permettrait pas de revenir à un moment donné - selon mon expérience, cela n'a jamais été nécessaire cependant).
À ce stade, je me demande si je marche dans la mauvaise direction, ou si je ne viens pas assez loin sur le bon chemin ..? (tout ce que je lis continue de parler de "votre application", et je ne sais pas comment cela se traduit par l'exécution de 14 sites Web à partir de la même base de code ...)