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 !
Il faut prendre en considération trois niveaux de coût :
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 :
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
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
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, …
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
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 :
Le détail des tarifications de Azure DevOps Services se trouve ici :
https://azure.microsoft.com/fr-fr/pricing/details/devops/azure-devops-services/
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.
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
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 :
Figure 5 - Choix du centre de données pour une organisation Azure DevOps Services
Avantage certain en terme de sécurité juridique des données des projets à Azure DevOps version Server.
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
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/
Avantage évident à Azure DevOps version Server qui, au moins, propose un vrai choix.
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).
Figure 7 - 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.
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
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
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 :
Figure 10 - Les deux types de collection dans Azure DevOps Server 2020
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.
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.
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.
Pour les besoins de reporting, on peut trouver trois types de rapports disponibles pour les projets Azure DevOps
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 :
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
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
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
Là encore, match nul ! Les deux types de rapport restants sont disponibles quelle que soit la version de Azure DevOps.
Nope
Bonjour Je travaille pour Microsoft et l'article est très bien écrit et plutôt exhaustif, plus que nos ressources internes. donc MERCI à l'auteur (dommage que vous n'affichiez pas les noms de ceux qui ont travaillé :))