Dernier article pour cette série sur comment faire un dashboard qui déchire avec Dashing. Nous avons préalablement vu pourquoi utiliser dashing, puis nous avons vu comment faire un super widget giphy, aujourd’hui je vous propose de finir avec un widget JIRA.

Tout d’abord, avant d’attaquer la partie technique laissez-moi vous expliquer pourquoi ce widget nous est utile.

Notre équipe est organisée dans une logique Kanban, c’est-à-dire que nous travaillons en flux tiré et nous nous efforçons de limiter l’encours. Afin de gérer notre flux nous utilisons principalement deux outils : le suivi du nombre d’éléments en cours et notre « throughput », c’est-à-dire notre débit. C’est ce deuxième indicateur qui va nous intéresser aujourd’hui.

Après avoir étudié notre débit pendant plusieurs semaines, nous nous sommes rendu compte que nous délivrions environ quinze éléments en quinze jours.

Nous allons donc faire une petite jauge pour dashing pour visualiser en temps réel le nombre d’élément qui sont sortis les quinze derniers jours et ainsi avoir un feedback pour nous prévenir lorsque ce nombre chute (ou pour nous arrêter boire un coup s’il augmente trop 😉 ).

Je pars du principe que vous avez lu l’article précédent et donc que vous avez déjà un embryon de dashboard à minima.

Pour commencer nous allons donc ajouter à notre dashboard (/dashboard/foodash.erb) un nouveau widget de type « meter » :

<li data-row="1" data-col="1" data-sizex="1" data-sizey="1">
      <div data-id="throughtput" data-view="Meter" data-title="Nb tickets DONE (15j)" data-min="0" data-max="30"></div>
    </li>

Nous utilisons pour le moment le widget de base, si vous démarrez votre dashboard vous devriez avoir quelque chose comme ça :

Bien, passons à l’alimentation de notre widget. Nous allons maintenant créer un fichier jira.rb dans le répertoire jobs :

# encoding: utf-8
require 'httparty'

require 'json'

SCHEDULER.every '5m', :first_in => 0 do |job|

nbDays = 15

auth = {:username => "USERNAME", :password => "PASSWORD"}

url_jira = "http://your.jira.com/rest/api/2.0.alpha1/search?jql="

issues_done = getIssues(url_jira, auth, nbDays)

send_event(:throughtput, value: issues_done.length)

end

def getIssues(url_jira, auth, nbDays)

jql = 'project=SEC AND status=Closed AND resolution = Fixed AND type!=Epic AND resolutiondate>startOfDay(-'+nbDays.to_s+")"

url = url_jira+ERB::Util.url_encode(jql)

res = HTTParty.get(url, :basic_auth => auth)

return res["issues"]

end

A noter qu’en fonction de votre version de jira, il faudra que vous modifiez l’appel à l’API, mais ce ne devrait pas être bien compliqué à migrer. J’ai par facilité préféré utiliser une authentification par login/password. Dans l’idéal il faudrait transformer ceci en authentification oauth (si quelqu’un veut proposer une amélioration ce sera avec plaisir). Attention à bien penser à encoder l’url sinon il y a de grande chance pour que l’appel à Jira ne fonctionne pas.

Suite à la création de notre job, notre widget se met à jour automatiquement toutes les cinq minutes :

Maintenant, ce que nous souhaitons faire c’est y apporter un peu de couleur pour faciliter la lecture. Dans l’idéal notre widget sera vert si nous avons fini au moins 12 éléments, jaune jusqu’à 9, puis rouge en deçà (bornes définies avec l’équipe).

Nous ajoutons donc dans notre job une petite méthode pour définir la couleur (méthode bien verbeuse pour en faciliter la lecture cher lecteur) :

def getBackgroundColorByNBIssuesDone(nbIssues)
hotness = "cool"
if nbIssues < 12
hotness = "warm"
if nbIssues < 9
hotness = "hot"
end
end
return hotness
end

Et nous modifions le send event pour envoyer également cette couleur au widget : 

