La façon dont nous gérons actuellement les déploiements de sites sur le serveur, puis le changement de sites entre démo/acc/live "mode" est un peu hasardeux et je cherche pour améliorer l'ensemble du processus.Gestion des déploiements de sites entre démo/staging/live sur les serveurs de production
J'ai passé en revue les outils de déploiement automatisés, mais aussi la façon dont le serveur est structuré. Je vais enregistrer les questions de déploiement automatisé pour un autre poste, ici je suis intéressé par la façon dont les gens organisent le code sur leurs serveurs de production.
Nous avons actuellement 3 dossiers de premier niveau sur le lecteur de données, "démo", "acceptation" et "live". Il y a des différences ténues entre ce qui classifie quelque chose comme "démo" ou "acc" dans lequel je ne vais pas entrer, il suffit de dire que je veux me débarrasser de tout argument/ambiguïté. Notre procédure de déploiement est la suivante, une fois qu'un site est développé, déployez-le sous un en-tête d'hôte "d'acceptation" tel que acceptance.project-domain.com sous le dossier "acceptation". Le client passe en revue le site, nous lui faisons un test pour nous assurer que toutes les chaînes de connexion/permissions, etc. sont correctes. Le client donne l'OK pour aller vivre. À ce stade, nous redéfinissons complètement le site sous le dossier «live» et lui donnons l'en-tête de l'hôte en direct. Bien sûr, à ce stade, le site est totalement non testé dans son état déployé (ne parle pas de tests unitaires ici, je veux dire les autorisations de fichiers, les erreurs de configuration IIS, etc.). Le site doit alors être retesté :(
Je pense une structure quelque chose comme ça, serait beaucoup mieux:
/<customer>/<project>/<fullversion>/wwwroot
De cette façon, un nouveau site peut être déployé dans un dossier sous version1 Si le client donne l'OK, vous changez simplement les en-têtes et vous êtes absent.S'il y a des demandes de changement, ils passent sous un v1.1 qui peut avoir l'en-tête d'acceptation, une fois qu'il obtient le bon, permuter les en-têtes Rincez et répétez
Ce processus serait également beaucoup plus facile à gérer pour un déploi automatisé Script de yment. Avoir tout le code pour un site sous un dossier parent unique signifie que les permissions de téléchargement peuvent être limitées à un seul site, donc vous ne pouvez pas écraser accidentellement le code d'un autre site, il est beaucoup plus facile de garder une trace des versions sur le serveur. wiki de gestion peut facilement être maintenu ... la liste continue! Quelles sont vos méthodes d'organisation du code et de gestion des déploiements?