Le script de déploiement doit-il être un artefact de la génération?

Il s'agit d'un projet Web écrit en Java.

J'écris donc la construction et les scripts de déploiement. Pour créer le build, j'ai utilisé ant. La construction continue se fait avec Jenkins.

La construction génère 3 artefacts différents:

1. Le dossier de guerre
2. Un zip avec des dispositions
3. Un zip avec des images

Jusqu'à présent, tout va bien, mais maintenant je dois écrire le script de déploiement, qui devrait:

• Déployer la guerre (artefact 1) sur le tomcat exécuté sur le serveur 1
• Placer l'artefact 2 sur le serveur 1 dans un répertoire spécifique
• Placer l'artefact 3 sur le serveur 2 dans un répertoire spécifique

Je parlais donc avec mon collègue et il a dit que nous devrions également générer un artefact (peut-être deploy.xml ) qui déploie ces artefacts lorsqu'ils sont placés sur le bon serveur.

Il y aurait donc un autre script, qui:

• Téléchargez les artefacts Jenkins
• scp sur chaque serveur et placez-y le deploy.xml
• appeler à distance le deploy.xml

Ce qui me met un peu mal à l'aise, c'est le fait d'avoir le deploy.xml comme un artefact de build. La motivation derrière cela serait de pouvoir effectuer un déploiement sans avoir besoin d'avoir accès aux référentiels VCS, donc une build serait autonome, c'est-à-dire que n'importe quelle build ne pourrait entrer en production qu'avec ce qui a été généré par Jenkins.

Où placer les scripts de déploiement? Doivent-ils être uniquement sur le VCS ou doivent-ils également être des artefacts de construction?

D'après mon expérience, tout ce qui peut être automatisé devrait l'être. Si vous pouvez le décrire comme étape 1, étape 2, .... alors ce devrait être un script. Si le script peut être généré automatiquement pour inclure des informations spécifiques à la construction (par exemple, une balise de révision), c'est ce que vous devez faire. Ce n'est pas pour être paresseux, mais pour être prévisible et reproductible .

Remarque bene: vous devriez également avoir un script de retour généré automatiquement qui peut être utilisé par n'importe quel membre de l'équipe au cas où le script de déploiement généré automatiquement deviendrait complètement fou et arroserait le serveur de production.

Tout ce que Peter Rowell a écrit est correct, en plus je voudrais:

Pour le fichier de script de déploiement

• s'il a été écrit par quelqu'un, il doit être en contrôle de version.
• s'il a été généré et peut être généré à nouveau, il ne passe généralement pas en contrôle de version.

Pour le processus de déploiement:

• Si vous souhaitez que vos artefacts soient autonomes et que cela puisse être fait facilement, le fichier peut être un artefact de génération, ce qui signifie qu'il est empaqueté avec le résultat de la construction de telle manière qu'il est utilisable pour le déploiement.
• D'un autre côté, les déploiements deviennent de plus en plus complexes donc tôt ou tard vous aurez besoin d'un programme dédié (lire du code) qui fait le déploiement et un artefact de build Jenkins n'est plus autonome.

Cela dépend plutôt de votre processus et de la façon dont vous aimez gérer les déploiements.