Azure DevOps – 5 éléments pour choisir entre Services (ex VSTS) et Server (ex TFS)

25 Juin 2019

Azure DevOps Services est le nouveau nom de Visual Studio Team Services.
Azure DevOps Server est le nouveau nom de Team Foundation Server.
Comment choisir entre ces deux versions (Cloud ou sur site) ? 5 éléments pour vous guider !

Le coût

Il faut prendre en considération trois niveaux de coût :

  • La licence et le niveau d’accès
  • L’exploitation
  • L’utilisation

Licence/niveau d’accès

: les niveaux d’accès s’appuient sur la licence de l’utilisateur. Sur ce point, Azure DevOps Services comme Azure DevOps Server distinguent l’utilisateur fonctionnel de l’utilisateur technique. L’utilisateur fonctionnel n’interviendra pas sur le code et ne disposera donc pas d’éditeur de code. Le niveau d’accès « Participant /Stakeholder » lui conviendra pour accéder aux éléments de travail et aux tableaux de bord ou Kanban du projet. Ce premier niveau d’accès ne requiert pas de licence d’accès client. L’accès est donc gratuit pour les utilisateurs fonctionnels.

En revanche, l’utilisateur technique devra obtenir une licence pour accéder aux niveaux supérieurs, ceux qui autorisent l’accès au code-source et à la gestion des tests. Ce sera généralement le cas grâce à la licence Visual Studio qui inclut une licence d’accès client (CAL). Le type de licence Visual Studio (Professional ou Enterprise) définira le niveau d’accès Azure DevOps.

Ici interviennent les différences entre Azure DevOps Services et Azure Devops Server :

  • Azure DevOps Services : 5 utilisateurs techniques, dépourvus de licence Visual Studio, peuvent avoir un accès « Basic » gratuit. L’accès sera payant à partir du sixième utilisateur technique. Le coût d’accès pour x utilisateurs : https://marketplace.visualstudio.com/items?itemName=ms.vss-vstsuser#pricing
    La vérification des licences est stricte ! La licence affectée au compte Microsoft de l’utilisateur valide automatiquement son niveau d’accès.
  • Server : Pas de gratuité pour les 5 premiers utilisateurs techniques. Le niveau « Basic » correspond en fait au niveau autorisé par une licence Visual Studio Professional.
    La vérification des licences se fait « sur l’honneur » ! Techniquement, rien n’interdit de positionner l’ensemble des utilisateurs sur le niveau « Visual Studio Enterprise ».

Exploitation

Pour Azure DevOps Services, il n’y a pas besoin de prévoir les mises à jour matériel, système, anti-virus ou autres. On est vraiment sur un mode SaaS où on utilise le logiciel à la demande. Le coût d’exploitation est donc quasi-nul.

Evidemment avec Azure DevOps Server, il convient de procéder au maintien régulier du serveur ou des serveurs de l’instance en situation opérationnelle : mises à jour des patchs de sécurité, sauvegarde régulière des bases de données, mise en place d’un plan de relance, vérification de la disponibilité des instances IIS et SQL, …

Utilisation

L’utilisation intensive de Azure DevOps Server n’implique aucun coût supplémentaire à condition d’installer tous les agents de Build sur des machines locales.

Ce qui suit concerne donc exclusivement Azure DevOps Services.

Une fois réglé la question des licences, qui conditionnent les niveaux d’accès, le coût d’utilisation réside essentiellement dans les durées de Build et l’offre de test.

On pourra définir des Builds sur des pools d’agents hébergées dans Azure DevOps (Microsoft hosted) ou installés sur des machines dédiées sur site (self Hosted).

Utiliser les agents de Build installés est limité en nombre de tâches simultanées. Alors qu’utiliser les agents de Build hébergés implique en plus une limitation de durée de traitement des Builds.

Concernant la gestion des tests, une petite bizarrerie : il faut une licence Visual Studio Enterprise pour accéder pleinement au « Test Plans » ! Alors que, typiquement, la gestion des tests fonctionnels n’échoie pas aux profils techniques… Il faudra donc ajouter en supplément l’offre de test pour les profils fonctionnels, qui ont pourtant accès de manière gratuite, mais limitée, aux projets sous Azure DevOps Services.

