SonarLint, codez connecté avec SonarQube

sonarlint-black-256

Lors d'un projet, la qualité est aujourd'hui devenue une des priorités. Concernant celle du code source, de nombreux outils existent pour nous guider. Aujourd'hui nous allons aborder le sujet du plugin SonarLint en lien avec SonarQube.

Mais avant d'aborder ce qu'est SonarLint par rapport à SonarQube et en quoi celui-ci peut nous aider lors des phases d'amélioration du niveau de qualité du code de nos projets, voici un bref rappel sur SonarQube.

Docker : Build, Run &Compose (Partie 1)

docker-jenkins-artifactory-sonarqube

 

Dans cette série d'articles, nous allons démystifier docker (v 1.10.3 retenue et testée en particulier sous Windows). En attendant le support natif de docker dans Windows, nous présentons ici docker sous Windows reposant sur VirtualBox.

Nous nous attardons pas sur les concepts car, il me semble, que l'on en trouve suffisamment à ce propos sur le net. Ce que l'on trouve moins, c'est un tutoriel clair et complet sur docker pour Windows qui présente toutes les étapes nécessaires à la prise en main sans connaissance préalable.

Nous avons donc tenté de rassembler, dans cette série d'articles, l'ensemble des commandes utiles pour appréhender le monde docker.

Recette de l’intégration continue facile et rapide

Le trio Jenkins, Artifactory et Sonar est un classique pour construire des projets, récupérer/déployer des artefacts et mesurer la qualité du code. Vous connaissez surement déjà ces trois outils, mais sauriez-vous les mettre en place vous-même en partant de zéro? La réponse est évidement Oui! Voici la recette.

docker-jenkins-artifactory-sonarqube

Ingrédients :

  • 1 Machine Linux 64 bit avec accès à internet
  • 1 pincée de savoir faire

Temps de préparation : 5mn

Difficulté : Facile

DevOps @ Devoxx

J'ai eu la chance de pouvoir assister à la présentation "Les 5 mercenaires du DevOps", qui s'est tenue à l'occasion de Devoxx 2012.

Dans une très bonne ambiance, les animateurs de la session nous ont dressé un tableau très pertinent de ce qui se cache derrière le terme DevOps, agrémenté d'illustrations très pratiques. Pour ceux qui ont raté cet événement, voici ce que j'en ai retenu.

1. DevOps, kézaco?

Le terme DevOps mérite une petite explication. Dans le développement d'une application ou d'un logiciel, trois acteurs principaux sont impliqués :

- le business (le biz) : c'est le client (ou les utilisateurs)

- les développeurs (le dev) : les réalisateurs du projet ou du produit

- les opérations (les ops) : les personnes qui assurent son fonctionnement opérationnel.

Le terme DevOps désigne le point de rencontre entre le monde des développeurs et celui des opérations.

2. C'est quoi le problème?

Si vous faites partie du monde des Dev ou du monde des Ops, cette question ne vous surprend pas... Disons qu'il est difficile pour les uns et les autres de se comprendre, parce que leurs besoins sont presque antinomiques :

- les développeurs cherchent à délivrer des fonctionnalités nouvelles toujours plus rapidement

- les opérationnels cherchent la stabilité et la performance.

De plus, le dialogue est souvent perturbé par le fait que les développeurs se contentent de livrer des éléments de l'application, parfois avec une documentation (in)complète - et complexe - que les opérationnels peinent à installer. Et dans l'autre sens, les opérationnels ne savent pas quelles informations fournir aux développeurs pour les aider à reproduire ou à comprendre des dysfonctionnements de l'application.

3. Et l' intégration continue, c'est pas fait pour ça?

L'intégration continue c'est bien. Mais c'est surtout fait pour améliorer le travail des développeurs et la qualité de leurs livrables. Mais ça ne résout pas le problème de "qu'est-ce qu'un livrable"? Pour le développeur, c'est souvent un jar, ou un war, accompagné d'une bonne documentation d'installation. L'opérationnel, lui, préfèrerait un rpm, incluant les écrans de paramétrage spécifique et les procédures de migration et de rollback, au cas où...

Donc, si une intégration continue est nécessaire pour adresser les problématiques DevOps, elle n'est pas suffisante. Il faut combler l'espace entre ce que le développeur considère comme étant un livrable (le war), et ce que l'opérationnel considère comme étant un input (le rpm).

4. DevOps, c'est des outils?

Oui. Mais pas que.

DevOps c'est avant tout une philosophie, une volonté. Un peu comme l'agilité qui, elle, a permis d'améliorer le dialogue et la collaboration entre les deux premiers maillons de la chaine, le biz et le dev (mais bon... agile, ça sonne quand même mieux que BizDev!).

Mais, comme il est très difficile de faire du SCRUM sans outil, DevOps a aussi besoin d'un outillage adapté.

5. OK, je suis convaincu. De quels outils ai-je besoin?

On peut considérer que l'outillage utilisé pour l'intégration continue se prête bien à la mise en place de DevOps. Notamment :

- une repository d'artefacts qui permettra d'échanger les packages de livraison entre l'équipe de développement et celle d'exploitation.

- un moteur d'intégration continue qui permettra d'automatiser les jobs de déploiement pour une mise en production ou une livraison aux équipes de tests sans soucis.

L'outillage à adopter dépend de votre budget. Mais parmi les solutions les plus populaires on peut citer :

- SVN ou git pour la gestion de configuration

- Nexus, Archiva ou Artifactory pour la repository d'artefacts

- Bamboo, Teamcity ou Jenkins pour le moteur (de l'avis des animateurs, Bamboo et Teamcity sont plus avancés que Jenkins, mais ils ne sont pas gratuits...). On peut imaginer un moteur pour le développement, un pour la QA et un pour les Ops.

- Fisheye, Crucible pour la collaboration autour des sources et des packages

- Confluence pour la collaboration au sens large

DevOps se justifiant également pour le dialogue entre le développement et les équipes qualité, on peut ajouter à cette liste Sonar pour la validation du code.

Sonar au JUG de Paris

Depuis plus d'un an, Sonar est l'un de outils clé de la plateforme d'intégration continue de Netapsys (au même titre qu'Hudson et Artifactory).

Olivier Gaudin, l'un de ses créateurs, en fera une présentation le 15 septembre 2009 au Paris JUG à l'occasion de la "Soirée Qualité du Logiciel" tel qu'indiqué sur le blog de Sonar.

Le JUG se tiendra dans les locaux de l'ISEP, vous pouvez vous y inscrire en suivant ce lien.

Petits Déjeuners Netapsys / Intégration continue et outils de pilotage stratégique de vos projets

Jeudi 20 novembre à Nantes, Netapsys Atlantique vous invite à son petit déjeuner technique : Intégration continue et outils de pilotage stratégique de vos projets.

Animée par Jean-Baptiste Defard, Directeur Technique Netapsys, cette présentation sera l'occasion de détailler l'apport de tels outils par rapport à vos problématiques d'industrialisation des développements, de qualité et de pilotage stratégique de vos projets.

Nous vous proposerons sur cette rencontre de répondre aux questions suivantes :

  • Qu'est-ce que l'intégration continue ?
  • Quelles sont les étapes importantes de sa mise en oeuvre ?
  • Quels sont les impacts au quotidien ?
  • Quels sont les outils disponibles ? Maven, Hudson, Sonar...
  • Quels retours d'expérience après plus d'un an d'utilisation ?

Inscription sur notre site : http://petitdejeuner.netapsys.fr