Etape 2 - outiller le macro-processus Dev-Ops

3.3 Etape numéro 2 : outiller le macro-processus Dev-Ops

Le processus Dev-Ops ainsi structuré doit être examiné afin de voir comment l’accélérer.

3.3.1 Premier axe : accélérer l’enchaînement des activités et viser le zéro défaut

Le premier axe, le plus facile à traiter, est de prendre l’enchaînement d’activités tel quel et d’en accélérer le traitement. Cela sera fait obligatoirement par l’outillage du processus. Cela permettra aussi de viser le zéro défaut (un défaut fait perdre du temps à le corriger, donc autant éviter les défauts).

Il y a deux familles d’outils qu’il va falloir mettre en musique pour y arriver :

  • une série outils spécialisés qui vont automatiser les différentes phases Dev-Ops, par exemple :

    • outils d’automatisation des tests

    • outils d’automatisation des déploiements

  • une série d’outils de gestion d’éléments de configuration (au sens ITIL® et au sens développement), par exemple :

    • gestion des configurations logicielles (développement)

    • gestion des versions définitives (processus ITIL® de gestion des déploiements et des mises en production)

    • gestion des configurations de production (processus ITIL® de gestion des configurations)

Un outil fédérateur de gestion et de pilotage sera aussi nécessaire : les outils de Business Process Management sont des candidats idéaux pour cela, à condition qu’ils puissent s’interfacer et piloter les autres outils impliqués dans la démarche.

La conception des environnements de développement, d’intégration et d’exploitation devront avoir inclus dans leur réflexion la facilité et l’efficacité maximale d’outils automatisés concernant le processus Dev-Ops.

3.3.2 Second axe : permettre les digressions et les boucles contrôlées dans le processus Dev-Ops

Un processus, pour être pratique, doit autoriser en permanence la possibilité de faire autre chose ou autrement que ce qui est imposé dans le flux de traitement.

Les utilisateurs du processus doivent pouvoir (sous condition de savoir ce qu’ils font) :

  • traiter certaines activités « dans le désordre » (en fait, le flux de traitement ou une partie est vu comme une check-list où chaque élément peut être traité indépendamment des autres)

  • reboucler sur une partie du processus afin de rejouer cette partie : cela est intéressant pour raccourcir les délais ; il n’est plus utile de dérouler tout le processus et de le redéclencher pour rejouer la partie qui nous intéresse ; cela est utile lors de la mise en place du mode Agile

Il va falloir aussi accompagner et automatiser au maximum ces digressions et ces boucles contrôlées.

La programmation ou le paramétrage d’un outil de traitement de flux va donc d’avérer plus complexe que la simple mise en place d’un processus séquentiel. Beaucoup de ces logiciels proposent ce type de fonctionnalités (sous-processus par exemple) mais s'avèrent plus ou moins complexes à mettre en oeuvre selon l'ergonomie des logiciels.

3.3.3 Un outil de gestion et de pilotage qui va faire office de chef d’orchestre

Il existe sur le marché bon nombre de logiciels pouvant répondre à ce type de cahier des charges, en plus de l’arsenal classique de tout logiciel de gestion de flux de travail.

Je citerai Serena Software qui est une plate-forme complète de gestion de flux de travail, avec des boîtes de processus prêts-à-l’emploi et la possibilité d’avoir des activités automatisées.

Il existe deux types d'activités :

  • activités réalisées par un humain : elle est simplement signalée dans le logiciel (avec les résultats obtenus) par la personne à la fin de la réalisation de cette activité

  • activités automatisées : elles sont réalisées par des outils logiciels et l’outil de gestion et de pilotage doit pouvoir déclencher automatiquement ceux-ci et pouvoir recevoir un message lui signalant la fin de la réalisation de l’activité et le résultat obtenu pour le traiter et savoir quoi faire dans la suite du processus.

    Serena Software permet de le faire avec pal mal de possibilités techniques afin de s’adapter aux possibilités techniques d’interface du logiciel qui doit réaliser l’activité (email, webservices, etc.).

    C’est ce que Serena Software appelle l’orchestration des services.