Quel système de contrôle de version peut gérer tous les aspects? [fermé]

17

Il y a quelques mois, j'ai creusé dans Subversion et GIT et j'ai été déçu. Ils gèrent bien le CODE SOURCE mais pas les autres aspects. Par exemple, un site Web sous contrôle de version doit gérer la propriété des fichiers / répertoires, l'accès en lecture / écriture aux fichiers / répertoires, les listes de contrôle d'accès, les horodatages et le contenu de la base de données. et liens externes. Existe-t-il un système de contrôle de version qui peut faire une réversion aussi parfaite que le rechargement à partir d'une sauvegarde vieille d'un mois?

Andy Canfield
la source
12
Il semble que vous souhaitiez plutôt un système de sauvegarde?
Macke
2
Avez-vous envisagé d'exécuter votre site Web sous OS X sur un Mac? Time Machine est peut-être la solution de sauvegarde la plus simple actuellement disponible et facilite la restauration si nécessaire.
1
Si vous êtes sérieusement intéressé par le sujet, vous devriez jeter un œil à la recherche sur les systèmes de fichiers de version et les bases de données de version, qui vont au-delà des systèmes de contrôle de version pour le code source.
Jakob
quel est le problème d'écrire un peu de script pour gérer des choses que la scm ne gère pas? de cette façon, vous obtenez ce que vous voulez ET le mettez sous contrôle de source.
Newtopian

Réponses:

44

Vous êtes confus quant au rôle d'un système de contrôle de version. Il n'est pas et n'a jamais été conçu pour être un système de sauvegarde pour un site Web en cours d'exécution. Il fait un très bon travail de gestion de contenu statique de sorte qu'il soit entré en production de manière contrôlée. Avec une utilisation appropriée du balisage et des extractions automatisées, même les sites à changement rapide peuvent être conservés dans un système de contrôle de version.

Un système de contrôle de version sera en mesure de vous dire comment vous êtes passé du site le mois dernier à ce à quoi il ressemble aujourd'hui (au moins pour les composants sous contrôle de source). Il doit inclure tout ce dont vous avez besoin pour reconstruire le site Web (à l'exception du contenu dynamique). Comme d'autres l'ont noté, toute modification des autorisations et de la propriété doit être scriptée et ce script inclus dans le contrôle de version.

Les autorisations d'accès aux sites Web sont généralement assez simples. (Fondamentalement, vous devez vous assurer que le serveur Web peut lire tout le contenu et en écrire très peu.) À l'exception de la propriété du répertoire des quelques répertoires qui doivent être accessibles en écriture par la subversion du serveur Web, et éventuellement git, peut certainement gérer les autorisations. Les répertoires accessibles en écriture par le serveur Web contiennent généralement du contenu dynamique (créé et mis à jour à partir du site Web), qui est géré séparément de la source des sites Web.

Si on me demandait de travailler avec un site Web avec des autorisations et des listes de contrôle d'accès compliquées sur votre site Web, j'aurais de sérieuses préoccupations concernant le processus utilisé pour gérer le site Web. La mise en œuvre d'un système de contrôle de version et le déplacement des listes de contrôle d'accès vers celui-ci serait l'une des solutions que j'envisagerais sérieusement.

Le contenu dynamique, tel que les entrées de blog ou les commentaires, est généralement contenu dans une base de données ou une autre banque de données plutôt que le contrôle de version utilisé pour créer le site. Le magasin de données peut être organisé pour fournir un contrôle de version de son contenu (tout comme ce logiciel). De nombreux wikis utilisent un système de contrôle de version pour suivre les révisions.

ÉDITER:

Le correctif que j'utilise est (a) Aucun contrôle de version, (b) Le site de production est le site maître, (c) Archive chaque fois que quelque chose change, (d) Le script d'archive supprime les fichiers indésirables comme ACL, et (e) le script d'installation corrige d'autres autorisations de fichiers indésirables.

