De SVN à Git – Préparation de la migration

Les scripts de migration Atlassian

Si vous êtes intéressé par une transition abrupte vers Git, les scripts de migration d'Atlassian constituent un outil de choix. Ces scripts vous fournissent tous les outils dont vous avez besoin pour convertir vos dépôts SVN en dépôts Git en toute fiabilité. Résultat : l'historique Git natif garantit que vous ne devrez pas résoudre de problèmes d'interopérabilité SVN/Git après la conversion.

Nous avons élaboré une procédure technique détaillée sur l'utilisation de ces scripts pour convertir l'intégralité de votre base de code en une série de dépôts Git. Cette procédure vous explique chaque étape, de l'extraction des informations de l'auteur dans SVN à la réorganisation de structures de dépôt SVN non standard.

Plug-in SVN Mirror for Stash (désormais Bitbucket)

SVN Mirror for StashSVN Mirror for Stash est un plug-in Bitbucket qui vous permet de maintenir facilement une base de code hybride qui fonctionne aussi bien dans SVN que dans Git. Contrairement aux scripts de migration Atlassian, SVN Mirror for Stash vous permet d'utiliser Git et SVN simultanément sur un même projet, aussi longtemps que vous le souhaitez.

Cette solution intermédiaire est particulièrement appropriée pour les entreprises de plus grande taille. Elle permet une adoption incrémentielle de Git, puisque les différentes équipes peuvent migrer leur workflow à leur rythme.

Qu'est-ce que Git-SVN ?

L'outil git svn est une interface entre le dépôt Git local et un dépôt SVN distant. Git-svn permet aux développeurs d'écrire du code et de créer des commits en local avec Git, puis de les pusher vers un dépôt SVN centralisé. Le résultat sera alors similaire à celui de la commande svn commit. Cela devrait être temporaire, mais est utile pour débattre de la migration de SVN vers Git.

git svn est une bonne solution si vous n'êtes pas certain de migrer vers Git et que vous souhaitez que certains de vos développeurs explorent les commandes Git sans s'engager dans une migration complète. Cet outil est également idéal pour la phase de formation : plutôt que de devoir gérer une transition brutale, votre équipe peut s'y habituer en utilisant les commandes Git locales avant de se préoccuper des workflows de collaboration.

Remarque : git svn ne doit intervenir que temporairement dans votre processus de migration. Comme cette commande dépend toujours de SVN, elle ne permet pas d'exploiter les fonctionnalités plus puissantes de Git, comme le branching ou les workflows de collaboration avancés.

Les stratégies de déploiement

La migration de votre base de code ne constitue qu'un aspect de l'adoption de Git. Vous devez également déterminer la manière dont vous allez présenter Git aux personnes qui travaillent sur cette base de code. Trois grandes stratégies s'offrent à vous pour assurer la migration de votre équipe de développement vers Git : faire appel à des consultants externes, à des champions Git internes ou à des équipes pilotes.

Les consultants Git externes

Les consultants Git peuvent mettre en œuvre votre processus de migration pour une somme modique. L'avantage : vous obtenez un workflow Git parfaitement adapté à votre équipe sans devoir consacrer du temps à sa mise en place. De plus, des ressources de formation professionnelles sont à votre disposition pendant que votre équipe apprend à utiliser Git. Les partenaires Atlassian sont de véritables pros de la migration de SVN vers Git. Si vous recherchez un consultant Git, vous êtes à la bonne adresse.

D'un autre côté, en concevant et en implémentant un workflow Git par elle-même, votre équipe pourra comprendra les rouages internes de son nouveau processus de développement. Elle ne sera donc pas totalement perdue dès que votre consultant aura terminé sa mission.

Les champions Git internes

Un champion Git est un développeur employé par une entreprise qui a envie d'utiliser Git. Faire appel à un champion Git est une bonne solution pour les entreprises dotées d'une culture axée sur le développement avec des programmeurs enthousiastes et suffisamment à l'aise pour se lancer dans l'aventure en premier. L'idée ? Permettre à l'un de vos ingénieurs de devenir un expert Git. Il pourra alors concevoir un workflow Git adapté à votre entreprise et travailler comme consultant interne lorsque le reste de l'équipe migrera vers Git.

