Question

Mon équipe tente actuellement d'automatiser le déploiement de nos applications web .Net et PHP.Nous souhaitons rationaliser les déploiements et éviter les tracas et les nombreux maux de tête causés par une opération manuelle.

Nous avons besoin d’une solution qui nous permettra de :

- Compile the application  
  - Version the application with the SVN version number
  - Backup the existing site
  - Deploy to a web farm

Toutes nos applications sont contrôlées par la source à l'aide de SVN et nos applications .Net utilisent CruiseControl.Nous avons essayé d'utiliser les scripts de déploiement MSBuild et NAnt avec un succès limité.Nous avons également utilisé Capistrano dans le passé, mais souhaitons éviter d'utiliser Ruby si possible.

Existe-t-il d'autres outils de déploiement qui pourraient nous aider ?

Était-ce utile?

La solution

Merci à tous pour vos aimables suggestions.Nous les avons tous vérifiés, mais après mûre réflexion, nous avons décidé de créer le nôtre avec une combinaison de CruiseControl, NAnt, MSBuild et MSDeploy.

Cet article contient d'excellentes informations :Intégration de MSBuild avec CruiseControl.NET

Voici à peu près comment fonctionne notre solution :

  • Les développeurs créent la version « debug » de l'application et exécutent des tests unitaires, puis s'enregistrent sur SVN.
  • CruiseControl voit les mises à jour et appelle notre script de construction...
    • Exécute toutes les nouvelles migrations sur la base de données de build
    • Remplace les fichiers de configuration par la configuration du serveur de build
    • Construit la configuration « debug » de l'application
    • Exécute tous les tests unitaires et d'intégration
    • Construit la configuration de « déploiement » de l'application
      • Versionne les DLL avec la version majeure/mineure actuelle et la révision SVN, par ex.1.2.0.423
      • Déplace cette nouvelle version vers un dossier « release » sur notre serveur de build
      • Supprime les fichiers inutiles
    • Met à jour IIS sur le serveur de build si nécessaire

Ensuite, lorsque nous avons vérifié que tout est prêt à passer en live/staging, nous exécutons un autre script pour :

  • Exécuter des migrations sur un serveur live/stade
  • MSDéploiement :archiver le site live/staging actuel
  • MSDéploiement :synchroniser le site de la construction au live/staging

Ce n'était pas vraiment arrivé à ce stade, mais ça fonctionne à merveille maintenant :D

Je vais essayer de garder cette réponse à jour à mesure que nous apportons des modifications à notre processus, car il semble y avoir maintenant plusieurs questions similaires sur SA.

Autres conseils

j'ai utilisé Création visuelle Pro depuis des années, il est assez simple et facile à utiliser et intègre de nombreuses opérations standard (comme celles que vous avez mentionnées).

j'utilise Fantoche, Makefiles pour créer des RPM et Bambou faire ça pour moi.Mon système ne s'applique pas directement et je ne suis pas très familier avec le monde Windows, mais il existe certains modèles transférables.

Ma configuration make me permet de créer des RPM pour tout (librairies php, sites Web php, modules perl, applications C, etc.) qui composent mon application.Cela peut être appelé manuellement ou via Bamboo.Je transfère ces RPM dans un dépôt yum et des poignées de marionnettes en m'assurant que les versions les plus récentes (ou correctes) du logiciel sont installées dans le cluster.

Pourriez-vous automatiser la création de progiciels dans les MSI ?Je pense que Puppet peut gérer l'installation de packages logiciels et de versions sous Windows.

J'utilise msdeploy pour cela.Cela fonctionne parfaitement.

À propos de la fourmi ;pour la plateforme .NET, nous avons NAnt et vous pouvez l'utiliser en combinaison avec MSDeploy ;vous avez la possibilité d'appeler MSDeploy depuis votre script Nant.

Édité:Juste pour que les choses soient claires ;vous pouvez tout faire avec msdeploy.Utiliser Nant n’est pas une obligation.

Plutôt que d'utiliser xcopy, nous avons réussi à utiliser la commande -source:dirpath avec des adresses UNC vers les serveurs avec msdeploy.La clé était ignoreAcls=true et supprimait les appels au nom d'utilisateur et au mot de passe dans la chaîne msdeploy :

msdeploy -verb:sync -source:dirpath=\\build\e$\app -dest:dirpath=\\live\d$\app,ignoreAcls=true

L'exemple déploie le site depuis le lecteur E de notre serveur de build vers le lecteur D de notre serveur en direct.Il existe certaines considérations de sécurité liées à l'exposition des partages ou à ce niveau d'accès au disque sur un serveur actif.Nous étudions actuellement la possibilité d'utiliser un dossier partagé à accès limité.

Nous redirigeons ensuite cette sortie vers un fichier journal qui est ensuite déplacé vers l'archive de sauvegarde pour référence.Le fichier journal enregistre quels fichiers ont été déplacés et quand. Poursuivons l'exemple ci-dessus avec la commande de tube de sortie :

... > E:\archive\msdeploy.log

Personne n'a mentionné Final Builder http://www.finalbuilder.com.C'est à égalité avec Visual build Pro.Bonne interface graphique pour créer des harnais de déploiement de build automatisés

Tissu.Cela semble petit, simple, procédural.Écrit en Python, puisque Ruby est un non-non (pourquoi ?).

Découvrez Setup Factory (de Indigo Rose).Il est assez robuste dans ce qu'il peut faire.Il utilise l'API du programme d'installation de Windows.Il peut probablement faire ce dont vous avez besoin.

La seule raison pour laquelle Nant devrait exister est que vous disposiez d'un framework similaire à Ant dans lequel nous pouvons écrire des tâches en utilisant l'ensemble de langages .NET.Si vous ne souhaitez pas qu'un développeur .NET pur écrive des tâches personnalisées, je ne vois aucune raison pour laquelle vous ne pouvez pas utiliser Ant.Ce n’est pas parce que vous écrivez votre application dans un langage .NET que vous devez utiliser un outil de construction .NET.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top