Introduction
En ces jours de confinement, la majorité des développeurs a recours au télétravail. Fort heureusement, de nombreuses solutions en ligne existent pour versionner, construire et déployer les applications de nos clients.
Chez Publicis Sapient Engineering, un certain nombre de projets utilisent GitLab, Bitbucket ou encore Github en mode SaaS pour héberger leurs sources et pour gérer la partie CI et CD. Pour la plupart, ces projets sont déployés dans le Cloud sur AWS, GCP ou encore Azure. Pour ces équipes, les outils et les processus restent sensiblement les mêmes en télétravail.
Cependant, certains clients ont fait le choix d’utiliser des outils on-premise, bien souvent accessibles uniquement depuis leur réseau interne. Pour y accéder à distance, il faut alors utiliser des solutions comme un VPN, ou encore une VDI. Cette dernière consiste à se connecter sur un bureau à distance, généralement une machine virtuelle. Ces techniques ont le défaut d’offrir des performances toutes relatives qui dépendent de nombreux facteurs comme la connexion Internet de l’utilisateur, la puissance des machines virtuelles, mais aussi du nombre d’utilisateurs connectés simultanément. C’est d’autant plus vrai en ce moment, car les entreprises, dans leur majorité, n’ont jamais dimensionné ces dispositifs pour supporter la connexion de l’ensemble de leurs collaborateurs.
Cette solution rend alors le développement plus complexe à cause des deux problématiques suivantes :
- Comment faire pour continuer à communiquer avec l’équipe au sens large (développeurs, fonctionnels, PO, …) ?
- Sur quel environnement puis-je continuer à travailler ? Sur mon poste ou dois-je utiliser le bureau à distance ?
C’est notre projet
Dans le cadre de notre projet, le premier point s’est résolu assez rapidement. Comme beaucoup de projets, nous utilisons déjà Slack au jour le jour (pour les demandes de relecture de code, échanger sur des points techniques, prévenir de déploiements à venir, etc). Pour les réunions (daily, spring planning, backlog refinements), nous utilisons Zoom, qui fonctionne plutôt bien, même s’il existe quelques limites qui peuvent être contraignantes.
C’est plutôt le second point qui a été plus difficile à adresser. Nous vous donnons quelques éléments de réponse dans la suite de cet article.
En effet, nous sommes chez un client qui a fait le choix du on-premise. La majorité des outils dont nous avons besoin comme GitLab, JIRA, Confluence, les environnements de développement, d’intégration, ou encore Skype, ne sont accessibles que sur le réseau interne du client.
Cependant, le client a pu nous mettre à disposition une VDI qui nous permet d’avoir accès au réseau interne via un bureau à distance. Malgré cela, comme indiqué en introduction, il est assez difficile de développer dans cet environnement qui souffre régulièrement de lenteurs.
Nous avons donc fait le choix de continuer à développer sur nos machines hôtes, comme nous le faisions sur place, mais sans l’accès à GitLab. Il a ainsi fallu trouver une solution pour rester synchronisé avec le dépôt GitLab distant. C’est la commande git bundle qui est venue à notre rescousse.
En effet, cette commande permet de créer un fichier qui contient un ensemble de commits. Il suffit pour cela de lui donner un intervalle de révisions pour construire un patch. A l’inverse d’autres solutions comme la commande git format-patch, le fichier généré – on parle alors de bundle – va conserver les identifiants de commits ce qui est essentiel pour obtenir un historique identique au dépôt distant.
La solution magique
Mettre à jour son dépôt local
Tout d’abord, nous cherchons à mettre à jour notre branche master locale. Pour ce faire il faut récupérer le numéro du dernier commit local, pour savoir d’où nous partons.
En local
git rev-parse HEAD
Dans notre cas cette commande retourne efb259382f547f5c4988441b5e069ea98787656c.
Dans la VDI
Ensuite, il faut se connecter à la VDI pour avoir accès au GitLab distant. Si c’est la première fois que nous travaillons avec ce dépôt, il faut bien évidemment le cloner.
git clone git@gitlab.myclient.com:user/super-project.git
C’est à ce moment que la commande magique intervient. Nous allons créer un bundle contenant nos commits manquants :
git checkout master git bundle create master.bundle efb259382f547f5c4988441b5e069ea98787656c..HEAD
Le fichier master.bundle est alors créé : il contient l’ensemble des commits correspondant à l’intervalle fourni. Il suffit alors de l’envoyer vers notre machine hôte que ce soit par e-mail, Slack ou toute autre solution et le sauvegarder par exemple dans le dossier ~/Downloads.
En local
De retour sur notre terminal local, nous n’avons plus qu’à utiliser la commande suivante :
git pull ~/Downloads/master.bundle
Tada ! Le dépôt local est maintenant à jour.
Facile à vérifier avec la commande git log. Évidemment, il est possible de réaliser de nouveau cette procédure dès que nécessaire.
Pousser une branche de feature sur le dépôt distant
Pour envoyer nos modifications effectuées sur – par exemple – une branche de feature, il est possible de faire la même chose. Dans notre cas, nous voulons créer un patch contenant le différentiel entre le master local et notre branche courante, donc HEAD.
En local
git checkout my-feature-branch git bundle create my-feature.bundle master..HEAD
Cette fois-ci, il faut envoyer le patch vers la VDI.
Dans la VDI
Un peu comme précédemment avec le clone, si c’est la première fois que nous envoyons des modifications il faut créer la branche.
git checkout -b my-feature-branch
Encore une fois il faut utiliser la commande git pull pour appliquer les commits du bundle sur notre branche.
git pull ~/Downloads/my-feature.patch
Il faut aussi pousser la branche sur le dépôt distant.
git push --set-upstream origin my-feature-branch
Voilà, il ne reste plus qu’à créer la Pull Request, ou Merge Request .
Comme la méthode précédente, il est possible de répéter ces opérations pour envoyer autant de commits que nous le souhaitons vers le dépôt. A noter que la commande git pull est assez intelligente pour ignorer les commits présent dans le bundle qui existeraient déjà dans le dépôt cible.
Ce n’est pas tout : que faire lorsque notre Merge Request aura été validée et mergée dans le dépôt distant ? Que faire de notre branche locale ? Faut-il la merger elle aussi ?
Pour rester synchronisé avec le dépôt distant en conservant le même historique (et les mêmes identifiants de commit), il est conseillé de supprimer sa branche locale et de suivre la procédure ci-dessus : « Mettre à jour son dépôt local ».
Travailler de manière collaborative
Les commandes présentées remplacent les traditionnels git pull et git push, mais en plus complexe. Ainsi, il est possible de travailler quasiment de la même manière qu’avant quand il n’y avait pas les contraintes de la VDI. Cela inclus le travail collaboratif de plusieurs développeurs sur une même branche. Cependant, cela demande davantage de rigueur, en effet, il est moins facile de se mettre à jour et ainsi d’intégrer les modifications faites par les autres développeurs.
C’est pourquoi il faut communiquer plus, ne pas hésiter à prévenir quand des modifications ont été poussées sur le dépôt distant. De plus, avant de pousser des modifications, il est aussi recommandé de mettre à jour sa branche locale avant d’envoyer son bundle vers la VDI. Cela vous permettra de régler les conflits en local plutôt que dans la VDI, dans laquelle vous n’avez pas forcément les outils adéquats pour faire des diffs efficients, ou même pour lancer les tests de votre application.
Conclusion
Bien évidemment, la solution décrite dans cet article n’est pas idéale, il aurait été plus simple d’utiliser un gestionnaire de versions en ligne. Cependant, dans notre cas, cette dernière solution n’est pas envisageable car proscrite par le client pour des raisons de sécurité. Seule l’utilisation de notre boîte e-mail pro est tolérée pour réaliser ce travail d’équilibriste.
En cette période de confinement difficile dans laquelle nous sommes, il est intéressant de voir que nous finissons toujours par trouver des solutions de contournement aux problématiques liées au télétravail.
A votre tour n’hésitez pas à partager vos tips en commentaire !
N’oublions pas de rester positif et bon remote à tous !