Par rapport à un consultant externe, l'avantage de cette solution est que vous conservez votre savoir-faire Git en interne. Former ce champion Git requiert cependant plus de temps ; de plus, vous courrez le risque de choisir le mauvais workflow Git ou de l’implémenter d'une manière inadéquate.

Les équipes pilotes

Troisième option de migration vers Git : le test sur une équipe pilote. Cette solution est idéale pour les petites équipes qui travaillent sur un projet relativement isolé. Pour un combo gagnant, vous pouvez aussi associer des consultants externes aux champions Git internes dans l'équipe pilote.

L'avantage de cette solution, c'est qu'elle nécessite l'engagement de toute votre équipe et qu'elle limite les risques de choisir le mauvais workflow. En effet, toute l'équipe participe à la conception de ce nouveau processus de développement. En d'autres termes, cette solution permet de rassembler les pièces du puzzle plus rapidement que si un consultant ou un champion concevait le nouveau workflow tout seul.

D'un autre côté, mobiliser une équipe pilote allonge la durée de formation et de configuration initiale : plutôt que d'avoir un développeur qui détermine un nouveau workflow, une équipe entière pourrait perdre temporairement en productivité pendant qu'elle s'adapte à son nouveau workflow. Cependant, cet inconvénient de courte durée en vaut vraiment la chandelle à long terme.

Sécurité et autorisations

Le contrôle des accès est un aspect de Git qui vous amène à repenser entièrement la manière dont vous gérez votre base de code.

Dans SVN, vous écrivez généralement toute votre base de code dans un seul dépôt centralisé. Vous limitez ensuite l'accès aux différentes équipes ou personnes par dossier. Dans Git, c'est impossible : les développeurs doivent extraire tout le dépôt pour travailler dessus. Généralement, vous ne pouvez pas extraire un sous-ensemble du dépôt comme avec SVN. Les autorisations peuvent uniquement être accordées à des dépôts Git entiers.

Cela signifie que vous devez diviser votre dépôt SVN monolithique en plusieurs petits dépôts Git. Chez Atlassian, nous en avons nous-mêmes fait l'expérience lorsque notre équipe de développement Jira a migré vers Git. Jusqu'à présent, tous nos plug-ins Jira étaient stockés dans un seul dépôt SVN. Après la migration, chaque plug-in s'est retrouvé dans son propre dépôt.

Gardez à l'esprit que Git a été conçu pour intégrer de manière sécurisée les contributions de milliers de développeurs Linux indépendants : il va sans dire que vous pourrez donc configurer le type de contrôle des accès dont votre équipe a besoin. Toutefois, il vous faudra sans doute revoir votre cycle de build.

Si vous tenez à conserver des dépendances entre vos nouveaux dépôts Git, une couche de gestion des dépendances en plus de Git pourrait vous être utile. Cette couche sera bénéfique pour vos builds : en effet, au fur et à mesure qu'un projet évoluera, vous devrez effectuer des mises en cache pour accélérer vos temps de build. Vous trouverez une liste de suggestions d'outils de gestion des dépendances pour toutes les piles technologiques dans cet article très utile : « Git et dépendances de projet ».

Un dépôt pour chaque développeur

En tant que développeurs, le principal changement auquel vous devrez vous adapter est la nature décentralisée de Git. Au lieu d'un seul dépôt centralisé, chaque développeur dispose de sa propre copie de tout le dépôt. Cela change considérablement la façon dont vous collaborez avec vos collègues programmeurs.

Plutôt que de faire un checkout d'un dépôt SVN à l'aide de svn checkout et d'obtenir une copie de travail, vous clonez tout le dépôt Git sur votre ordinateur local à l'aide de git clone.

La collaboration s'effectue en déplaçant des branches d'un dépôt à l'autre à l'aide des commandes git push, git fetch ou git pull. En règle générale, le partage a lieu au niveau des branches dans Git, mais il peut également s'effectuer au niveau des commits comme dans SVN. Cependant, dans Git, un commit représente l'état général du projet dans son ensemble, plutôt que des modifications de fichier. Comme vous pouvez utiliser des branches dans Git et dans SVN, la plus grande distinction à faire est qu'avec Git, vous pouvez commiter en local sans partager votre travail. Cela vous permet d'expérimenter plus librement, de travailler plus efficacement hors ligne et d'accélérer presque toutes les commandes liées au contrôle de version.

