Nous avons vu la semaine dernière ce qu’il fallait savoir en matière de Mainframe-Cobol, avant de se présenter dans une réunion avec les spécialistes de cette technologie et préparer un processus d’analyse avec Sonar.
Nous allons maintenant examiner les questions à poser afin d’organiser les analyses avec Sonar (que nous verrons dans un prochain article).
Ces questions vous permettront également de préciser les règles de livraison du code source.
J’ai fait quelques posts il y a quelques mois (Sonar – Analyse Cobol avec Jenkins, Open Source & code Legacy) dans le but de montrer que, contrairement à une idée assez répandue, il n’est pas nécessaire d’être un gourou J2EE ou un expert Open Source pour analyser du code Legacy d’applications Cobol (ou ABAP) avec Sonar et Jenkins.
Et je vois pas mal de visiteurs consulter ces pages sur mon blog, ce qui dénote l’intérêt certain pour ce sujet.
Mais quelqu’un m’a dit récemment : « Nous effectuons régulièrement et avec succès des analyses Sonar pour du code J2EE. Nous envisageons également de mettre les applications Cobol dans Sonar et Jenkins, mais je ne connais pas le monde Mainframe ».
Ainsi, ce post (et les suivants) aura pour objectif d’aider à la mise en place d’un processus d’analyse de code Cobol avec Sonar et Jenkins. Continuer la lecture
Vous avez peut-être entendu parler de Crowdtesting, une pratique qui génère actuellement pas mal de ‘buzz’ et qui consiste à confier une application à une communauté de testeurs externes afin qu’ils en vérifient la robustesse.
A l’occasion du post de la semaine dernière, je me suis demandé si la situation rencontrée dans ce cas ne justifierait pas le recours à cette technique. Continuer la lecture
Le bug présenté dans notre précédent post a attiré un grand nombre de commentaires tous plus intéressants les uns que les autres.
Donc d’abord, un grand merci à tous ceux qui nous ont fait part de leur point de vue, puisque c’était justement l’objectif de cette publication.
Mon expérience de consultant est plutôt orientée ‘best practices’ en matière de cycle de vie de projet (ex-développeur, ex-chef de projet, puis dans le Configuration Management et la qualité de code). Je ne suis donc pas un expert en QA.
Mais je travaille régulièrement avec de bons professionnels de QA et j’étais très curieux de l’opinion de personnes plus expertes que moi dans ce domaine … avant de formuler quelques hypothèses dans ce second post.
En tant que consultant Qualité, je n’adore rien de plus que de trouver des bugs.
Rien de plus plaisant que d’analyser le code d’une application et de trouver un ou plusieurs bon gros bugs impardonnables, comme un ‘Break’ en ABAP (instruction utilisé en mode debug et qui va stopper instantanément le programme), un OPEN / CLOSE de fichiers dans une boucle (instructions coûteuses en temps système, á réaliser hors de la boucle, évidemment) ou un accès direct à la base de données depuis une page JSP. Pas besoin d’être spécialiste pour savoir qu’il s’agit de défauts graves.
Il y a pourtant une situation dans laquelle je détester trouver des bugs : en tant qu’utilisateur d’une application.
Cela faisait un moment que nous n’avions pas parlé de Sonar. J’ai été un peu occupé récemment à découvrir de nouveaux territoires (cf. les posts précédents Elasticité des applications, La qualité dans le Cloud) et j’ai donc pris du retard dans la mise-à-jour de de mon environnement Sonar. De surcroît, il y a une nouvelle version 3.0 avec un tas de nouveautés.
Donc et sans plus attendre, le moment est venu d’effectuer un upgrade Sonar. Continuer la lecture
Dans notre dernier post, nous avons expliqué la notion d’élasticité, en tant que capacité à déplacer des ressources au sein d’une infrastructure virtuelle afin de répondre avec la meilleure réactivité possible aux demandes métier et aux pics d’activités, ces derniers pas toujours prévisibles.
Mais il ne s’agit pas seulement de pouvoir ‘gonfler’ l’infrastructure en ajoutant les ressources qui s’avèrent nécessaires, sinon – et surtout – de pouvoir ‘dégonfler’ celle-ci en réaffectant ces ressources par ailleurs. A l’image d’un ballon, plus l’infrastructure est élastique, plus elle est facile et rapide à gonfler et dégonfler.
Encore faut-il que les applications veulent bien s’y prêter.
Comme nous l’avons vu dans un post précédent – La qualité dans le cloud – la réduction des coûts reste la motivation principale pour la virtualisation et le cloud, suivi ensuite de l’aptitude á délivrer la capacité.
Lorsqu’il s’agit de dimensionner une infrastructure physique et un budget d’exploitation pour celle-ci, le modèle est le suivant :
Bon. J’avais décidé de ne pas faire un post chaque fois que le blog passait une nouvelle barre, mais c’est trop amusant. Continuer la lecture
J’ai continué à jouer avec le plugin City Model pour Sonar de eXcentia.
Pour ceux qui ont manqué les épisodes précédents, vous pouvez les trouver ici : City Model, City Model – Nouvelle version, La métrique ABC.
Ce plugin est vraiment très fun. Et tout le monde trouve fantastique une représentation visuelle de son code sous forme d’une cité. Aller à l’essentiel est important lorsque vous devez régulièrement juger de la qualité d’une application. Continuer la lecture