Ingénierie de publication de logiciels Lean (Webapplication)

Question

Je cherche à réorganiser la manière dont nous publions notre logiciel interne. Tout le code (applications Web PHP, certaines applications Java et les scripts Perl) est archivé dans les référentiels Subversion, mais il n'y a pas de branches ni de balises, tout est archivé dans le coffre (seulement environ 1 à 3 développeurs par application). Sur les serveurs linux de production, le logiciel est directement exécuté à partir d’une copie de travail svn (en fait, la plupart des modifications s’y produisent également).

Étant donné que nous avons beaucoup de petites applications et que nous publions très souvent de petites modifications du système en cours d'exécution, je cherche un moyen très léger ou transparent de faire de l'ingénierie de publication et de nettoyer ce gâchis.

Existe-t-il des outils qui pourraient m'aider à le faire dans un environnement hétérogène (du point de vue du langage) comme celui-là? Ou quelqu'un a-t-il une idée de la manière de procéder?

Sinon, j'avais pensé écrire des scripts de version (shell) qui créaient automatiquement des balises de sous-version à partir de trunk, puis effectuaient une extraction de la balise correspondante sur les serveurs de production. Mais cela me semble un peu bidouiller aussi.

Merci,

Haes.

Answer 1

L’intégration continue est définitivement la voie à suivre - tout CI (même les fichiers de commandes minimalistes) vaut mieux que rien - mais il ne sera aussi bon que les politiques que vous avez mises en place. Étant donné que vos fichiers ne finissent pas en tant que «binaires» ou «distribuables», le marquage d'une version peut simplement nécessiter simplement de baliser le référentiel, ou même simplement de stocker le numéro de révision Subversion quelque part. La politique importante dont vous avez besoin est que chaque version puisse être reconstruite à tout moment - vous pouvez ainsi comparer les versions actuelles et précédentes, ou revenir à une version plus ancienne en cas de problème. Ne vous inquiétez pas de la "surcharge" de la création de balises dans svn - c'est très efficace.

Un script de version qui utilise la balise subversion semble bien se comporter Une implémentation de CI (je recommanderais CruiseControl car elle est idéale pour un travail hétérogène, bien que l'hétérogénéité nécessite un peu plus de temps système), car vous pouvez automatiquement lancer le processus lors de l'enregistrement d'une sous-version et exécuter des tests automatisés qui déterminent si c'est correct. assez pour taguer ou pas.

Je ne voudrais certainement pas déployer automatiquement sur un serveur de publication. Une "zone de préparation" (appelez-la "construction nocturne", "test bêta", peu importe) serait meilleure. Laissez vos utilisateurs insister sur ce point avant de décider qu'il est assez bon de le déployer sur les serveurs de production. Et, tant que vous avez la politique en place pour pouvoir revenir à une version antérieure, vous avez atténué la possibilité d’un mauvais déploiement.

L’auto-extraction sur les serveurs de production est la seule partie 'hackish' - une extraction, un test, une balise, un déploiement bêta automatiques sont suffisamment lisses. Le passage à la production ne devrait cependant pas être facile.

Answer 2

Utilisez des balises et des branches; en faire une partie du cycle de développement. Lorsque vous mettez à jour cette " stable-1.0 " branche, ont testé les modifications et les ont étiquetées "release-1.0.5", vous faites simplement "svn switch". sur le serveur à la nouvelle balise. N'a pas fonctionné, malgré l'avoir testé? Revenez et trouvez ce qui ne va pas.

Mais attention, la création de branches dans la subversion peut être pénible, du moins avant la version 1.5. Si vous ou vos développeurs n'êtes pas habitués aux branches, attendez-vous à des tracas et / ou à des erreurs au début. Mais tant que vous avez commis aucun code ne doit être perdu (au pire, il est difficile de fusionner).

Vos développeurs doivent vraiment apprendre à utiliser les branches; cela peut être très utile à diverses fins (pas seulement pour l’ingénierie des versions).

Ne pas permutez automatiquement le code sur vos serveurs de production; quelqu'un pourrait accidentellement appuyer sur le mauvais bouton. Les mises à jour de la production doivent toujours être effectuées avec soin. Les scripts pour ajouter de nouveaux tags sont, à mon humble avis, inutiles en raison de leur simplicité, mais votre kilométrage peut varier.

Une dernière chose, ne permettez à personne d’avoir des modifications sur votre serveur de production. Cela pourrait provoquer des conflits, qu’il faudra généralement du temps pour résoudre. Sans oublier que cela détruit votre capacité à reproduire une version donnée sur différents postes de travail (fonctionne bien ici! Pourquoi pas sur le serveur? Hmm).

Answer 3

Certains serveurs d’intégration continue agissent de la sorte, par exemple, Hudson a une intégration de subversion. Il peut baliser, exécuter test et déployer pour vous.

Answer 4

J'utiliserais Hudson. En plus de récupérer et de marquer dans svn (ref sblundy), il peut être utile dans la gestion des versions avec le bon plugins . Par exemple, vous pouvez essayer un plugin pour " promouvoir " ; les versions que vous déployez en production et conservez une liste des versions promues elles-mêmes et un journal de modification / validation des différentes versions.