Fait vécu. Votre chef de développement désire bâtir un pont entre votre outil de billetterie (helpdesk ou logiciel de gestion de services) et sa plateforme de développement Agile. Il vous demande de développer ce pont afin de supporter notamment une série de tests automatisés.
Dans une optique DevOps, ces types de systèmes peuvent communiquer ensemble et partager des données cruciales en support aux processus en place. Il est néanmoins utile de simplifier leur intégration.
Ainsi, à l’aide de type d’événements Service Hook, un département informatique peut entre autres gérer plus facilement les sorties de version logicielle, faire le suivi de bogues et de nouvelles stories.
L’objectif est de réduire les coûts d’opérations et de mieux livrer des services / applications à valeur ajoutée. Accélérer le développement de ces livraisons demandent une plus grande collaboration, voire une synchronisation entre les équipes de développement et celles aux opérations. Pour s’assurer que les développeurs se concentrent à faire évoluer le système sans devoir faire la gestion des bogues, il est bénéfique d’intégrer ces outils de développement logiciels à des systèmes opérationnels tels que les outils ITSM.
On parle alors un cycle de développement DevOps.
Voici quelques scénarios où votre outil de gestion de services et Azure DevOps peuvent communiquer de façon bilatérale.
Dans le cadre d’une gestion de projets ou de développement logiciel end-to-end, l’identification et la prise en charge des bogues est importante. Si votre équipe cherche à mieux suivre les incidents soulevés par l’assurance qualité, l’application ITSM peut créer des bons de commande (Work items) ou modifier les items déjà inscrits dans Azure DeVops (VSTS).
L’inverse s’applique aussi dans le cas où une information change dans VSTS ; celle-ci peut venir changer le statut du billet dans le logiciel de gestion de services (ITSM), modifier son sommaire, etc.
Disons que vous avez en main Azure DevOps ou toute autre solution de développement logiciel Agile et que vous recevez bon nombre de demandes de service d’améliorations à apporter au système.
En traitant ces demandes avec votre solution ITSM, on peut maintenant créer une story dans Azure DevOps à partir de ces mêmes billets.
Lorsque votre client qui a demandé l’amélioration « X » désire un état de progression, Azure DevOps est en mesure de mettre à jour les valeurs, dont l’état d’avancement dans l’outil de gestion de services par exemple, afin de communiquer avec le client en toute transparence.
Prenons un autre exemple, celui de générer des tests automatisés. L’approche Agile, rappelons-le, permet de gérer le développement parallèle de stories qui doivent ensuite passer l’épreuve des tests. Plusieurs entreprises ont déjà pris le virage de l’automatisation et tentent d’accélérer le processus, incluant la portion assurance qualité.
Le pont entre Azure DevOps et l’outil ITSM vous permet ainsi de lancer des tests suite à la programmation d’une nouvelle fonction par exemple ; une fois que l’équipe de développement commet et automatise le « build » sur Azure DevOps, des tests sont lancés et un billet peut être créé dans l’outil de billetterie. On peut alors notifier l’équipe de développement et l’équipe QA pour le suivi de cet extrant.
Synchroniser la création de billets suite à des bris ou « failure » de compilation peut également vous sauver beaucoup de temps. Un incident est immédiatement créé et une notification est envoyée aux développeurs qui pourront réagir rapidement sur l’erreur.
Plusieurs autres actions sont possibles dans le cadre d’un processus de déploiement (release management) – création de billets, modification de billet, appels de service web supplémentaire, modification d’une valeur.
La plupart des cycles de développement doivent aussi gérer des scénarios où des demandes de changements peuvent ralentir le travail ou le dupliquer. Ces changements comportent souvent de nombreux niveaux de vérification et de conformité, en lien avec des équipements physiques ou intangibles.
Un exemple d’intégration est d’initier une demande de changement et de pouvoir en suivre le détail opérationnellement. La solution idéale est supportée avec la plupart des outils ITSM; la demande de changement initiée sur Azure DevOps peut synchroniser des valeurs et activer un flux de travaux dans l’outil ITSM pour aviser le CAB du changement, puis poursuivre avec ses prochaines tâches.
Plusieurs déclencheurs sont possibles selon votre besoin et ses paramètres. Des problèmes ou défectuosités peuvent survenir du côté du développement logiciel ou du côté des opérations.
L’équipe de développement doit pouvoir rapidement identifier les potentiels « vrais problèmes » des erreurs connues. Pour ne pas qu’elle soit constamment dérangée par des faux problèmes, l’intégration logiciel ITSM / Azure DevOps permet la création de problèmes dans le backlog Azure et peut monitorer les mises à jour en lien avec ces mêmes problèmes.
Les nouvelles informations pertinentes peuvent ensuite être renvoyés aux opérations pour en informer les clients/usagers impactés.
Selon les scénarios et besoins priorisés, il est possible d’orchestrer ces résultats d’intégration out-of-the-box ou encore développer des ponts personnalisés entre votre outil ITSM et votre plateforme de développement Agile. Ces cas d’intégration se multiplieront rapidement, les organisations recherchant à faire progresser l’efficacité de leurs processus de déploiement.
Vous retrouvez une liste non-exhaustive de Service Hook, qui représente des types d’événements possibles.