Voilà un résumé des coûts d’utilisation supplémentaires à prévoir avec Azure DevOps Services :

  • Profils techniques (accès à la gestion du code) sans licences Visual Studio :
    1. 5 premiers gratuits en niveau d’accès « Basic »
    2. Puis 5€ mensuel par utilisateur
  • Gestion complètes des tests (Test Plans) : 44€ mensuel par utilisateur
  • Builds hébergées par Microsoft :
    1. 1800 minutes gratuites par mois et par organisation (collection de projets)
    2. 33€ par travail parallèle supplémentaire avec durée de build illimitée
  • Build auto-hébergées :
    1. Nombre de tâches en parallèle : 1 + nb licences VS Enterprise
    2. 12€ par tâche supplémentaire

Le détail des tarifications de Azure DevOps Services se trouve ici :
https://azure.microsoft.com/fr-fr/pricing/details/devops/azure-devops-services/

Conclusion

: Une entreprise qui a souscrit pour tous ses développeurs une licence Visual Studio Enterprise pourra bénéficier pleinement de Azure DevOps en version Services sans se préoccuper de l’installation et de l’exploitation. Il faudra juste installer les agents de Build en local pour optimiser les coûts d’utilisation.

Au contraire, sans licence Visual Studio Enterprise, la version Services de Azure DevOps peut vite s’avérer coûteuse pour des Builds lourdes et fréquentes et la gestion des tests. Azure DevOps Server deviendra alors une solution intéressante malgré les coûts d’installation et d’exploitation des serveurs.

Match nul entre les versions Server et Services. Le choix dépendra de l’utilisation prévue et de la disponibilité de licences Visual Studio Enterprise.

2. Les données

Toutes les données d’un projet Azure DevOps sont stockées dans une base SQL Server ou Azure : les éléments de travail, les permissions et droits d’accès, les archivages de code, les définitions de Build et de Release, les résultats des tests, etc.

Dans le cas de Azure DevOps Server, anciennement Team Foundation Server, il existe une base de configuration, qui retient les caractéristiques de toute l’instance du ou des serveurs, et une base SQL pour chacune des collections de projets d’équipe. Toutes ces bases sont hébergées sur le serveur SQL (ou le cluster dans le cas de très grosses installations) choisi par l’entreprise. Cette dernière peut héberger les bases TFS et les données de tous les projets sur un serveur interne, un cloud privé ou sur une VM dans Azure par exemple. L’entreprise garde donc complètement la main sur les données, leur accès et le lieu de leur hébergement.

Dans le cas de Azure DevOps Services, la gestion des données des projets d’équipe dans des bases SQL Azure est évidemment complètement transparente. Ce qui amène deux problèmes majeurs :

  1. Il n’existe actuellement, en juin 2019, aucun moyen de récupérer l’ensemble des données des projets de Azure DevOps Services !! La migration dans le sens TFS vers Azure DevOps Services est largement encouragée par Microsoft. La migration dans le sens inverse n’est pas prévue…
  2. En Europe, le seul centre de données proposé est celui de « West Europe », situé près d’Amsterdam. Cela peut-être un frein juridique au stockage de certaines données, contenues dans des scripts SQL archivés dans le projet Azure DevOps Services par exemple. Certaines entreprises ont probablement l’obligation légale de stocker leurs données dans le pays de leur siège social.

Conclusion

: Concernant l’intégrité et l’accès aux données des projets dans le temps, il faut vraiment faire confiance à Microsoft ! Même si c’est hautement improbable, que se passerait-il si Microsoft arrête le service ou propose soudainement des tarifs en forte hausse ?

Avantage certain en terme de sécurité juridique des données des projets à Azure DevOps version Server.

3. La langue

Azure DevOps Server, tout comme son prédécesseur Team Foundation Server et la quasi-totalité des produits Microsoft, est un logiciel multilingue : https://docs.microsoft.com/fr-fr/azure/devops/server/requirements?view=azure-devops#languages

Azure DevOps Services n’est disponible qu’en anglais !

Pourtant, ce ne sont pas les demandes qui manquent pour du multilinguisme, comme en atteste le lien suivant :
https://developercommunity.visualstudio.com/idea/365587/localization-support-for-team-services.html