send_event(:throughtput, value: issues_done.length, hotness: getBackgroundColorByNBIssuesDone(issues_done.length))

Pour que la couleur de fond soit modifié nous allons modifier le fichier coffeescript de notre widget meter, widgets/meter/meter.coffee et ajouter cette partie :

onData: (data) ->
node = $(@node)
hotcss = switch
when data.hotness == "cool" then "#00C176"
when data.hotness == "warm" then "#FABE28"
when data.hotness == "hot" then "#FF003C"

$(@node).css("background-color", hotcss)

Ainsi notre widget ressemblera à ça :

Ou sinon :

 

 

 

 

 

 

 

Voilà, notre widget est déjà terminé. Comme vous l’avez-vu, nous avons quelque chose de très précis, facile à lire et ceci pour tout juste une trentaine de ligne de code. De plus, cette jauge colorée pourra être réutilisée pour d’autres indicateurs.

C’est ainsi que se termine cette série d’article Dashing, j’espère que cela vous aura donné envie de vous lancer, vous aussi, dans la création de joli dashboard très utile. Si vous avez besoin d’aide, n’hésitez pas à nous contacter.

Bon que ce soit bien clair : je n’aime pas et je n’ai jamais aimé les dashboards électroniques que l’on peut créer via Jira, Redmine, ou peut importe le logiciel de suivi de besoins.
Je trouve déterminant la mise en place d’un management visuel « physique » (c’est-à-dire bien visible, facilement modifiable et partagé par toute l’équipe) pour la bonne marche d’une équipe.
Et puis il y a dashing. Cela lui là je l’aime bien. Il faut que je vous raconte pourquoi…

Découverte et premier dashboard

J’ai découvert Dashing il y a quelques mois grâce à Vincent et Philippe. C’est un outil open source et gratuit créé par une boite américaine Shopify. J’ai regardé l’outil, vu la démo. C’est cool et c’est joli en effet …
bon …
je retourne bosser.

Mais Philippe insiste. Il envisionne la création d’un dashboard électronique qui nous permettrait de voir en un clin d’oeil si tout est ok sur l’équipe ou non. Son idée est d’avoir des widgets qui soient intégralement verts lorsque tout roule et rouges lorsqu’il y a un soucis et qu’il faut prendre une action.
Un peu pour lui faire plaisir et un peu par curiosité je décide de m’y mettre. Je vois qu’il existe de nombreux widgets, certains attirent mon attention comme le widget Jenkins (état de l’intégration continue), ou le widget Rickshaw graph  qui permet de faire de jolies graphiques.
Cependant, je ne trouve pas forcement mon bonheur pour tout et je me rends vite compte qu’il faudra vite faire du custom…

Je me lance en me posant la question « que voulons nous voir ? » (et non pas : « que pouvons-nous voir ? » ) :

• Certains jobs Jenkins (intégration continue) tombent en échec et nous les laissons parfois rouge quelques jours ce qui nous pose beaucoup de problèmes. 
• Nous avons un mécanisme de réalimentation d’un référentiel qui se lance trois fois par semaine en soirée et celui-ci crash de temps en temps. L’impact est très mineur, mais au plus l’analyse est faite tardivement au plus celle-ci est compliquée.
• L’humeur de l’équipe de teammood. Lorsque certaines journées sont mauvaises (deux/trois membres de l’équipe mettent un mauvais mood) ou au contraire très bonnes, nous ne nous en rendons compte que quelques jours après et il est trop tard pour discuter et comprendre ce qu’il s’est passé.
• Nous avons mis en production un module de floutage automatique des plaques d’immatriculation de voitures et nous nous regardons quasiment quotidiennement ces résultats sur kibana.

Après quelques tâtonnements j’arrive à un premier résultat (note : certaines parties business sont volontairement masquées, désolé 🙂 ) :

C’est encourageant. Avec l’équipe nous jugeons que ce premier opus a assez de valeurs et nous installons donc dashing sur un serveur et demandons un écran dédié pour l’afficher en continue sur notre bureau, bien visible par tous.

Lire la suite →