Ces problèmes peuvent être traités en important le site dans un système de contrôle de version et en modifiant votre processus afin que le site maître soit mis à jour via ce système. (a), (b) et (c) sont gérés directement par le contrôle de version. Vous voudrez peut-être baliser les versions pour que (c) fonctionne mieux. (d) n'est généralement pas un problème si vous n'avez que le système de déploiement qui modifie votre site. Je n'ai jamais eu besoin d'ACL sur le contenu du site.

(e) ne devrait être exécuté que lors de la création initiale et des modifications majeures. Il peut également inclure le script qui met à jour le site à partir du contrôle de version et s'exécute fréquemment. Ces scripts ont tendance à être assez simples lorsque vous gardez votre site dans un système de contrôle d'aversion.

Mais pourquoi personne n'a-t-il construit un système général pour ce faire?

Parce que ce n'est pas nécessaire si vous utilisez un système de contrôle de version.

Un système de contrôle de version POURRAIT suivre tout cela, mais aucun ne le fait.

CVS et Subversion suivent ce que vous devez suivre si vous les utilisez. Ils ne suivront pas ce que vous devez suivre car vous n'utilisez pas de système de contrôle de version, et ils ne devraient pas non plus le faire. Ils suivent ce que vous devez suivre lorsque vous utilisez un système de contrôle de version.

J'ai travaillé avec plusieurs sites qui ont géré leur contenu à l'aide du contrôle de version. Tous avaient des exigences différentes pour les sites intermédiaires, la fréquence de déploiement et l'exhaustivité des mises à jour. Une fois que les sites étaient sous contrôle de version, le reste des exigences était relativement facile à satisfaire. La documentation de CVS et de Subversion propose des méthodes de mise à jour possibles.

Vous devrez peut-être des listes de contrôle d'accès pour limiter l'accès à des zones particulières du contenu contrôlé par la version. Cependant, j'ai tendance à travailler sur une base de confiance. Le contrôle de version permet de voir facilement qui a fait quoi et quand. Si vous ne reformatez pas les fichiers, il est facile d'obtenir un historique annoté d'un fichier indiquant qui a ajouté quelles lignes quand.

BillThor
la source
+1 pour étoffer les raisons pour lesquelles la question est erronée dès le départ.
Macke
2
+1 Néanmoins, il est bon que la question ait été posée afin que d'autres puissent bénéficier de votre réponse.
oliver-clare
Un système de contrôle de version est censé me donner la possibilité de dire "OK, sur cet autre ordinateur ici, construisez-moi le site à partir du 28 juillet." Le contrôle de version est plus efficace que les sauvegardes car il suit les modifications. Sinon, oui, une sauvegarde quotidienne suffirait.
Andy Canfield
Oui, le correctif que j'utilise est (a) Pas de contrôle de version du tout, (b) Le site de production est le site maître, (c) Archive chaque fois que quelque chose change, (d) Le script d'archivage supprime les fichiers indésirables comme ACL, et ( e) le script d'installation corrige d'autres autorisations de fichiers indésirables. Mais pourquoi personne n'a-t-il construit un système général pour ce faire? Un système de contrôle de version POURRAIT suivre tout cela, mais aucun ne le fait.
Andy Canfield
+1: Excellente réponse. Je voudrais cependant ajouter qu'aucun système de contrôle de version ne suit ce genre de choses car ils NE POURRAIENT PAS. Les autorisations et les noms d'utilisateur sont spécifiques à l'hôte et leur format est spécifique au système; il n'y a aucun moyen que l'outil puisse les transférer automatiquement sur un hôte différent, en particulier lorsqu'il s'agit d'un système d'exploitation différent.
Jan Hudec
10

Tous et aucun d'entre eux.

C'est une mauvaise idée d'obtenir le contrôle des sources pour gérer ces détails directement, de la manière dont votre question est intimiste.

Cependant, vous pouvez écrire un script bash (* nix) ou un script powershell (Windows), qui atteint tout ou partie de ces objectifs. Ce script pourrait être stocké dans le contrôle de code source.

Ensuite, vous pouvez faire de ce script l'un de vos artefacts de génération et l'exécuter dans le cadre de votre déploiement.

pdr
la source
Cette. L'idée d'avoir des sources est que vous pouvez les retirer de votre VCS et les utiliser pour construire le produit fini.
Blrfl
2

À mon humble avis, un système de contrôle de version en soi n'est pas destiné à être utilisé de cette manière.

Mais ce que j'ai tendance à faire, c'est de m'assurer que vous pouvez obtenir une version du contrôle de code source, vous n'avez besoin d'exécuter qu'un seul fichier de construction / fichier PowerShell et tout est à nouveau opérationnel.

Pour cela, vous devez:

  • toutes les bibliothèques dont vous utilisez dépendent du contrôle de code source
  • un fichier de construction qui définit votre environnement
  • une instruction sur les exigences de votre environnement (vous ne voulez pas mettre une installation de serveur sql dans votre contrôle de code source)
KeesDijk
la source
1

Je crois que ce dont vous avez besoin dans votre cas est un outil de gestion de configuration . Celui que j'ai utilisé est une marionnette .

Vous citer:

gérer la propriété des fichiers / répertoires, l'accès en lecture / écriture aux fichiers / répertoires,

Je l'ai fait avec une seule ligne (assurez-vous que l'utilisateur existe, assurez-vous que le répertoire existe, etc.) ...

Listes de contrôle d'accès,

S'il s'agit d'ACL Windows, il existe des outils CM spécifiques pour Windows ...

horodatages,

encore une fois, la commande touch unix sur une seule ligne d'un script de marionnette pourrait le faire pour vous.

contenu de la base de données.

C'est construit dans de nombreux cadres, un travail cron qui garantit que tout y est autrement?

et liens externes.

Je n'en sais rien.

Bien sûr, après avoir écrit votre code de gestion de la configuration, vous souhaiterez peut-être le placer (ou le récupérer dans les systèmes concernés) sur un système de contrôle de version. Vous ne vous en sortirez pas :-).

Dimitrios Mistriotis
la source
Je ne comprends pas ce que vous entendez par "horodatages - encore une fois, une commande unix dans une ligne d'un script de marionnette pourrait le faire". Sur mon site, pour obtenir la version du site, il scanne l'intégralité de l'arborescence et renvoie la date et l'heure du fichier le plus récent. Je veux que mon contrôle de version "Checkout" donne aux fichiers le même horodatage qu'au moment de l'enregistrement, pas défini comme "maintenant". Comment faites-vous cela dans une commande unix?
Andy Canfield
bien sûr, vous cherchez "toucher", vérifiez ceci: en.wikipedia.org/wiki/Touch_(Unix) . Généralement, lors de la vérification, l'heure actuelle sera appliquée, mais si pour une raison quelconque vous souhaitez un horodatage différent, voici comment procéder.
Dimitrios Mistriotis
En fait, j'ai aimé la justification de votre question, vous voulez automatiser autant que possible, qui est la "bonne façon", vous avez besoin de savoir-faire sur la façon de le faire et ce qui va à VControl et ce qui ne l'est pas. Je souhaite que plus de gens dans
notre
0

Il existe un système de contrôle de version ultime qui gère tous les aspects de tous les documents numériques. Il s'appelle Xanadu et a été créé par Theodor Holm Nelson en 1960, avant même que des choses comme les systèmes de fichiers ne soient courantes. Donc, en théorie, tout est parfaitement résolu. En pratique, Xanadu n'a jamais été implémenté comme envisagé par Nelson, mais il a inspiré de nombreux systèmes plus spécialisés, y compris le Web et les systèmes de contrôle de version. Les œuvres de Nelson valent toujours une lecture fraîche - et elles peuvent répondre à la question de savoir pourquoi il n'y a pas de VCS général qui gère tous les aspects.

Jakob
la source