Troquer son CIFS contre un SVN ?

C'est l'histoire d'un administrateur système qui devait faire une livraison.
Actuellement cela se passe de cette manière :

1. La DEV créé un dossier sur un partage CIFS "Projets\Nom-application\v1.0.1".
2. Dans ce dossier, s'y trouve le code de l'application si c'est du php ou le war si c'est du java.
3. Vient éventuellement un dump SQL
4. Et parfois un Vhost apache.
5. Évidement, il y a aussi un fichier texte (LibreOffice) qui explique comment installer l'application.
6. L'administrateur système est notifié de la demande de mise en service de l'application par un ticket et planifie une date de réalisation.

Tout ça c'est cool, c'est à peu près simple à faire, mais c'est extrêmement fastidieux et l'administrateur système n'apporte presque aucune valeur ajouté à la mise en service de l'application. #grille-pain

Il faut automatiser cela !
Cependant avec des dossiers arbitraires dans un partage CIFS on est plutôt mal parti.

Nous nous sommes donc dit que mettre tout cela dans un SCM pourrait être une bonne idée.
Par défaut, j'ai proposé git, mais comme les chefs veulent y mettre également des gros fichiers binaires (les war par exemple), d'après la documentation de git et svn, il s'avère que svn est mieux adapté pour gérer cela.
C'est dommage d'installer une nouvelle brique technique sans avoir la dernière en date, la meilleure du moment (et pour un bon moment à mon avis), mais passons.

Nous voilà donc avec un serveur SVN propulsé par SCMManager. Pourquoi ce choix ?  Nous sommes en entreprise et pour quasiment toutes nos applications il faut au minimuim :

• une authentification LDAP
• une interface web d'administration car «on est pas tous expert» #Let-me-laugh

Bref, ce qui est bien dans ce produit c'est qu'il permet de faire aussi bien du git que du svn, donc le jour ou on voudra changer ça sera simple.
Pour information, SCMManager c'est un war qui embarque tout, tu le jette dans un tomcat et ça run :)

Nous avons donc un serveur SVN prêt à recevoir nos projets.
Oui, mais comment organiser cela ? Si l'on créé un repository par projet en poussant le code à la racine, quid du dump SQL ou du vhost apache ? Comment stocker cela maintenant ?

Après recherches et discussions avec des personnes «du milieu» le plus simple dans notre cas est d'initialiser un repository portant le nom de l'application et de créer des dossiers vides à l'intérieur, comme ceci :

• appli : ce dossier contiendra le code de l'application (le php par exemple)
• db : ce dossier contiendra le dump SQL si il y en a un
• conf : ce dossier contiendra les fichiers de configuration (vhost par exemple)
• script :ce dossier contiendra des scripts

Dans mon cas j'ai créé un script "deploy.sh" dans le dossier "script" du repository. Ce script fait tout le travail de la mise en service de l'application en prenant en paramètre l’environnement, «pre-prod» ou «prod».

Voilà, ce n'est peut-être pas encore parfait, mais c'est bien mieux qu'un partage CIFS.