Open Source y código Legacy

Il existe de plus en plus de solutions d’analyse de code qui permettent de mesurer la qualité de vos applications. La plupart sont vendues par des éditeurs logiciels, et nous avons eu l’occasion de vérifier que ces solutions coûtaient cher à l’achat, à l’implémentation et à l’utilisation (Software jetable). Face à cela, la dernière décennie a vu la montée en puissance du monde Open Source, alternative au logiciel propriétaire.

J’entends souvent dire au sujet de solutions Open Source en matière de qualité logicielle :

  • Les outils Open Source ne savent analyser que du Java.
  • Ils nécessitent une forte expertise technique Open Source / J2EE.
  • Ce sont des outils pour développeurs.

Les premiers outils Open Source à analyser du code – citons PMD, FindBugs, Checkstyle – sont effectivement centrés sur le code Java et globalement utilisés par des profils développeurs. La plateforme Sonar que nous avons utilisée dans nos posts précédents pour analyser du code Cobol (Sonar – Première analyse, Sonar – Analyse Cobol avec Jenkins) propose de nombreux plugins (Open Source ou commerciaux) pour de nombreux langages, pas simplement orientés nouvelles technologies, mais également pour des technologies Legacy tels que Cobol, ABAP ou du monde Microsoft.

Nous avons également pu vérifier qu’il n’est nul besoin de connaissances techniques approfondies. Nous avons utilisé :

  • Un environnement Windows / Oracle très courant dans le monde des entreprises.
  • Tomcat sous la forme d’un service Windows, pour l’installation de Sonar et de Jenkins.
  • L’intégration transparente de Sonar et de Jenkins, grâce au plugin Sonar.
  • Le Java Runner de Sonar : il nous permet d’effectuer immédiatement des analyses sans nécessiter d’autres outils tels que Maven ou Ant, qui eux effectivement nécessitent quelques connaissances J2EE.

Enfin, nous avons vu dans notre dernier post comment mettre en œuvre un serveur d’analyse pour du code Legacy sur la base d’un socle Sonar / Jenkins, et comment nous pouvons organiser notre environnement d’analyse de différentes manières. Voici quelques cas d’usage pour un tel serveur.

Quality Gate

Chaque nouvelle version applicative est distribuée sur notre environnement, dans un répertoire spécifique à cette application. Les analyses sont déjà paramétrées et sont effectuées automatiquement depuis Jenkins. Dans le portail Sonar, une alerte peut être programmée sur la survenance de certains défauts présentant une certaine criticité, qui déclenchera un Go / NoGo, c’est à dire acceptation ou rejet de cette version, pour passer en phase suivante (test ou production).

Benchmarking de providers

Un ensemble de métriques sont constituées en Service Level Agreements (accords de niveau de service) pour différents prestataires effectuant la maintenance de différentes applications. Le code correspondant à chaque correction ou évolution ou nouvelle version est livrée dans notre environnement. Les analyses peuvent être effectuées manuellement ou automatiquement (par exemple, durant la nuit). Si les métriques qui constituent l’accord de service ne sont pas respectées, le prestataire peut se voir obliger d’effectuer une nouvelle livraison ou subir certaines pénalités prévues dans ce cas. Le responsable en charge de gérer ces prestataires dispose dans Sonar des données objectives qui lui permet, à la fin de chaque mois, de comparer la qualité de service de chacun d’entre eux.

Gouvernance applicative

Au niveau de chaque projet, des analyses sont effectuées à intervalles réguliers (chaque semaine par exemple) indépendamment de toute nouvelle version ou évolution. Les gestionnaires de ces projets peuvent suivre l’évolution au fil du temps de facteurs tels que la maintenabilité, la capacité d’évolution ou encore la dette technique, facteurs qui impactent directement les coûts de projet et le time to market. Ces mêmes données sont agrégées chaque mois ou chaque trimestre au niveau du portefeuille applicatif et examinées par la direction informatique.

Ce ne sont là que quelques exemples qui démontrent bien que les outils tels que Sonar et Jenkins ne sont pas uniquement pour les développeurs, des gurus J2EE ou des applications Java.

