Utiliser le dépôt hg comme site web

Question

Ceci est quelque peu lié à ma question sur la sécurité aquí . Est-ce une mauvaise idée d'utiliser un dépôt 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 y www.example.com . Si c'est une mauvaise idée d'utiliser un dépôt pour un site de production, serait-il possible d'utiliser un dépôt 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 sur le site. Les personnes techniques (ingénieurs logiciels) n'auront aucun problème à travailler avec la ligne de commande ou TortoiseHG. Je suis plus préoccupé par les personnes moins techniques (concepteurs web). Ils ne seront pas à l'aise pour travailler sur la ligne de commande, et peuvent même trouver TortoiseHG intimidant. Ces collègues de travail téléchargent principalement .css les fichiers et les images sur le serveur. J'aimerais que ces fichiers (au moins le fichier .css ) soient sous contrôle de version, mais je veux que cela soit aussi transparent que possible pour les membres non techniques de l'équipe.

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

Edit : Notre 'site' est en fait une installation CMS multi-site avec un dépôt principal et plusieurs sous-dépôts. Maquette de la structure du dépôt :

/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]

Les ingénieurs logiciels travailleront dans le root , modules y sites/global dépôts. Les personnes moins techniques (concepteurs de sites web) ne travailleraient que dans la section site1 ... siteN sous-référentiels.

Answer 1

Oui, c'est une mauvaise idée.

Ne faites pas de votre référentiel votre site web. Cela signifie que les éléments archivés, mais qui ne fonctionnent pas, seront immédiatement disponibles. Et cela signifie que les enregistrements accidentels (cela arrive) seront également répercutés en direct (c'est-à-dire des documents qui n'ont rien à faire là, etc.).

J'aborde cependant ce "concept" (le contrôle de la source en tant que déploiement) avec un outil que j'ai écrit (quelques autres sociétés abordent également ce sujet maintenant, donc vous le verrez davantage). Le mien est pour SVN (pour le moment) donc ce n'est pas particulièrement pertinent ; je le mentionne seulement pour montrer que j'ai considéré cela précédemment (pas sur un référentiel cependant ; une copie de travail, dans ce scénario la réponse est la même : mieux vaut avoir un répertoire "libre" non versionné comme répertoire du site web, et automatiser (via une action de l'utilisateur) la copie des données "versionnées" dans ce répertoire).

Answer 2

De nombreuses personnes conservent leurs sites dans des dépôts, et tant que vous n'ont pas de personnes qui éditent en direct le site en direct vous allez bien. Ayez une zone de développement où les personnes qui n'ont pas le contrôle de la révision font leurs changements, puis demandez à quelqu'un de plus favorable au RCS de faire le cycle commit-pull-merge-push périodiquement.

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

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

Answer 3

Personnellement (je suis une équipe de 1) et j'aime bien l'idée d'utiliser src control comme un site web en direct. plus avec hg, qu'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 que ftp/ssh ceci, supprimer cela, etc.

si vous utilisez apache (et probablement aussi iis), vous pouvez créer 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 se trouve sur la machine locale et fonctionne directement à partir d'un référentiel (aucune sécurité n'est vraiment requise ici, faites ce que vous voulez, livrez ce qui est nécessaire)

La machine de test est une boîte séparée ou une machine virtuelle qui exécute une copie récente de la base de données en ligne. (j'ai un script pour pousser les changements engagés vers le serveur de mise en scène et exécuter les tests)

machine en direct (ouvrir une connexion ssh, pousser les changements vers le serveur live, tester à nouveau, tout peut être scripté assez facilement, google pour des exemples)

en raison de la nature push/pull de hg, cela signifie que vous pouvez commettre des changements et tester sans le danger de pousser une construction cassée vers le site web live. comme vous le dites dans vos commentaires, seules des personnes spécifiques devraient avoir la permission de pousser une version vers le site live. (en cas d'échec, vous devriez facilement pouvoir revenir à la version précédente, via le contrôle src).

Answer 4

Pourquoi ne pas faire en sorte qu'un repo soit également un serveur web actif (pour les environnements de développement ou de test/QA de toute façon) ?

Voici ce que j'essaie de mettre en œuvre :

• Les développeurs disposent d'environnements de test locaux dans lesquels ils peuvent construire et tester leur code.
• Les développeurs créent un clone de l'environnement de développement sur leur machine de développement locale.
• Les développeurs commettent aussi souvent qu'ils le souhaitent dans leur dépôt local.
• Quand une partie du travail est terminée et testée, le développeur pousse les ensembles de modifications vers le dépôt de développement.

Les changements sont fusionnés et testés par Dev, puis poussés vers Test/QA, et ainsi de suite.

BTW, nous utilisons Mercurial. Je pense que ce modèle ne pourrait fonctionner qu'en utilisant un outil de gestion du code source distribué.