Comment fonctionne le support Drupal chez Droptica

Dans mon précédent article, j'ai décrit pourquoi nous avons créé une équipe de support Drupal distincte. Dans cet article, je vais décrire comment notre équipe de support Drupal fonctionne.

Objectifs de l'équipe de support Drupal

L'équipe de support Drupal chez Droptica a 3 objectifs principaux :

1. Assurer le fonctionnement continu de tous les sites web

Beaucoup de nos clients dépendent de l'opérationnalité de leurs sites web. Souvent, les applications que nous maintenons fonctionnent ou sont au cœur du business de nos clients. Les temps d'arrêt entraînent des plaintes, des pertes de revenus, etc. 

Notre équipe de support se concentre sur s'assurer que les sites web fonctionnent et réagit rapidement à tout problème ou erreur qui surgit. 

2. Garantir la sécurité des sites web

Les mises à jour de sécurité du cœur de Drupal et des modules sont publiées en permanence. Il en va de même pour les stacks technologiques exécutant Drupal - logiciels serveur, versions PHP, etc. Notre équipe de support veille à ce que tous les sites web soient à jour et ne présentent aucune vulnérabilité de sécurité connue. 

Lorsqu'une mise à jour de sécurité Drupal est publiée, nous devons mettre à jour plus de 100 sites web le plus rapidement possible. Pour cela, nous avons rationalisé les processus et les workflows qui sont maintenus par notre équipe de support.

3. Fournir des services de développement mineurs

De nombreux sites web après une phase de développement initiale n'ont pas besoin d'une équipe de développement à plein temps. Presque chaque site web, cependant, nécessite un peu de travail de temps en temps. Soit une nouvelle page d'accueil, soit une nouvelle intégration ou peut-être quelques corrections de bugs ou résolution de problèmes.

Tant que l'effort de développement n'est pas important, notre équipe de support aide aussi avec ces tâches. Si de nouvelles fonctionnalités nécessitent un plus grand effort, le travail est planifié et confié à l'une de nos équipes dédiées de développeurs Drupal.

Le processus de support

Chez Droptica, nous automatisons autant que possible. Pour nous assurer que nous ne perdons pas de temps et que nous fournissons les résultats les plus prévisibles, tous les sites web suivent le même processus.

Il existe un environnement de test automatisé

Chaque site web que nous prenons en charge pour support passe par un processus d'intégration qui nous permet de le maintenir facilement à l'avenir. Pendant l'intégration, nous créons ce qui suit :

1. Un environnement de développement reproductible sur Docker, qui ressemble autant que possible à l'environnement de production. 
2. Un environnement de test automatisé, accessible au client (un site de test). C'est là que nous préparons le travail pour nos clients afin qu'ils puissent l'inspecter avant de le déployer en production. Les clients peuvent également l'utiliser pour leurs tests et formations. Si besoin est, nous pouvons créer de multiples clones de ce site web.
3. Un processus automatisé de duplication d'un site de production vers les environnements de développement et de test. Ce processus nous permet, en appuyant sur un bouton, de copier la dernière version du site de production dans n'importe quel environnement et d'y déployer du nouveau code. 
4. Un mécanisme de déploiement automatisé, qui nous permet de publier rapidement et de manière prévisible de nouvelles modifications en production 

Grâce à l'automatisation, nous pouvons rapidement (en quelques minutes) copier un site de production vers le développement, inspecter une erreur et créer une solution pour celle-ci, l'envoyer à l'environnement de test pour tester le déploiement et également pour la présenter au client. Si elle est acceptée, la modification peut rapidement être automatiquement poussée en production.

Flux de travail des demandes de support

Nous encourageons nos clients à utiliser Jira mais certains préfèrent les emails ou Skype. Quelle que soit la méthode de communication, nous enregistrons chaque demande dans Jira. C'est à ce moment que commence la vie de la demande. Selon la gravité, l'urgence, le type de demande et le package de support du client, le ticket sera planifié en conséquence et attendra qu'un développeur disponible le prenne en charge. 

Après de nombreux essais, nous avons maintenant les statuts suivants dans Jira pour décrire les étapes dans lesquelles le ticket peut être :

1. À faire - le ticket est nouveau. Personne n'a encore travaillé dessus.
2. À retravailler - le ticket a été commencé mais n'est pas encore fini et n'est pas activement travaillé pour le moment. Cela peut être un ticket qui n'a pas réussi à passer notre équipe de contrôle qualité et a été renvoyé pour être amélioré ou un ticket qui a été commencé mais le développeur a dû passer à quelque chose de plus urgent.
3. En cours - un développeur travaille actuellement activement sur ce ticket. Cela se fait dans une branche séparée dans git qui sera fusionnée avec la branche principale uniquement lorsqu'elle aura passé le QA. Cela assure que nous déployons en production uniquement des solutions testées et fonctionnelles.
4. Retour/Impediment - le ticket a besoin d'input du client ou de quelqu'un (par exemple, un prestataire externe) et nous attendons plus d'informations.
5. Revue de code - un développeur a fini le travail et a créé une pull request avec le code. Elle attend maintenant une révision de la qualité du code. Un développeur senior révisera le code pour vérifier s'il est correct, fait sens et s'il respecte les standards de Drupal.
6. QA - le ticket a passé la revue de code et est maintenant en test par notre équipe de test (assurance qualité). Les types de tests ici peuvent varier de vérifications manuelles basiques à des tests de régression automatisés poussés de la fonctionnalité et de l'apparence. Typiquement, le QA construira automatiquement une version de test du site web sur la branche du développeur et effectuera tous les tests nécessaires. Si les tests réussissent, le client est informé qu'il peut tester la solution s'il le souhaite.
7. Revue PO - (revue du Product Owner) - nous pensons avoir terminé le travail et présenté le ticket pour revue au client sur un site de test.
8. Prêt à déployer - le Product Owner a accepté le travail et il est prêt à être déployé en production.
9. Fait - le code est déployé en production. Le travail sur ce ticket particulier est terminé.   

Ce qui précède décrit bien ce qui se passe avec chaque demande. Grâce à l'automatisation, nous pouvons facilement travailler sur divers tickets en parallèle, les tester et les déployer en production de manière sécurisée et prévisible. 

Les sites web de nos clients sont bien pris en charge.