Voici la suite de l’article : DevOps : Définition

Je vais commencer par créer un logiciel. Ce projet personnel va me permettre d’allier deux passions : le développement et le poker. Je vous vois venir de loin : non je ne vais créer un bot pour jouer à ma place et ramasser plein d’argent. Je joue dans une association et le logiciel va être un site web destiné à gérer le club, les membres, les évènements, les classements, etc..

Ce logiciel servira de fil rouge pour le reste des articles.

Dans cet article : Du projet, du paramétrage et de l’analyse qualité.

Création du logiciel

J’utilise pour mes développements Visual Studio 2017 Community. Je crée un projet de type Application web ASP.NET Core.

Nouveau projet

La décision de faire ce type de projet est de permettre à d’autres utilisateurs de pouvoir l’installer sur un autre serveur que IIS. Ce site doit pouvoir tourner sur un serveur Linux par exemple.

Pour commencer je ne vais pas le mettre directement sur VSTS cela fera parti de la suite.

Je choisi un modèle .Net Core 1.1 Application Web.

Application Web

Comme je dois pouvoir gérer les utilisateurs je change l’authentification :

Autentification

Le projet est enfin créé :

Solution

J’exécute pour voir s’il n’y a aucun souci.

Test du site

Je vais maintenant modifier le projet ainsi :

  • Faire en sorte que les warnings soient pris comme des erreurs
  • Ajouter un projet NDepend pour contrôler la qualité du projet : il est plus facile de le faire dès le départ afin de garder une qualité constante.

Warnings en erreurs

Rien de bien compliqué.

Dans les propriétés du projet, dans la section Build je sélectionne : “Considérer les avertissements comme des erreurs” à “Tout”.

Modification du projet

Je sauvegarde et je lance le build, tout va bien :

Build

Mise en place de NDepend

Site : NDepend

Pour la suite je pars de la supposition que vous l’avez installé. Sinon prenez le temps d’installer la version de démonstration. J’utilise ici la version 2017.2.1 Professional Edition.

Dans le menu NDepend je choisi d’attacher un nouveau projet à ma solution.

NDepend

Voici la fenêtre de création du projet NDepend.

NDepend

Par défaut il prend le nom de la solution pour le nom du projet suivi de l’extension ndproj.

Il est possible de sélectionner les Assemblies à analyser soit :

  • En les sélectionnant via l’option Browse,
  • En prenant ceux de la solution,
  • En prenant les assemblies d’un répertoire particulier.

Par défaut c’est la seconde option. Je ne change rien et je clique sur “Analyze”.

Il se peut que vous ayez des warnings durant l’analyse sur des fichiers introuvables :

NDepend

Ceci n’est pas gênant en soit mais je prendrai un peu de temps après pour paramétrer le projet NDepend.

Voici le tout premier rapport sur le projet créé par Visual Studio :

NDepend

Comme vous pouvez le voir sur cette capture d’écran, le projet à une note de B concernant la dette technique (Debt). Pour en avoir fait l’expérience c’est beaucoup mieux que le projet Application Web ASP.NET standard qui lui a une note de D.

Essayons d’améliorer cette note. Le rapport est interactif :

Dans le menu sur le coté je prends “Hot Spots”

NDepend

Comme il est possible de le constater les notes sont par types :

NDepend

Il est aussi possible de voir le temps estimé pour le remboursement de la dette technique.

Autre vision de la qualité

Le rapport c’est bien mais peu interactif avec le développement. Je retourne dans Visual Studio.

Dans la barre d’état de VS il y a un petit rond en bas à droite vert, jaune ou rouge. C’est l’indicateur de respects des règles de NDepend :

  • Vert : toutes les règles actives sont respectées
  • Jaune : des règles actives ne sont pas respectées
  • Rouge : des règles critiques actives ne sont pas respectées

NDepend

Ici c’est en jaune. En passant la souris sur l’indicateur nous obtenons un eu plus de détails 13 règles non respectées :

NDepend

En cliquant sur le nombre de règles non respectées, NDepend affiche automatiquement les règles concernées :

NDepend

Devant le nom de la règle, vous avez le nombre d’éléments concernés.

Prenons une règle pour voir son détail et les éléments concernés : “A stateless class or structure might be turned into a static type”

Un clic sur la règle nous affiche le détail :

NDepend

Le haut est la règle proprement dites en format CLinq. Toutes les règles sont modifiables pour s’adapter aux besoins spécifiques et vos propres règles peuvent être créées.

Le bas concerne les éléments concernés. Ici un seul élément.

La règle que nous regardons dit qu’une classe n’ayant pas d’état (aucun élément non “static”) devrait être “static”.

La classe Program est concernée :

using System.IO;
using Microsoft.AspNetCore.Hosting;

namespace PokerClubManager
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .UseApplicationInsights()
                .Build();

            host.Run();
        }
    }
}

En effet, la seule méthode est la méthode Main qui est static. Je modifie donc pour mettre la classe en static. Je rebuild le projet et plus d’éléments concerné .

NDepend

Je vous laisse découvrir les autres règles par vous même pour les corriger à titre d’exercice.

Paramétrage du projet NDepend

Pour supprimer les warnings d’analyse, il faut indiquer au projet où se situe les DLL concernées.

Pour les éléments du SDK .Net Core je vais chercher le répertoire dans les propriétés de la référence :

NDepend

L’information se trouve dans SDK Root :

NDepend

Voici le répertoire concerné sur mon poste :

NDepend

Celui-ci ne contient pas toutes les DLL mais je vais le rajouter.

Avec cette information je retourne dans le menu NDepend puis dans Project puis je choisi Edit Project Properties.

NDepend

Je clique sur “View Directories that contain .Net assemblies to analyse”

NDepend

Je clique sur Browse puis me dirige vers ce répertoire que je sélectionne.

Si cela ne corrige pas il faut résoudre le répertoire directement. Un clic-droit sur la DLL concernée puis “Resolve Directory”

NDepend

Sélectionnez la DLL dans son répertoire puis validez.

Après avoir corriger les DLL non trouvées vous devez sauvegarder vos modifications.

NDepend

Un rebuild vous indique enfin que vous avez corrigé les warnings.