Nous aurons l’occasion d’examiner plus en détails ces cas d’utilisation dans nos futurs posts, avec ces outils Open Source et pour des applications Legacy.Il existe de plus en plus de solutions d’analyse de code qui permettent de mesurer la qualité de vos applications. La plupart sont vendues par des éditeurs logiciels, et nous avons eu l’occasion de vérifier que ces solutions coûtaient cher à l’achat, à l’implémentation et à l’utilisation (Software jetable). Face à cela, la dernière décennie a vu la montée en puissance du monde Open Source, alternative au logiciel propriétaire.

J’entends souvent dire au sujet de solutions Open Source en matière de qualité logicielle :

  • Les outils Open Source ne savent analyser que du Java.
  • Ils nécessitent une forte expertise technique Open Source / J2EE.
  • Ce sont des outils pour développeurs.

Les premiers outils Open Source à analyser du code – citons PMD, FindBugs, Checkstyle – sont effectivement centrés sur le code Java et globalement utilisés par des profils développeurs. La plateforme Sonar que nous avons utilisée dans nos posts précédents pour analyser du code Cobol (Sonar – Première analyse, Sonar – Analyse Cobol avec Jenkins) propose de nombreux plugins (Open Source ou commerciaux) pour de nombreux langages, pas simplement orientés nouvelles technologies, mais également pour des technologies Legacy tels que Cobol, ABAP ou du monde Microsoft.

Nous avons également pu vérifier qu’il n’est nul besoin de connaissances techniques approfondies. Nous avons utilisé :

  • Un environnement Windows / Oracle très courant dans le monde des entreprises.
  • Tomcat sous la forme d’un service Windows, pour l’installation de Sonar et de Jenkins.
  • L’intégration transparente de Sonar et de Jenkins, grâce au plugin Sonar.
  • Le Java Runner de Sonar : il nous permet d’effectuer immédiatement des analyses sans nécessiter d’autres outils tels que Maven ou Ant, qui eux effectivement nécessitent quelques connaissances J2EE.

Enfin, nous avons vu dans notre dernier post comment mettre en œuvre un serveur d’analyse pour du code Legacy sur la base d’un socle Sonar / Jenkins, et comment nous pouvons organiser notre environnement d’analyse de différentes manières. Voici quelques cas d’usage pour un tel serveur.

Quality Gate

Chaque nouvelle version applicative est distribuée sur notre environnement, dans un répertoire spécifique à cette application. Les analyses sont déjà paramétrées et sont effectuées automatiquement depuis Jenkins. Dans le portail Sonar, une alerte peut être programmée sur la survenance de certains défauts présentant une certaine criticité, qui déclenchera un Go / NoGo, c’est à dire acceptation ou rejet de cette version, pour passer en phase suivante (test ou production).

Benchmarking de providers

Un ensemble de métriques sont constituées en Service Level Agreements (accords de niveau de service) pour différents prestataires effectuant la maintenance de différentes applications. Le code correspondant à chaque correction ou évolution ou nouvelle version est livrée dans notre environnement. Les analyses peuvent être effectuées manuellement ou automatiquement (par exemple, durant la nuit). Si les métriques qui constituent l’accord de service ne sont pas respectées, le prestataire peut se voir obliger d’effectuer une nouvelle livraison ou subir certaines pénalités prévues dans ce cas. Le responsable en charge de gérer ces prestataires dispose dans Sonar des données objectives qui lui permet, à la fin de chaque mois, de comparer la qualité de service de chacun d’entre eux.

Gouvernance applicative

Au niveau de chaque projet, des analyses sont effectuées à intervalles réguliers (chaque semaine par exemple) indépendamment de toute nouvelle version ou évolution. Les gestionnaires de ces projets peuvent suivre l’évolution au fil du temps de facteurs tels que la maintenabilité, la capacité d’évolution ou encore la dette technique, facteurs qui impactent directement les coûts de projet et le time to market. Ces mêmes données sont agrégées chaque mois ou chaque trimestre au niveau du portefeuille applicatif et examinées par la direction informatique.

Ce ne sont là que quelques exemples qui démontrent bien que les outils tels que Sonar et Jenkins ne sont pas uniquement pour les développeurs, des gurus J2EE ou des applications Java.

Nous aurons l’occasion d’examiner plus en détails ces cas d’utilisation dans nos futurs posts, avec ces outils Open Source et pour des applications Legacy.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *