Intégrer le génie logiciel dans le monde de tous les jours

Image de Benoit Verhaeghe
Benoit Verhaeghe
  • 6 minutes de lecture
Partager par e-mail

Je fais partie de l'équipe de recherche de Berger-Levrault depuis 6 ans. L'un de nos principaux défis consiste à intégrer nos innovations dans le monde quotidien de l'entreprise. Il y a plusieurs façons d'intégrer l'innovation : en tant que bibliothèque de code externe, en fournissant des schémas, en enseignant comment utiliser de nouveaux outils, etc. Dans ce billet de blog, je présenterai comment nous intégrons le travail d'ingénierie logicielle dans les outils quotidiens des développeurs.

Le génie logiciel consiste à aider les gens à développer d'excellents systèmes logiciels. Dans le cadre de la recherche en génie logiciel, nous avons créé des outils qui aident à migrer votre application, ou à améliorer votre architecture logicielle. Cependant, ce type d'innovations n'est pas destinée à être utilisé tous les jours. Par exemple, une fois que l'application est migrée, les gens ne réutilisent pas (pour la même application) l'outil de migration.

D'autres innovations concernent la conception de nouvelles visualisations ou la fourniture de diagnostics sur le code. Ce type d'innovations est plus efficace lorsqu'il est mis à jour automatiquement avec le code. En effet, lorsqu'ils utilisent une carte, les gens s'attendent à ce qu'elle soit mise à jour. Il en va de même pour les schémas logiciels ou les critiques de code. Une autre contrainte pour les développeurs est que l'utilisation de ces innovations doit être aussi facile et intégrée que possible à leurs outils actuels.

Chez Berger-Levrault, nous utilisons Moose pour analyser les systèmes logiciels. Moose nous permet de créer des visualisations et des diagnostics sur le code. Aujourd'hui, nous allons présenter comment on peut produire une visualisation UML de base de son code et l'intégrer dans le wiki GitLab. Ensuite, nous présenterons comment intégrer les diagnostics avancés de Moose dans le célèbre wiki GitLab : Outil SonarQube. Enfin, nous exposons l'intégration dans les éditeurs de texte et les IDE tels que VSCode.

Effectuer une analyse dans un CI

La première étape de l'analyse lorsque les développeurs travaillent sur le code consiste à utiliser l'IC pour effectuer notre analyse.

Le processus principal est le suivant : les développeurs modifient le code, le placent dans un dépôt git, l'IC installe les dépendances du code, notre outil analyse le code et les nouveaux résultats sont envoyés aux outils des développeurs.

En ce qui concerne le CI GitLab, deux étapes préliminaires sont nécessaires pour effectuer l'analyse. La figure ci-dessous présente le fichier CI GitLab .gitlab-ci.yml

étapes :
  - installer
  - analyser

# Installer les dépendances
install :
  stage : install
  image :     
    name : kaiwinter/docker-java8-maven
  script :
# '../maven/settings - critics.xml' set the maven repository to './repo'
    - mvn clean install --settings '../maven/settings - critics.xml' -Dmaven.test.skip=true
  artefacts :
    chemins :
      - repo

parse :
  stage : parse
  image :     
    name : ghcr.io/evref-bl/verveinej:v3.0.13
    point d'entrée : [""]
  besoins :
    - job : install
      artefacts : true
  script :
    - /VerveineJ-3.0.13/verveinej.sh -format json -o output.json -alllocals -anchor assoc -autocp ./repo .
  artefacts :
    chemins :
      - output.json

L'étape installer consiste à utiliser Maven (dans le cas du code Java) pour installer les dépendances du projet. Cette étape est facultative mais permet d'obtenir de meilleurs résultats lors d'analyses ultérieures.

L'étape analyser utilise VerveineJ. Le logiciel de gestion du code Java est un outil qui analyse le code Java et produit un modèle du code qui peut être utilisé pour l'analyse.

Une fois ces étapes préliminaires effectuées, nous devons demander à l'IC d'effectuer l'analyse et d'envoyer les résultats à la plateforme cible.

Intégrer les visualisations au wiki GitLab

Pour intégrer le schéma au wiki GitLab, il y a deux options : utiliser le schéma markdown natif, ou exporter la visualisation en png et intégrer le fichier png au markdown.

Dans cet article de blog, nous nous concentrons sur le schéma markdown natif à l'aide de MermaidJS. Pour utiliser Mermaid avec Moose, nous utilisons l'option du projet MermaidPharo . La configuration de l'IC pour intégrer la visualisation dans le wiki GitLab se fait en trois étapes :

  1. Nous ajoutons un fichier de configuration nommé .smalltalk.ston. Ce fichier configure l'IC pour qu'il installe le projet MermaidPharo
