Azure DevOps Services vs Azure DevOps Server

Azure DevOps - 6 éléments pour choisir Azure DevOps Services (Cloud - ex VSTS) ou Azure DevOps Server (sur site - ex TFS)

26 Octobre 2021

Azure DevOps Services et Azure DevOps Server remplacent respectivement les anciennes versions Visual Studio Team Services et Team Foundation Server.
Azure DevOps Services est la version Cloud, hébergée dans un centre de données Microsoft Azure.
Azure DevOps Server est la version « on-premise », installée sur un ou plusieurs serveurs privés pour les composants IIS et SQL Server notamment
Comment choisir entre ces deux versions (Cloud ou sur site) ?
Voici 6 éléments pour vous guider !

1. Le coût

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

  • La licence et le niveau d'accès

  • L'utilisation

  • L'exploitation

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 : Manage paid access for users in Azure DevOps - Azure DevOps | Microsoft Docs

    La vérification des licences est stricte ! La licence affectée au compte Microsoft de l’utilisateur valide automatiquement son niveau d’accès.

    Figure 1 - Répartition des utilisateurs par niveau d'accès dans Azure DevOps Services

    Répartition des utilisateurs par niveau d’accès dans Azure DevOps
  • Azure DevOps Server : Pas de gratuité pour les 5 premiers utilisateurs techniques. Le niveau « De base » 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 ».

    Figure 2 - Les quatre niveaux d'accès de Azure DevOps Server 2020

    Les quatre niveaux d’accès de Azure DevOps

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ée 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és dans Azure DevOps (Microsoft hosted) ou installés sur des machines dédiées sur site (self Hosted).

Figure 3 - Nombre d'exécutions parallèles pour les Builds Azure DevOps Services

Nombre d’exécutions parallèles pour les Builds Azure DevOps

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ète 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. 34€ 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. 13€ 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 d’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 donc 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.

Figure 4 - Base de données de configuration sur une instance SQL Server pour Azure DevOps Server 2020

Base de données de configuration sur une instance SQL Server pour Azure DevOps Server

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 certainement l’obligation légale de stocker leurs données dans le pays de leur siège social.

Figure 5 - Choix du centre de données pour une organisation Azure DevOps Services

Choix du centre de données Azure pour une organisation Azure DevOps

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êtait le service ou proposait 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

Figure 6 - Liste des langues disponibles pour Azure DevOps Server 2020

Liste des langues disponibles pour Azure DevOps Server

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 parfois la version anglaise de Visual Studio par exemple. Mais les profils plus fonctionnels préfèrent souvent 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 paraît totalement fou de ne proposer qu’une seule langue en 2021 !

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).

Les extensions

Figure 7 - Liste des extensions d’une collection Azure DevOps

Liste des extensions d’une collection Azure DevOps

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.

Les processus de gestion de projets

La deuxième technique permet de modifier en profondeur le comportement des processus de gestion qui sont gérés au niveau de la collection pour Azure DevOps Server ou de l’organisation pour Azure DevOps Services. Pour faire simple, on peut dire qu’une collection et une organisation c’est pareil ! Par défaut, ces processus sont au nombre de quatre :

Figure 8 - Liste des processus de gestion de projets Azure DevOps

Liste des processus de gestion de projets Azure DevOps

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. Dans le cas de la figure ci-dessus, le processus personnalisé MonScrum hérite des caractéristiques du processus Scrum.

La personnalisation est toutefois limitée aux éléments de travail : leur représentation graphique (Layout) avec la liste des champs, les différents états (States) constituant le flux de travail (workflow) et enfin, les règles (Rules).

Figure 9 - Personnalisation d’un modèle de processus dans une collection héritée de Azure DevOps

Personnalisation d’un modèle de processus dans une collection héritée de Azure DevOps

Avec Azure DevOps Server, c’est un peu plus compliqué car il existe deux types de collections de projets, ce qui implique deux façons différentes de modifier les processus de gestion de projets :

  • La collection héritée qui permet de réaliser une personnalisation limitée aux éléments de travail telle que décrite ci-dessus pour Azure DevOps Services.
  • La collection xml qui regroupe la configuration des projets de la collection dans un ensemble de fichiers xml.

Figure 10 - Les deux types de collection dans Azure DevOps Server 2020

Les deux types de collection dans Azure DevOps Server

Avec Azure DevOps Server donc, 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 Process Template Editor qui reste valable pour Azure DevOps Server ! L’extension existe pour Visual Studio 2019 :
Process Template Editor - Visual Studio Marketplace.

