JetBrains Qodana a été le sujet de discussion dans le domaine de la qualité du code depuis sa sortie commerciale officielle en juillet 2023. Non seulement il s'agit de la plateforme d'analyse de code statique officielle de JetBrains pour les équipes et donc hautement compatible avec les EDI JetBrains et les outils d'équipe, mais Qodana comprend également une gamme d'inspections uniques, accompagnées d'un excellent support client tout au long de votre expérience.JetBrains a développé ce puissant moteur d'analyse statique pour permettre aux équipes de développement logiciels d'automatiser les revues de code, de construire des murs de qualité et de faire respecter les directives de qualité du code à l'échelle de l'entreprise, le tout au sein de leur écosystème JetBrains. La plateforme peut être intégrée à n'importe quel pipeline CI/CD et peut analyser du code écrit dans plus de 60 langages, dont Java, JavaScript, TypeScript, PHP, Kotlin, Python, Go et C#.
L'adoption croissante de Qodana marque le moment parfait pour JetBrains pour dévoiler de nouvelles fonctionnalités et mises à jour, aidant les équipes à maintenir la qualité logicielle dans une industrie qui en a plus que jamais besoin.
Que vous cherchiez à créer des inspections personnalisées pour votre équipe, à auditer les licences par défaut pour devenir ou rester conforme, ou simplement à naviguer plus facilement dans les résultats de l'analyse de code, Qodana vous offre ces capacités, et plus encore, dans la version 2024.1.
FlexInspect - une nouvelle façon d'écrire des inspections personnalisées
Chaque équipe a des besoins uniques en matière de qualité du code. À l'heure actuelle, aucun outil de qualité du code ne couvre l'ensemble du spectre des règles par défaut, laissant potentiellement des lacunes pour les équipes ayant des besoins spécifiques.
Avec FlexInspect de Qodana, vous pouvez désormais créer des inspections de code personnalisées pour n'importe quelle règle que vous souhaitez appliquer dans votre code ou votre référentiel. Ensuite, vous pouvez exécuter ces inspections sur votre projet dans IntelliJ IDEA ou en utilisant Qodana dans votre pipeline CI/CD.
Ainsi, vous pouvez identifier les problèmes spécifiques à votre base de code et à votre équipe, ce qui vous fait gagner du temps et des efforts.
Pour écrire une inspection personnalisée en utilisant l'API Kotlin d'IntelliJ dans IntelliJ IDEA, suivez ces étapes :
- Accédez à l'AST (arbre de syntaxe abstraite) du code source.
- Déboguez le fonctionnement d'une nouvelle inspection sur le code en temps réel.
- Observez vos nouvelles inspections personnalisées en action, y compris la mise en surbrillance des extraits de code qui ne respectent pas le comportement attendu.
Grâce à cette fonctionnalité, vous avez accès à PSI - l'API utilisée par toutes les inspections IntelliJ et Qodana, et vous pouvez implémenter toutes les inspections personnalisées supplémentaires dont vous pourriez avoir besoin.
Voici comment vous pouvez accéder à l'AST de votre code avec le visualiseur PSI d'IntelliJ IDEA :
FlexInspect vous permet d'analyser du code dans une variété de langages, notamment Java, Kotlin, JavaScript, TypeScript, PHP, Go, Python, Ruby, SQL, XML, CSS, YAML, JSON, shell et Dockerfile. JetBrains travaille sur l'extension de cette liste, alors restez à l'écoute !
Veuillez noter que la mise en œuvre d'inspections personnalisées nécessite que vous écriviez du code en Kotlin, ce qui signifie que vous devrez utiliser IntelliJ IDEA Ultimate.
De plus, comme il s'agit de la première version de FlexInspect, l'équipe de support de JetBrains est prête à vous aider si vous rencontrez des problèmes.
Analyse de différences ajoutée à Qodana pour .NET
Maintenant, vous pouvez utiliser le linter QDnet pour n'analyser que les merge et les pull requests lorsque vous le souhaitez, plutôt que de scanner l'ensemble de votre base de code.
Utilisez ce mode pour exécuter une analyse incrémentielle ou une analyse de différences sur un change-set, c'est-à-dire sur une merge ou une pull request. Pour les utilisateurs de qodana-github-action, ce changement sera pris en charge automatiquement.
Comment l'utiliser :
- Si vous venez de terminer votre commit et que vous voulez analyser les modifications :
qodana scan --diff-start=$GIT_START_HASH
- Si vous voulez analyser un ensemble de modifications entre deux commits :
qodana scan --diff-start=$GIT_HASH_START --diff-end=$GIT_HASH_END
- Si vous utilisez l'action GitHub Qodana pour vos exécutions CI, cela va fonctionner automatiquement.
Veuillez noter que cette fonctionnalité est uniquement prise en charge par le linter payant Qodana for .NET, mais pas par le linter Qodana for .NET Community.
Audit de licence activé par défaut
La conformité peut être un cauchemar sans les bons outils, c'est pourquoi la fonctionnalité d'audit de licence de JetBrains est si populaire auprès des utilisateurs. Maintenant, la fonctionnalité d'audit de licence est activée par défaut (si vous avez la licence Ultimate Plus, la seule licence qui prend en charge cette fonctionnalité en général).
Toute information que Qodana trouve concernant les licences des dépendances de votre projet sera automatiquement affichée dans l'onglet Audit de licence de votre projet dans Qodana Cloud, vous n'avez donc pas besoin de configurer votre analyse pour l'exécuter.
JetBrains a également rendu possible pour les utilisateurs existants de l'audit de licence de voir les problèmes d'audit dans l'onglet d'interface utilisateur de Qodana Cloud, plutôt que dans la liste générale des problèmes. Mais si vous et votre équipe préférez continuer à voir les problèmes de licence dans la liste générale des problèmes, veuillez mettre à jour votre configuration en conséquence.
Prise en charge de la qualité du code GitLab et de l'analyse du code BitBucket (décoration de pull requests)
À partir de la version 2024.1, les linters Qodana prennent en charge la décoration des pull requests pour BitBucket Pipelines et GitLab CI. Auparavant, cette fonctionnalité était uniquement disponible pour GitHub Actions.
Désormais, Qodana est capable d'améliorer les revues de code avec des informations automatisées sur la qualité du code directement dans l'interface des pull ou merge requests pour GitHub Actions, GitLab CI et BitBucket Pipelines.
Grâce à cette intégration, vous pouvez accéder aux lignes de code spécifiques où des problèmes ont été détectés, ainsi qu'aux descriptions des problèmes et aux solutions ou recommandations possibles - directement depuis votre pull ou merge request.
Comment activer la fonctionnalité :
- BitBucket Code Insights : aucune configuration supplémentaire n'est nécessaire - il suffit de mettre à jour votre linter vers la version 2024.1.
- GitLab Code Quality : une configuration supplémentaire est nécessaire (spécifiez l'emplacement du fichier de rapport).
Script :
| Code : | Sélectionner tout |
1 2 3 |
- qodana --results-dir=$CI_PROJECT_DIR/.qodana/results
--cache-dir=$CI_PROJECT_DIR/.qodana/cache |
Artefacts :
- Rapports : codequality: .qodana/results/gl-code-quality-report.json
Choix du linter par défaut lorsque non défini via qodana.yaml
JetBrains introduit un changement dans le choix du linter par défaut pour les projets JVM et Python. Pour fournir aux utilisateurs les capacités d'analyse les plus avancées et riches en fonctionnalités, Qodana utilisera désormais par défaut les versions Ultimate des linters de JetBrains - QDJVM pour les projets JVM et QDPY pour les projets Python - plutôt que les versions Community (QDJVMC et QDPYC, respectivement).
Ce changement signifie que, si votre configuration qodana.yaml ne spécifie pas une version de linter particulière et que le token Qodana Cloud n'est pas fourni, la version Ultimate sera utilisée automatiquement, vous permettant de profiter de toutes les capacités de Qodana.
Si vous préférez la version Community, assurez-vous de la définir explicitement dans le fichier qodana.yaml pour éviter les perturbations après votre mise à niveau vers Qodana 2024.1.
Amélioration de l'expérience utilisateur pour le plugin Qodana
- La coloration syntaxique de Qodana ne duplique plus la mise en évidence de l'EDI. Si un problème du rapport de Qodana est déjà mis en évidence par l'EDI, le plugin Qodana ne tente pas de le mettre en évidence.
- Lorsque vous corrigez l'un des problèmes répertoriés dans le rapport de Qodana ou ajustez l'extrait de code associé, le plugin Qodana met automatiquement à jour le statut du problème dans le rapport à Fixed (s'il a été corrigé) ou Not found (si l'extrait de code associé a été supprimé).
De cette façon, vous pouvez immédiatement voir quels problèmes du rapport ont été résolus et continuer à travailler sur le reste.
Configuration des murs de qualité par gravité du problème
Vous ne voulez pas faire échouer vos builds en raison de problèmes de faible gravité. Maintenant, vous pouvez ajuster finement les conditions d'échec de build.
Tous les linters sauf Qodana Community pour .NET vous permettent de configurer des murs de qualité distincts pour chaque gravité de problème, et dépasser simplement une limitation de configuration fera échouer le build. Voici un exemple de configuration de gravité dans qodana.yaml :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 |
failureConditions:
severityThresholds:
any: <number> # Total problems
critical: <number> # Critical and other severities
high: <number>
moderate: <number>
low: <number>
info: <number> |
Paramètre pour un fichier qodana.yaml personnalisé
La version 2024.1 simplifie le processus d'exécution de plusieurs builds Qodana avec différentes configurations sur le même référentiel.
Dans les versions précédentes, les linters Qodana utilisaient un fichier qodana.yaml qui conservait la configuration et définissait le comportement du linter (y compris l'ensemble des inspections qu'il exécute, les dossiers et fichiers à analyser, etc.).
Pour exécuter un job d'intégration continue avec un linter utilisant une configuration différente, vous deviez remplacer le fichier qodana.yaml.
De plus, si vous aviez un monorepo (c'est-à-dire un référentiel dans lequel est stocké le code d'un certain nombre de projets) avec, par exemple, JavaScript, PHP et Python, et que vous exécutiez trois jobs respectifs pour chaque linter, vous auriez peut-être voulu utiliser différents fichiers qodana.yaml, mais dans le passé, vous ne pouviez pas le faire.
À partir de Qodana 2024.1, vous pouvez utiliser n'importe quel nom de fichier et simplement le passer en tant que paramètre. Tous les linters fournissent désormais un paramètre facultatif appelé config qui vous permet de passer n'importe quel fichier en tant que configuration.
Exemples d'utilisation :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | #qodana-cli qodana scan --config custom.qodana.yaml #qodana docker docker run \\ -v <source-directory>:/data/project \\ -v <output-directory>:/data/results \\ jetbrains/qodana-jvm:2024.1 \\ --config .qodana/license-check.qodana.yaml |
Ce sont là quelques-unes des améliorations et nouveautés clés de la nouvelle version de Qodana. Vous pouvez consulter la documentation complète de Qodana 2024.1 pour en savoir plus.
Découvrez et téléchargez Qodana (pour JVM, PHP, Python, JS, GO, .NET, Android)