Comment s'assurer que mon code de dépôt git est sécurisé?

Question

Si notre organisation devait passer d'un VCS à serveur central, tel que Subversion, à un VCS distribué, tel que git, comment puis-je m'assurer que tout mon code est protégé contre les pannes matérielles?

Avec un VCS à serveur central, je dois juste sauvegarder le référentiel tous les jours. Si nous utilisions un système DVCS, il y aurait beaucoup de branches de code sur toutes les machines des développeurs, et si ce matériel échouait (ou si un développeur perdait son ordinateur portable ou le volait), nous n'aurions aucune sauvegarde. .

Notez que je ne considère pas comme une bonne option "de faire en sorte que les développeurs transfèrent les branches vers un serveur". - C’est fastidieux et le les développeurs finiront par ne pas le faire.

Existe-t-il une solution commune à ce problème?

Quelques précisions:

Avec un VCS à serveur central natif, tout doit se trouver sur le serveur central à l'exception des dernières modifications apportées par le développeur. Ainsi, par exemple, si un développeur décide de créer une branche pour faire un correctif, cette branche se trouve sur le serveur central et est immédiatement disponible pour la sauvegarde.

Si nous utilisons un DVCS, le développeur peut créer une branche locale (et en fait plusieurs branches locales). Aucune de ces branches n’est sur le serveur central et disponible pour la sauvegarde tant que le développeur n’a pas réfléchi, "ah oui, je devrais le transmettre au serveur central".

Donc, la différence que je vois (corrigez-moi si je me trompe!): les fonctionnalités et corrections de bugs implémentées à moitié ne seront probablement pas disponibles pour la sauvegarde sur le serveur central si nous utilisons un DVCS, mais avec une résolution normale VCS. Comment garder ce code en sécurité?

Answer 1

Je pense que vous constaterez que, dans la pratique, les développeurs préfèrent utiliser un référentiel central plutôt que de placer et d'extraire entre les référentiels locaux les uns des autres. Une fois que vous avez cloné un référentiel central, tout en travaillant sur les branches de suivi, extraire et pousser sont des commandes triviales. Ajouter une demi-douzaine de télécommandes aux référentiels locaux de vos collègues est une tâche ardue et ces référentiels peuvent ne pas toujours être accessibles (éteints, sur un ordinateur portable emporté à la maison, etc.).

À un moment donné, si vous travaillez tous sur le même projet, tout le travail doit être intégré. Cela signifie que vous avez besoin d’une branche d’intégration où tous les changements se rejoignent. Cela doit naturellement être accessible à tous les développeurs, cela n'appartient pas, par exemple, à l'ordinateur portable du développeur principal.

Une fois que vous avez configuré un référentiel central, vous pouvez utiliser un workflow de style cvs / svn pour l'archivage et la mise à jour. cvs update devient git fetch et rebase si vous avez des modifications locales ou simplement git pull si vous ne le faites pas. cvs commit devient git commit et git push.

Avec cette configuration, vous vous trouvez dans une position similaire avec votre système VCS entièrement centralisé. Une fois que les développeurs ont soumis leurs modifications (git push), ce qu'ils doivent faire pour être visibles par le reste de l'équipe, ils se trouvent sur le serveur central et seront sauvegardés.

Dans les deux cas, il faut de la discipline pour empêcher les développeurs de conserver des modifications longues en dehors du référentiel central. La plupart d'entre nous ont probablement travaillé dans une situation où un développeur travaille sur la fonctionnalité 'x' qui nécessite une modification fondamentale de certains codes centraux. Cette modification entraînera une reconstruction complète de tous les autres utilisateurs, mais la fonctionnalité n’est pas encore prête pour le flux principal. Il la conserve donc jusqu’à un moment opportun.

La situation est très similaire dans les deux situations bien qu’il existe certaines différences pratiques. Grâce à git, étant donné que vous devez effectuer des validations locales et que vous pouvez gérer l’historique local, la nécessité de transmettre au référentiel central risque de ne pas être ressentie autant par le développeur que par quelque chose comme cvs.

Par contre, l’utilisation d’engagements locaux peut être un avantage. Il ne devrait pas être très difficile de placer tous les commits locaux dans un endroit sûr sur le référentiel central. Les branches locales peuvent être stockées dans un espace de noms de balises spécifique au développeur.

Par exemple, pour Joe Bloggs, un alias peut être créé dans son référentiel local pour effectuer les opérations suivantes en réponse à (par exemple) git mybackup .

git push origin +refs/heads/*:refs/jbloggs/*

Il s'agit d'une commande unique qui peut être utilisée à tout moment (par exemple en fin de journée) pour s'assurer que tous ses changements locaux sont sauvegardés en toute sécurité.

Cela aide avec toutes sortes de catastrophes. La machine de Joe explose et il peut utiliser une autre machine et récupérer les commits enregistrés et continuer là où il s'était arrêté. Joe est malade? Fred peut aller chercher les branches de Joe pour s'emparer de la réparation "indispensable" qu'il a faite hier mais n'a pas eu l'occasion de se mesurer au maître.

Pour revenir à la question initiale. Faut-il une différence entre dVCS et VCS centralisé? Vous dites que les fonctionnalités à moitié implémentées et les corrections de bugs ne se retrouveront pas dans le référentiel central dans le cas de dVCS, mais je soutiendrais qu'il ne doit y avoir aucune différence.

J'ai souvent constaté qu'une fonctionnalité implémentée à moitié restait dans la boîte de travail d'un développeur lors de l'utilisation d'un VCS centralisé. Il faut soit une politique autorisant l’archivage de fonctionnalités semi-écrites dans le flux principal, soit la décision de créer une branche centrale.

Dans le dVCS, la même chose peut arriver, mais la même décision doit être prise. S'il existe un travail important mais incomplet, il doit être sauvegardé de manière centralisée. L’avantage de git est que la création de cette branche centrale est presque triviale.

Answer 2

Je pense que le fait que l’utilisation d’un VCS distribué signifie nécessairement que vous devez l’utiliser de manière totalement distribuée est une erreur. Il est tout à fait correct de configurer un référentiel git commun et de dire à tout le monde qu’il est le référentiel officiel. Pour un flux de travail de développement normal, les développeurs extraient les modifications du référentiel commun et mettent à jour leurs propres référentiels. Deux développeurs collaborant activement sur une fonctionnalité spécifique pourraient avoir besoin d'extraire les modifications directement l'un de l'autre.

Compte tenu du nombre de développeurs travaillant sur un projet, il serait extrêmement fastidieux de penser aux modifications apportées par tous les autres. Que feriez-vous si vous n'aviez pas de référentiel central?

Au travail, nous avons une solution de sauvegarde qui sauvegarde quotidiennement les répertoires de travail de tout le monde et écrit le tout sur un DVD hebdomadaire. Ainsi, bien que nous ayons un référentiel central, chaque fichier individuel est également sauvegardé.

Answer 3

Il n’est pas rare d’utiliser un "central". serveur en tant qu’autorité dans DVCS, ce qui vous fournit également le lieu de faire vos sauvegardes.

Answer 4

Je trouve cette question un peu bizarre. En supposant que vous utilisiez un système de contrôle de version non distribué, tel que CVS, vous aurez un référentiel sur le serveur central et travaillerez en cours sur les serveurs des développeurs. Comment sauvegardez-vous le référentiel? Comment sauvegardez-vous le travail en cours des développeurs? La réponse à ces questions est exactement ce que vous devez faire pour traiter votre question.

À l'aide du contrôle de version distribuée, les référentiels sur les serveurs de développeurs sont simplement en cours de développement. Voulez-vous le sauvegarder? Alors sauvegardez-le! C'est aussi simple que cela.

Nous avons un système de sauvegarde automatisé qui récupère tous les répertoires de nos machines que nous spécifions. Par conséquent, j’ajoute tous les référentiels et toutes les copies de travail sur ma machine, y compris les référentiels git et CVS.

Soit dit en passant, si vous utilisez le contrôle de version distribué dans une entreprise publiant un produit, vous aurez un référentiel central. C'est celui que vous libérez. Ce n'est peut-être pas sur un serveur spécial; cela pourrait être sur le disque dur de certains développeurs. Mais le référentiel que vous libérez est le référentiel central. (Je suppose que si vous n'êtes pas encore sorti, vous n'en avez peut-être pas encore.) J'ai en quelque sorte l'impression que tous les projets ont un ou plusieurs référentiels centraux. (Et vraiment, s’ils en ont plus d’un, c’est deux projets et l’un est une fourchette.) Cela vaut également pour l’open source.

Même si vous n'aviez pas de référentiel central, la solution est la même: effectuer des sauvegardes sur les machines des développeurs. Vous auriez dû le faire de toute façon. Le fait que le travail en cours se trouve dans des référentiels distribués au lieu de copies de travail CVS ou de répertoires non versionnés est sans importance.

Answer 5

Les répertoires de départ des développeurs peuvent monter des périphériques distants sur le réseau local. Il ne vous reste alors plus qu'à vous soucier de sécuriser le stockage réseau. Ou peut-être pourriez-vous utiliser quelque chose comme DropBox pour copier votre dépôt local ailleurs en toute transparence.

Answer 6

Tous les développeurs de votre équipe peuvent également avoir leurs propres succursales sur le serveur (par ticket ou juste par dev, etc.). De cette façon, ils ne cassent pas la branche principale de construction, mais ils peuvent toujours pousser leur travail en cours sur le serveur qui est sauvegardé.

Mon propre outil git_remote_branch peut être utile pour ce type de flux de travail (notez qu'il nécessite Ruby). Cela facilite la manipulation des branches distantes.

En guise de remarque, en ce qui concerne la sécurité des dépôts, vous pouvez configurer sur votre serveur un hook post-commit qui effectue un simple clone git ou un push git sur une autre machine ... Vous obtenez une sauvegarde à jour après chaque commit. !

Answer 7

Nous utilisons rsync pour sauvegarder les répertoires .git des développeurs individuels dans un répertoire du serveur. Ceci est configuré en utilisant des scripts wrapper autour de git clone, et des hooks post-commit, etc.

.

Etant donné que cela se fait dans les hooks post- *, les développeurs n'ont pas besoin de se rappeler de le faire manuellement. Et comme nous utilisons rsync avec un délai d'expiration, si le serveur tombe en panne ou si l'utilisateur travaille à distance, ils peuvent toujours fonctionner.