Utilisation du référentiel hg en tant que site Web

Question

Ceci est en quelque sorte lié à ma question de sécurité here. Est-ce une mauvaise idée d'utiliser un référentiel hg/mercurial pour un site web en direct? Si oui, pourquoi?

En outre, nous avons des installations de développement, de test et de production de notre site Web, comme dev.example.com, test.example.com et www.example.com. Si c'est une mauvaise idée d'utiliser un référentiel pour un site Web en direct/production, serait-il acceptable d'utiliser un référentiel hg pour les sites de développement et de test?

Je suis également préoccupé par la facilité de déploiement. Nous avons des collègues techniques et moins techniques qui travailleront avec le site. Les techniciens (ingénieurs logiciels) n'auront aucun problème à travailler avec la ligne de commande ou TortoiseHG. Je suis plus préoccupé par les gens moins techniques (concepteurs de sites Web). Ils ne seront pas à l'aise de travailler sur la ligne de commande, et peuvent même trouver TortoiseHG intimidante. Ces collègues téléchargent principalement .css des fichiers et des images sur le serveur. Je souhaite que ces fichiers (au moins les fichiers .css) soient sous contrôle de version, mais je souhaite que cela soit aussi transparent que possible pour les membres de l'équipe non technique.

Quelle est la meilleure façon d'y parvenir?

Edit: Notre 'site' est en fait une configuration CMS multi-site avec un référentiel principal et plusieurs subrepositories. La maquette de la structure du référentiel:

/root [main repository containing core files and subrepositories] 
    /modules [modules subrepository] 
    /sites/global [subrepository for global .css and .php files] 
    /sites/site1 [site1 subrepository] 
    ... 
    /sites/siteN [siteN subrepository] 

ingénieurs logiciels travailleraient dans les root, modules et sites/global dépôts. Les personnes moins techniques (concepteurs de sites Web) ne travailleraient que dans les sous-dépôts site1 ... siteN.

Answer 1

Oui, c'est une mauvaise idée.

N'utilisez pas votre référentiel comme site Web. Cela signifie que les choses enregistrées, mais non travaillées, seront immédiatement disponibles. Et cela signifie que les checkins accidentels (cela arrive) seront reflétés en direct aussi bien (c'est-à-dire des documents qui n'appartiennent pas à cet endroit, etc.). En fait, je parle de ce «concept» (contrôle de la source comme déploiement) avec un outil que j'ai écrit (quelques autres entreprises traitent également ce sujet maintenant, donc vous le verrez plus souvent). Le mien est pour SVN (pour le moment) donc ce n'est pas particulièrement pertinent; Je le mentionne seulement pour montrer que je l'ai considéré précédemment (pas sur un Repository cependant, une copie de travail, dans ce scénario la réponse est la même: mieux vaut avoir un "gratuit" non versionné comme le répertoire du site, et automatiser (via l'action de l'utilisateur) la copie des données «versionnées» vers ce répertoire).

Answer 2

Beaucoup de gens gardent leurs sites dans des dépôts, et aussi longtemps que vous n'avez pas de gens en direct-éditant le live-site vous allez bien. Avoir une zone de mise en scène/dev où vos gens de contrôle de non-révision apportent leurs modifications et ensuite avoir quelqu'un de plus convivial RCS faire le cycle de commit-pull-merge-push périodiquement.

Tant que c'est l'action consciente d'un humain qui juge la zone de mise en scène -> production-repo push vous va bien. Vous pouvez même mettre un crochet dans le clone de production qui effectue automatiquement une 'mise à jour hg' du répertoire de travail dans ce clone de production, de sorte que 'push' soit tout ce qu'il faut pour le déployer.

Cela dit, je pense que vous sous-estimez votre équipe web ou tortoiseHg; ils peuvent l'obtenir.

Answer 3

moi personnellement (je suis une équipe de 1) et j'aime bien l'idée d'utiliser le contrôle src comme un site web en direct.plus encore avec hg, puis avec svn.

la façon dont je le vois, vous pouvez charger un site entier, (ajouter/supprimer des fichiers) avec un seul cmd beaucoup plus facile alors ce ftp/ssh, supprimez ce etc

si vous utilisez apache (et probablement iis aussi) vous pouvez faire un simple fichier .htaccess qui bloquera tous les fichiers .hg (ou .svn si vous utilisez svn)

ma structure préférée est le site de développement est sur la machine locale fonctionnant directement sur un référentiel (aucune sécurité n'est vraiment requise ici, faites ce que vous voulez commettre au besoin)

mise en scène/machine de test est une boîte séparée ou Vm en cours d'exécution d'une récente copie de la base de données en direct (j'ai un script pour pousser les changements engagés à mettre en scène le serveur et exécuter des tests)

la machine en direct (ouverte connexion ssh, appuyez sur les changements en raison de la nature push/pull de hg, cela signifie que vous pouvez commettre des changements et tester sans risquer de pousser un build cassé à la vie site Internet. Comme vous le dites dans vos commentaires, seules certaines personnes devraient avoir la permission de pousser une version sur le site en direct. (si cela échoue, vous devriez facilement pouvoir revenir à la version précédente, via le contrôle src)

Answer 4

Pourquoi ne pas avoir un repo aussi être un serveur web actif (pour l'environnement de développement ou de test/QA de toute façon)?

Voici ce que je suis en train de mettre en œuvre:

• Les développeurs ont des environnements de test locaux où ils peuvent construire et tester leur code
• Les développeurs font un clone de l'environnement de dev sur leur machine dev locale
les développeurs
• engagent aussi souvent qu'ils veulent leur pension locale
• Lorsque morceau de travail est fait et testé, puis développeur pOUSSE changement de travail fixe pour dev repo

Les modifications seraient fusionnées et testées sur Dev, puis transmises à Test/QA, et ainsi de suite.

BTW, nous utilisons Mercurial. Je crois que ce modèle fonctionnerait seulement en utilisant un outil distribué de gestion de code source.