Et là, on dispose d’une personnalisation vraiment complète et sans limites, bien au-delà de la modification des éléments de travail comme c’est le cas avec les collections héritées.

On peut ainsi, paramétrer dans le processus de gestion de projets les itérations et les zones qui seront créées en même temps que le projet d’équipe. On peut aussi agir sur les groupes de permissions et les permissions par défaut. En plus des fichiers de configuration xml, on peut également inclure dans le processus de gestion de projets des rapports par défaut (fichiers rdl) et des requêtes sur les éléments de travail (fichiers wiq).

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 version Server autorise une personnalisation complète et plus poussée mais cela doit être réservé aux utilisateurs avertis.

Conclusion

: Azure DevOps Services et Azure DevOps Server en mode collection héritée, en limitant la personnalisation, permettent de garder un cadre cohérent, même pour les migrations futures. Un autre point très positif est la possibilité de « déplacer » facilement un projet existant sur la chaîne d’héritage.

Match nul ! Personnalisation complète et plus poussée avec les collections xml de Azure DevOps version Server. Mais beaucoup plus de sécurité et de facilité d’utilisation avec Azure DevOps Services ou les collections héritées de Azure DevOps Server.

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 annuelle puisque les dernières versions sont TFS 2017, TFS 2018, Azure DevOps Server 2019 et Azure DevOps Server 2020.

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.

6. Les rapports

Pour les besoins de reporting, on peut trouver trois types de rapports disponibles pour les projets Azure DevOps

Tableaux de bord

Lorsqu’un projet d‘équipe est créé, une équipe est créée également et un tableau de bord « Overview » existe par défaut pour cette équipe mais vide de widgets.

Les tableaux de bord sont de deux types :

  • Tableau de bord d’équipe – associé à une équipe précise, les administrateurs de cette équipe peuvent modifier le tableau de bord
  • Tableau de bord du projet – global au niveau du projet.

Dans les deux cas, les tableaux de bord restent des ressources publiques et sont vus par toute personne ayant un droit d’accès que le projet d’équipe.

Un tableau de bord est constitué de widgets, éléments graphiques prêts à l’emploi qui affichent le plus souvent le résultat d’une requête sur les éléments de travail. De nombreux widgets existent et sont disponibles et des extensions peuvent être téléchargées depuis la place de marché de Visual Studio.

Cette fonctionnalité des tableaux de bord existe pour tous les projets, que ce soit avec Azure DevOps Services ou Azure DevOps Server.

Figure 11 - Tableau de bord d’un projet Azure DevOps

Tableau de bord d’un projet Azure DevOps

Vues analytiques et Power BI

Une toute nouvelle fonctionnalité (Analytics views) permet de constituer un ensemble de données à partir des ressources d’un projet d’équipe. Ces vues sont alors fournies à Power BI pour générer toute sorte de rapports personnalisés.

En octobre 2021, cette fonctionnalité est encore en « preview » et est disponible tant sur Azure DevOps Services que Azure DevOps Server.

Figure 12 - Nouvelle fonctionnalité des vues analytiques pour créer des rapports avec Power BI

Nouvelle fonctionnalité des vues analytiques pour créer des rapports avec Power BI

SQL Server Reporting Services

Une autre façon d’obtenir des rapports entièrement personnalisés est d’installer la fonctionnalité SQL Server Reporting Services et de créer des rapports rdl alimenté par le cube olap de SQL Server Analysis Services.

Toutefois, cette option n’est possible qu’avec Azure DevOps en version Server puisqu’il faut avoir la maîtrise de l’instance SQL.

Attention !! Azure DevOps Server 2020 est la dernière version qui propose cette fonctionnalité. A l’avenir, les rapports personnalisés d’un projet d’équipe Azure DevOps sera disponible uniquement avec le couple Vues analytiques – Power BI.

Figure 13 - Avertissement de la dépréciation de SQL Server Reporting Services dans Azure DevOps Server 2020

Avertissement de la dépréciation de SQL Server Reporting Services dans Azure DevOps Server

Conclusion

: La possibilité d’étendre Azure DevOps Server avec SQL Server Reporting Services va être retirée dès la prochaine version. Il restera donc les tableaux de bord et les vues analytiques.

Là encore, match nul ! Les deux types de rapport restants sont disponibles quelle que soit la version de Azure DevOps.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *