Est-ce une bonne idée d'installer Mercurial sur votre serveur et hg pull pour déployer?

Je viens de commencer un nouveau travail le mois dernier et on dirait qu'ils n'ont AUCUN contrôle de code source pour leur code. Ils comptent sur les sauvegardes que leur hébergeur prend pour eux.

Après avoir parlé un peu, j'ai convaincu mon patron que nous devrions certainement utiliser le contrôle de code source et après avoir donné un court séminaire à ce sujet, toute l'équipe est à bord; ils aimaient Mercurial.

Voici donc comment nous travaillons actuellement:

º----------BitBucket
º---------/
º--------/

Moi-même et les trois autres développeurs hg pullde BitBucket, apportons nos modifications, puis hg pushà BitBucket.

Maintenant, pour le déploiement, quelqu'un aurait besoin de FTP les derniers fichiers vers le serveur de production.

Je pensais installer Mercurial sur notre serveur et utiliser hg clone(par la suite hg pull) pour garder les versions à jour en production.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

Est-ce une bonne idée? Des pièges potentiels que je ne vois peut-être pas? Quelqu'un ici a-t-il fait quelque chose de similaire? Comment déployez-vous une grande application de framework PHP (nous utilisons Moodle)?

C'est certainement une bonne idée et c'est une méthode courante à utiliser pour le déploiement. Vous souhaiterez peut-être utiliser une branche stable à des fins de déploiement tout en conservant le tronc pour le développement continu afin de pouvoir tester la branche stable avant de la déployer en production.

Le seul problème peut survenir lorsque vous avez des informations sensibles dans votre base de code (telles que des clés API, etc.) que vous ne souhaitez pas télécharger sur des serveurs tiers (dans votre cas, ce serait Bitbucket). Dans ce cas, un script simple qui est exécuté une fois que vous avez extrait les données du référentiel pour restaurer les données sensibles au bon endroit résoudra ce problème.

N'oubliez pas que cette stratégie de déploiement n'est pas atomique. Il peut arriver que certains fichiers soient déjà mis à jour alors que d'autres fichiers peuvent encore être dans l'ancien état pendant que l'application est lancée. Cela peut provoquer des effets secondaires inattendus.

Une façon de faire des déploiements atomiques consiste à utiliser des liens symboliques. Créez un répertoire contenant les nouveaux fichiers. lorsque tout est prêt, modifiez un lien symbolique pour le répertoire utilisé. Si vous conservez l'ancienne version, vous pouvez également facilement revenir en arrière.

Autre possibilité (à mon avis meilleure) : utiliser un serveur de build / serveur d'intégration continue.

Brève explication courte: il s'agit d'un serveur (peut être interne, n'a pas besoin d'être sur Internet) que vous configurez pour surveiller vos référentiels, et chaque fois qu'il y a de nouveaux changements dans le référentiel, le serveur construit votre code ( AFAIK cela n'est pas nécessaire en PHP) , exécute des tests unitaires et déploie votre code sur le serveur Web.

Pour plus d'informations, consultez ces liens:

• Article Wikipedia sur CI
• Question de dépassement de capacité: à quoi sert un «Build Server»?

Il existe de nombreux produits différents pour CI , mais le seul que j'ai utilisé jusqu'à présent est TeamCity . Très facile à installer ... en fait, c'est le premier que j'ai essayé, et je l'ai tellement aimé que je m'en suis tenu.

Solution alternative bon marché:

Si la configuration d'un serveur de build demande trop d'efforts ou si vous souhaitez plus de contrôle sur le moment exact où votre site est déployé, il vous suffit de configurer un fichier de script (Batch / Powershell sur Windows ou quelque chose de similaire sur Linux / Mac) qui tire le la dernière version de votre référentiel et la transfère sur le serveur de production.

Fondamentalement, c'est la même chose qu'un serveur de build, mais plus simple.

Peu importe comment vous le résolvez à la fin ... assurez-vous de l'automatiser d'une manière ou d'une autre!

Vous voulez pouvoir déployer en un seul clic / en tapant une seule commande, afin que TOUT LE MONDE puisse le faire sans avoir à connaître quoi que ce soit de spécial et sans faire d'erreurs - même en cas de catastrophe ou de stress.

Nous faisons cela, ou des choses similaires à cela. Le @johannes non anatomique mentionne que l'angle est un problème, bien qu'en termes réalistes cela se produise si vite qu'il devrait être OK et il existe des moyens de contourner cela comme il le fait remarquer.

Probablement plus important que cette non-atomicité serait "comment gérez-vous les mises à jour du schéma de la base de données" - le déploiement de mauvais code de cette façon facilite la correction. Le gros problème est lorsque vous déployez une mise à jour qui modifie la base de données que vous souhaitez restaurer. Ou si vous effectuez de mauvaises mises à jour et corrompez des données.

L'autre problème que nous avons eu avec les outils DCVS (par opposition à l'utilisation de SVN) est que vous avez maintenant une copie de la base de code entière sur la machine quelque part qu'un attaquant pourrait potentiellement récupérer. Et aussi que cette base de code DCVS peut devenir assez lourde en termes de taille, ce qui pourrait avoir de l'importance si vous payez pour le stockage et / ou la sauvegarde. Nous utilisons toujours SVN pour le déploiement final pour ces raisons.

C'est une excellente idée, mais gardez à l'esprit les points suivants:

• Essayez de ne pas vous engager sur le serveur (même si cela arrive rarement, il est judicieux de le faire, par exemple en installant un plugin ou en ajoutant des ressources de contenu)
• Utiliser un serveur de transfert ou un déploiement de référentiel secondaire pour les tests
• Soyez toujours prudent, cela hg update -Cn'affecte pas la production (par exemple, supprimez les fichiers importants)
• Avoir une branche production et développement, déployer uniquement la branche production
• Traitez les actifs comme une sauvegarde (par exemple, des images pour le contenu) et ignorez les données utilisateur (par exemple, pièces jointes / téléchargements, cache, etc.)
• Ayez toujours une hg statussortie propre sur le serveur (cela vous aidera à vous assurer que vous ignorez les choses en tant que cache)
• Ne déployez pas le référentiel dans le dossier Web. Utilisez des liens symboliques extérieurs à l'espace public (par exemple, ln -s / myrepo / src / web / public_html / myapp)
• Attention à ne pas versionner les fichiers de configuration (spécialement avec les mots de passe de base de données ou autres)
• Ne pas utiliser à la place d'une sauvegarde de production, il s'agit d'une sauvegarde de développement pour le code de production , pas les données de production

Enfin, je pense que la chose la plus précieuse pour ajouter un DVCS à votre processus de déploiement est que cela ajoutera de la sécurité à votre déploiement, parfois les pirates informatiques injectent du code malveillant dans vos fichiers et vous n'avez vraiment aucun moyen de le détecter facilement sans quelque chose comme le contrôle de version ( spécialement distribué, car l'aspect distribué de VCS facilite la vérification de l'intégrité de vos fichiers).

Certains sites ont été piratés plusieurs fois, Mercurial m'aide à annuler littéralement ces piratages en émettant simplement un hg update -Csur le serveur (bien sûr, vous voudrez peut-être faire un hg statuset obtenir les fichiers affectés pour une analyse ultérieure).