Cette absence de choix de la langue pour Azure DevOps Server peut constituer un frein pour certaines organisations. Généralement, les profils techniques sont habitués à travailler avec l’anglais technique. Les développeurs ont souvent la version anglaise de Visual Studio par exemple. Mais les profils plus fonctionnels préfèrent avoir le confort de travailler dans leur langue.

Il existe aussi une obligation juridique stipulant qu’une entreprise doit mettre à disposition de ses employés français des logiciels en langue française : http://www.entreprise-et-droit.com/le-francais-dans-lentreprise/

Conclusion

: Cela parait totalement fou de ne proposer qu’une seule langue en 2019 !

Avantage évident à Azure DevOps version Server qui, au moins, propose un vrai choix.

4. La personnalisation

On a souvent besoin de fonctionnalités additionnelles ou de modifier les processus de gestion de projets existants afin de se rapprocher le plus possible des usages internes de notre entreprise…
Azure DevOps, Services comme Server, propose deux techniques principales pour adapter son fonctionnement. Rien de bien nouveau ici ! La personnalisation était déjà largement présente du temps de Team Foundation Server (TFS) et de Visual Studio Team Services (VSTS).

Un nombre impressionnant d’extensions se trouve dans la place de marché de Azure DevOps : https://marketplace.visualstudio.com/azuredevops. Ces extensions permettent d’enrichir les fonctionnalités proposées par défaut dans les cinq rubriques principales : Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans et Azure Artifacts.

Pour Azure DevOps Services, on installe directement dans l’organisation voulue.

Pour Azure DevOps Server, on télécharge d’abord l’extension en vue de son installation sur le serveur interne.

La deuxième technique permet de modifier en profondeur le comportement des processus de gestion. Par défaut, ces processus sont au nombre de quatre :

Avec Azure DevOps Services comme Azure DevOps Server, il est possible d’hériter l’un de ces quatre processus par défaut afin d’effectuer une personnalisation. Dane le cas de la figure ci-dessus, le processus personnalisé MonScrum hérite des caractéristiques du processus Scrum.

Avec Azure DevOps Server seulement, la technique de personnalisation d’un processus par héritage reste valable mais on peut également carrément définir un tout nouveau process par la configuration d’un ensemble de fichiers xml. Pour ce faire, on utilise toujours le fameux TFS Process Template Editor qui reste valable pour Azure DevOps Server ! L’extension existe pour Visual Studio 2017 mais n’est pas encore disponible (en juin 2019) pour Visual Studio 2019 :
https://marketplace.visualstudio.com/items?itemName=KarthikBalasubramanianMSFT.TFSProcessTemplateEditor&ssr=false#overview

Conclusion

: Attention !! Modifier en profondeur un modèle de processus, voire en créer un totalement nouveau n’est pas sans conséquences ! Une migration peut devenir très compliquée si les processus ont beaucoup évolué.

Azure DevOps Services, en limitant la personnalisation, permet de garder un cadre cohérent.

Personnalisation complète et plus poussée avec Azure DevOps version Server. A réserver toutefois aux utilisateurs avertis.

5. La mise à jour

La version Services de Azure DevOps est développée en mode Agile avec des Sprints d’une durée de trois semaines : https://docs.microsoft.com/en-us/azure/devops/release-notes/

Cela signifie bien sûr qu’une instance Azure DevOps Services est toujours à jour des corrections de bugs et des ajouts de nouvelles fonctionnalités.

La version Server de Azure DevOps, elle, est proposée en version, généralement une année, comprenant chacune trois mises à jour, les « update ». Ainsi TFS (Team Foundation Server) 2017 et 2018 sont disponibles en :

  • TFS 2017/2018
  • TFS 2017/2018 Update 1
  • TFS 2017/2018 Update 2
  • TFS 2017/2018 Update 3

En juin 2019, seule la version de base de Azure DevOps Server 2019 est sortie. Il n’y a pas encore de version « Update X».

Conclusion

: Il n’y a pas photo sur ce critère. Azure DevOps Services est toujours à jour et, surtout, la mise en place des dernières versions successives est complètement transparente.

Azure DevOps Services : toujours à jour sans rien avoir à faire !