SmalltalkCISpec {
    #loading : [
        SCIMetacelloLoadSpec {
            #baseline : 'MermaidPharo',
            #repository : 'github://badetitou/MermaidPharo:main',
            #directory : 'src',
            #platforms : [ #pharo ],
            #onConflict : #useIncoming,
            #load : [ 'moose' ],
            #onUpgrade : #useIncoming
        }
    ],
    #esting : {
    #failOnZeroTests : false
    }
}
  1. Nous ajoutons un script Pharo en ci/executeCode.st qui effectuera l'analyse.
"=== Charger le modèle MooseModel ==="
model := FamixJavaModel new.
'./output.json' asFileReference readStreamDo : [ : stream | model importFromJSONStream : stream ].
modèle rootFolder : '.'.

diagramme := Famix2Mermaid new
     modèle : modèle ;
     generateClassDiagram.

visitor := MeWritterVisitor new.
visiteur endOfLine : Chaîne crlf.

"Exporter le diagramme dans le fichier markdown './wiki-export/mermaid.md'"
'./wiki-export/mermaid.md' asFileReference ensureCreateFile ; writeStreamDo : [ :stream |
    stream << '``mermaid' ; << String crlf.
    diagram exportWith : visitor to : stream.
    stream << String crlf ; << String crlf ; << '```' ; << String crlf.
].
 Stdio stderr << '=== End Pharo ===' << String crlf.
Smalltalk snapshot : false etQuit : true
  1. Enfin, nous mettons à jour le .gitlab-ci.yml pour exécuter l'analyse Moose et mettre à jour le projet wiki GitLab
analyser :
  étape : analyser
  image : hpiswa/smalltalkci
  variables :
    ORIGIN_IMAGE_NAME : BLMoose
  besoins :
    - job : parse
    artefacts : true
  script :
    # Mise en place d'une image Moose pour l'analyse
    - apt-get install -y wget unzip
    - wget -O artifacts.zip --header "PRIVATE-TOKEN : $GILAB_TOKEN" "https://my.private.gitlab.com/api/v4/projects/219/jobs/artifacts/main/download?job=Moose64-10.0" ;
    - décompresser artifacts.zip

    # Installer Moose en utilisant .smalltalk.ston
    - smalltalkci -s "Moose64-10" --image "$ORIGIN_IMAGE_NAME/$ORIGIN_IMAGE_NAME.image"

    # Exécuter le code d'analyse
    - /root/smalltalkCI-master/_cache/vms/Moose64-10/pharo --headless BLMoose/BLMoose.image st ./ci/executeCode.st

    # Mise en place et mise à jour du Wiki
    - export WIKI_URL="${CI_SERVER_PROTOCOL}://username:${USER_TOKEN}@${CI_SERVER_HOST}:${CI_SERVER_PORT}/${CI_PROJECT_PATH}.wiki.git"

    # Désactiver la vérification ssl qui pourrait échouer
    - git config --global http.sslverify "false"
    - rm -rf "/tmp/${CI_PROJECT_NAME}.wiki"
    - git clone "${WIKI_URL}" /tmp/${CI_PROJECT_NAME}.wiki
    - rm -rf "/tmp/${CI_PROJECT_NAME}.wiki/wiki-export"
    - rm -rf "/tmp/${CI_PROJECT_NAME}.wiki/wiki-export"
    - mv -f wiki-export /tmp/${CI_PROJECT_NAME}.wiki
    - cd /tmp/${CI_PROJECT_NAME}.wiki

    # set committer info
    - git config user.name "$GITLAB_USER_NAME"
    - git config user.email "$GITLAB_USER_EMAIL"

    # valide le fichier
    - git add -A
    - git commit -m "Fichier mis à jour automatiquement dans le CI"

    # repousse le changement vers la branche master du wiki
    - git push origin "HEAD:main"

Envoi de diagnostics avancés à SonarQube

Une autre intégration possible est celle de SonarQube. Là encore, pour réaliser l'intégration avec SonarQube, nous devons modifier les éléments suivants .smalltalk.ston, ci/executeCode.stet .gitlab-ci.yml. Nous devons également créer un rapports/règles/règles.ston qui contient les règles exécutées par Moose.

  1. Pour le .smalltalk.ston, cette fois, nous chargeons le FamixCritics au projet SonarQube
SmalltalkCISpec {
    #loading : [
        SCIMetacelloLoadSpec {
            #baseline : 'FamixCriticSonarQubeExporter',
            #repository : 'github://badetitou/Famix-Critic-SonarQube-Exporter:main',
            #directory : 'src',
            #platforms : [ #pharo ],
            #onConflict : #useIncoming,
            #onUpgrade : #useIncoming
        }
    ],
    #esting : {
        #failOnZeroTests : false
    }
}
  1. Pour le rapports/règles/règles.stoncela comprend les règles que Moose exécutera lors de l'analyse du code. La création de ce fichier est facilitée par le navigateur Critics de Moose. L'exemple ci-dessous présente une règle qui vérifie que les attributs Java ne commencent pas par _.