Cependant, il est important de comprendre qu'un dépôt distant n'est pas un lien direct vers le dépôt d'un autre utilisateur. Ce n'est rien de plus qu'un signet qui vous évite de saisir de nouveau toute l'URL à chaque interaction avec un dépôt distant. Jusqu'à ce que vous fassiez un pull ou un push d'une branche vers un dépôt distant, vous travaillez dans un environnement isolé.

L'autre grand changement pour les utilisateurs de SVN est la notion de dépôts « locaux » et « distants ». Les dépôts locaux se trouvent sur votre ordinateur local, et tous les autres dépôts sont appelés des dépôts distants. Le principal objectif d'un dépôt distant est de rendre votre code accessible au reste de l'équipe ; dès lors, aucun développement actif n'est effectué dans ces dépôts. Les dépôts locaux sont stockés sur votre ordinateur local ; vous y effectuez toutes vos tâches de développement.

N'ayez pas peur de créer des branches ou d'effectuer des merges

Dans SVN, vous commitez du code en modifiant des fichiers dans votre copie de travail, puis en exécutant svn commit pour transférer le code vers le dépôt centralisé. Vos collègues peuvent ensuite importer ces changements dans leur propre copie de travail avec svn update. Les branches SVN sont généralement réservées à des aspects importants et de longue durée, car les opérations de merge sont des procédures dangereuses qui pourraient scinder le projet.

Le workflow de développement de base de Git est très différent. Plutôt que d'être lié à une seule ligne de développement (p. ex., un trunk), tout tourne autour du branching et du merging.

Lorsque vous voulez travailler dans Git, vous créez une branche et en effectuez un check-out avec git checkout -b. Vous disposez ainsi d'une ligne de développement dédiée où vous pouvez écrire du code sans influer sur le travail de vos collègues. Si vous commettez une erreur irréparable, il vous suffit de supprimer la branche en exécutant git branch -d. Si vous avez développé une fonctionnalité utile, vous créez une pull request afin de merger votre travail dans la branche main.

Les workflows Git potentiels

Au moment de choisir votre workflow Git, vous devez impérativement penser aux besoins de votre équipe. Un workflow simple peut maximiser votre vitesse de développement et votre flexibilité, tandis qu'un workflow plus complexe peut assurer une meilleure cohérence et un contrôle accru du travail en cours. Vous pouvez adapter et combiner les approches générales recensées ci-dessous en fonction de vos besoins et des différents rôles au sein de votre équipe. Par exemple, un développeur interne pourrait utiliser les branches de fonctionnalité, alors qu'un sous-traitant travaillerait à partir d'un fork.

• Un workflow centralisé est la solution qui se rapproche le plus des processus SVN courants ; elle est donc idéale pour commencer.
• Partant de ce principe, l'utilisation d'un workflow de branche de fonctionnalité permet aux développeurs d'isoler leurs tâches en cours et de protéger des branches partagées importantes. Les branches de fonctionnalité servent en outre de base à la gestion des changements via les pull requests.
• Un workflow Gitflow est une version plus formelle et structurée de la création de branches de fonctionnalité. Ainsi, c'est la solution idéale pour les équipes de plus grande taille avec des cycles de livraison bien définis.
• Enfin, pensez à mettre en place un workflow de duplication (fork) si vous avez besoin d'un maximum d'isolement et de contrôle des changements, ou si beaucoup de vos développeurs travaillent dans un même dépôt.

Mais si vous voulez vraiment tirer le meilleur parti de Git en tant qu'équipe professionnelle, nous ne pouvons que vous conseiller le workflow de branche par fonctionnalité. Il s'agit d'un workflow véritablement distribué et hautement sécurisé, incroyablement évolutif et agile par excellence.

Migrer votre équipe vers Git peut sembler fastidieux, mais il peut en être autrement. Dans cet article, nous vous avons présenté quelques options courantes pour migrer votre base de code existante, déployer Git au sein de vos équipes de développement, assurer la sécurité et gérer les autorisations. Nous vous avons également exposé les plus grands défis qui attendent vos développeurs pendant le processus de migration.

Nous espérons vous avoir fourni des bases solides pour présenter le développement distribué à votre entreprise, quelles que soient sa taille ou ses pratiques de développement actuelles.