L’un des points positifs d’être consultant, est le fait de pouvoir travailler sur des problématiques d’entreprises très variées. C’est justement le cas de figure que j’ai pu rencontrer chez un client récemment, qui pour certaines raisons, sur une application, a dû externaliser son développement avec des équipes géolocalisées et qui souhaitait récupérer son code source au fur et à mesure des développements. Cette récupération devait se faire de façon automatisée afin de pouvoir être intégrée aux différents pipelines de CI/CD.

L’usine logicielle en interne chez ce client est outillée par TFS 2017 (Team Foundation Server), mais pour des questions de sécurité et d’accessibilité, ses équipes externes, ne pouvant pas accéder à ce TFS, ont dû utiliser et mettre le code dans VSTS (Visual Studio Team Services).

La problématique qui m’a été présentée est donc la suivante :

  • Comment synchroniser le code source entre VSTS vers TFS (unilatérale, uniquement dans ce sens) ? Est-ce que c’est VSTS qui va “envoyer” le code vers TFS ou à l’inverse, est-ce que c’est TFS qui va “récupérer” le code de VSTS ?

De plus, comment intégrer cette synchronisation dans les pipelines de TFS ? Enfin, comment être sûr que le code source qui va être synchronisé est le plus stable possible, sachant qu’en interne, il n’y a pas de compétences sur les langages de développement composant cette application.

Le premier élément de réponse que nous avons dû déterminer et qui va être le “master” de cette synchronisation, est la solution à cette question qui a été réfléchie en fonction de l’architecture réseau qui ne permet pas l’accès à TFS de l’extérieur. VSTS étant une plateforme cloud accessible via une connexion internet, c’est donc TFS qui récupèrera le code source archivé dans VSTS.

Cette réponse validée, il nous faut maintenant implémenter la solution technique de synchronisation.

 

Coté VSTS

Avec les développeurs travaillant sur VSTS, nous devons répondre à la problématique de la sécurité des accès au repository, mais nous devons aussi veiller à la qualité du code source qui va être synchronisé.

L’accès au repository sécurisé

Afin que TFS puisse s’authentifier à un projet VSTS sans avoir à fournir son login / mot de passe, il va falloir générer un token d’identification.

Pour sécuriser au mieux les accès de ce token, il faut cibler le plus finement possible les permissions de ce token en donnant le minimum de droits avec dans notre cas un accès en lecture seule au repository.

Ainsi, toute personne au sein de l’entreprise possédant ce token n’aura que la permission de pouvoir récupérer le code de ce repository et ne pourra pas, par exemple, modifier son code directement dans VSTS.

Comment garantir la qualité du code qui sera synchronisé ?

Pour que les développeurs délivrent du code le plus stable possible et qu’il n’y ai pas du code en cours de développement qui soit synchronisé, nous avons simplement défini une stratégie de branche pour que le code à synchroniser soit isolé des branches de développement et qu’il soit validé.

Pour ceci, dans le repository du projet de VSTS, nous avons créé une branche “releaseToTFS” dans laquelle nous avons défini des “policies” :

Ces policies imposent que :

  • Pour merger du code dans cette branche, il faut obligatoirement passer par une Pull Request, qui obligera une revue de code avant le merge.
  • Une build d’intégration continue qui simule le code une fois mergée et exécutée lors de la création du Pull request, ainsi la pull request ne pourra être complétée et validée seulement si cette build s’est exécutée correctement. On peut s’assurer que la compilation et les tests sont effectués, tout ayant un feedback très rapide avant même le merge.

Ainsi, grâce à ce token, cette branche et ces policies, nous pouvons garantir la sécurité du repository, tout en conservant une qualité de code synchronisé qui évitera les bugs sur les déploiements de l’application. En conséquence, le temps nécessaire pour effectuer des corrections par les équipes en externe s’en trouve diminué.

 

Côté TFS

Une fois que les équipes travaillant sur VSTS ont implémenté leur partie de la solution, il reste à implémenter le processus de synchronisation sur TFS.

Pour répondre à la question de l’automatisation de cette synchronisation, nous allons utiliser une build de TFS qui sera déclenchée manuellement et qui exécutera les différentes étapes de synchronisation du code.

Configuration du repository

Avant la mise en place de cette définition de build de synchronisation, nous vérifions bien les prérequis dans TFS qui sont le team project ainsi que repository Git qui va contenir le code récupéré de VSTS.

Pour permettre à la buid de mettre à jour le contenu du repository, nous modifions les permissions du compte de service de build avec des autorisations sur :

  • la création de branche
  • la contribution au repository (modifier le code)
  • la lecture du code du repository
  • la création de tags

La définition de build de synchronisation

Afin d’utiliser des outils natifs à l’entreprise et déjà présents dans les builds de TFS, nous avons utilisé l’appel à des commandes Git au sein de notre définition de build pour effectuer cette synchronisation.

Une des conditions pour qu’une build puisse faire appel à des commandes Git, est que cette définition soit rajoutée à une variable “system.prefergit” et sa valeur “true“.

Nous allons aussi autoriser les scripts de la build à utiliser l’authentification oAuth :


Nous allons ensuite configurer la source avec le repository de destination (donc celui de TFS) qui sera mis à jour, et une option de suppression de repository locale qui sera sur l’agent de build :


Quant aux étapes de la build, elles exécuteront le script suivant qui est un classique de synchronisation d’un repository local Git avec plusieurs repositories distant.

Ce script rajoute un repository distant (add remote), récupère le code de VSTS de la branche “releaseToTFS” en utilisant le token de VSTS généré (pull) et il le synchronise dans le repository TFS (push).

Intégré à la définition de build nous avons plusieurs tâches cmd qui exécutent pour chacune d’elle une commande Git de ce script.

La variable $vstsToken contient le token de VSTS et la variable $vstsRepoUri contient l’url du repository VSTS.

Remarques :

  • Dans TFS 2018 , il est possible de mettre tout ce script dans 1 seule tâche cmd en utilisant la V2.
  • La partie du script git config peut être exécutée directement de manière manuelle sur le serveur où est exécuté l’agent de build et ainsi être supprimé de la définition de build.

Ainsi lorsque la branche “releaseToTFS” est mise à jour, cette build pourra être exécutée et le repository TFS sera mis à jour avec les changements de code et pourra être déployée en interne sur les différents environnements.

Conclusion :

Nous vous partageons dans cet article un cas d’une des problématiques rencontrée chez un client entre une synchronisation entre VSTS et TFS, mais cette solution peut s’appliquer aussi pour toutes synchronisation entre TFS/VSTS et une autre plateforme de gestionnaire de sources Git comme GitHub, GitLab, etc.

Quelques références :

Voici les quelques liens qui m’ont aidé pendant l’implémentation de cette solution :

 

Livre Blanc Cell'insight 1 DevOps