FamixCBContext {
    #contextBlock : '[ :collection | \r\t collection select : [ :el | el isKindOf : FamixJavaAttribute ] ]',
    #summary : '',
    #name : 'FamixJavaAttribute' ;
}FamixCBCondition {
    #query : '[ :entity | entity name beginsWith : \'_\' ]',
    #summary : '# Attribute name cannot begin with _\r\rAn attribute should not begin with `_`',
    #name : 'Le nom de l'attribut ne peut pas commencer par _' ;
}OrderedCollection [
    0,
    1
]
  1. Pour le ci/executeCode.st, nous demandons à Moose de charger les règles définies précédemment, nous les exécutons et nous générons le fichier compatible SonarQube à partir des résultats.
"=== Charger le modèle MooseModel ==="
model := FamixJavaModel new.
'./output.json' asFileReference readStreamDo : [ : stream | model importFromJSONStream : stream ].
modèle rootFolder : '.'.

"Exécuter les règles"
criticBrowser := MiCriticBrowser on : MiCriticBrowser newModel.
'./reports/rules/rules.ston' asFileReference readStreamDo : [ :stream | criticBrowser importRulesFromStream : stream ].
criticBrowser model setEntities : model.
criticBrowser model run.
violations := criticBrowser model getAllViolations.
    
"Export critics to file './reports/sonarGenericIssue.json' asFileReference"
targetRef := './reports/sonarGenericIssue.json' asFileReference.
FmxCBSQExporter new
   violations : violations ;
    targetFileReference : targetRef ;
    export.
  1. Enfin, nous mettons à jour le .gitlab-ci.yml pour exécuter l'analyse et envoyer les résultats à SonarQube
analyser :
    étape : analyser
    image : hpiswa/smalltalkci
    variables :
        ORIGIN_IMAGE_NAME : BLMoose
    besoins :
        - job : parse
        artefacts : true
    script :
        # Mise en place d'une image Moose pour l'analyse
        - apt-get install -y wget unzip
        - 'wget -O artifacts.zip --header "PRIVATE-TOKEN : $GILAB_TOKEN" "https://my.private.gitlab.com/api/v4/projects/219/jobs/artifacts/main/download?job=Moose64-10.0"'.
        - décompresser artifacts.zip
         # Installer Moose en utilisant .smalltalk.ston
        - smalltalkci -s "Moose64-10" --image "$ORIGIN_IMAGE_NAME/$ORIGIN_IMAGE_NAME.image"
         # Exécuter le code d'analyse
        - /root/smalltalkCI-master/_cache/vms/Moose64-10/pharo --headless BLMoose/BLMoose.image st ./ci/executeCode.st
    artefacts :
      chemins :
        - reports/sonarGenericIssue.json
        expire_in : 1 semaine
        
sonar :
    stage : sonar
    image : kaiwinter/docker-java8-maven
    besoins :
        - job : analyze
        artefacts : true
    variables :
        MAVEN_CLI_OPTS : '--batch-mode -Xmx10g -XX:MaxPermSize=10g'
        SONAR_URL : 'https://my.private.gitlab.com'
    script :
        - mvn clean install sonar:sonar -Dsonar.projectKey=$PROJECT_KEY -Dsonar.host.url=$SONAR_URL -Dsonar.login=$MOOSE_SONAR_TOKEN -Dsonar.externalIssuesReportPaths=../reports/sonarGenericIssue.json --settings '../maven/settings - critics.xml' -Dmaven.test.skip=true

Les critiques sont ensuite disponibles via l'interface SonarQube.

Problème DASH dans SonarQube

Intégrer le VSCode

La dernière grande intégration possible est l'intégration de Critics (voir la section avec SonarQube) directement dans VSCode. Cette approche est similaire à celle de SonarLint.

Pour réaliser une telle intégration, nous utilisons également Moose et Pharo, et en particulier, nous utilisons la fonction Protocole du serveur de langues et sa mise en œuvre pour Pharo (badetitou.pharo-language-server). Nous l'avons étendu pour calculer les mêmes critiques que notre IC. Et il montre directement les critiques dans l'environnement des développeurs.

Le BL Language Server (l'extension de Berger-Levrault pour le VSCode) affiche une erreur directement dans l'IDE du développeur.

Plus ...

Commencez à saisir du texte et appuyez sur Entrée pour rechercher

Retour en haut