Tout d’abord, il me semble important de définir ce que sont les concepts d’intégration et de déploiement continu.
L’intégration continue est l’ensemble des processus automatisés permettant :
· Le merge des branches
· La construction d’artefacts (qui pourront être déployés)
· L’ensemble des tests possibles sans l’exécution du programme (Tests unitaires, tests de sécurité avec Fortify, qualité de l’artefact…)
Le déploiement continu est l’ensemble des processus automatisés permettant le déploiement sur un serveur d’une version de l’application. Cela comprend :
· L’intégration continue
· Le déploiement
· Les tests après déploiement (tests fonctionnels, charges…)
Voici un schéma récapitulatif :
Pourquoi ces processus ? Quel est le but recherché ?
Le but de ces processus est d’améliorer les mises en production d’une application et ce de différentes manières :
· Améliorer la confiance sur la qualité de l’application
· Améliorer le temps de mise sur le marché
· Livrer plus souvent
· Réduction du coût total du produit (industrialisation)
Comment atteindre ces buts ?
Ces processus d’intégration et de déploiement continus ont vocations à être exécuté aussi souvent que possible (but : livrer plus souvent).
Il faut donc
· Tester souvent (tests unitaires, sécurité fonctionnel, charges…)
· Construire les nombreux paquets (ou artefacts)
· Déployer (dans le cas du déploiement continu)
De plus, pour pouvoir le faire souvent il faut que ces processus soient rapides ! Si l’ensemble de ces étapes prend plusieurs heures ou jours il est alors impossible de le faire régulièrement. Le challenge est alors d’optimiser le temps d’exécution de ces processus.
Il faut donc faire une sélection drastique des tests à exécuter et avoir une batterie de test qui permet d’assurer un matelas de sécurité à chaque implémentation… Il faut donc une campagne de tests vitaux… Ici, par campagne de tests vitaux, je compte également les cas de performance, de sécurité, etc… à ajouter. On a alors des tests vitaux fonctionnels, de performance, de sécurité…
L’automatisation étape obligatoire !
Malheureusement, cette sélection seule n’est pas suffisante. Afin de de s’assurer une exécution rapide et régulière l’automatisation est quasiment obligatoire. Comme vous le savez, l’intérêt principal des tests automatisés est le fait que l’exécution ne coûte quasiment rien et peut être beaucoup plus rapide que les tests manuel rendent leur utilisation obligatoire.
De plus le temps de transition entre ces phases doit être aussi court que possible, l’automatisation de ces enchainements permet également de gagner beaucoup de temps.
Enfin, aucun testeur ne pourrait plusieurs fois par jours pendant des mois toujours faire les mêmes cas de test et gardant une qualité optimale. Au bout d’un moment son attention diminue à force de toujours répéter les mêmes tâches, ce n’est pas le cas avec les tests automatisés (qu’il faut quand même maintenir).
Conclusion
Les points forts de l’automatisation (rapidité d’exécution, exécution peu coûteuse, pas de différence entre les runs) sont exactement tous les besoins du métier DevOps et des processus d’intégration et de déploiement continu. Dans ce cas le ROI est évident, les tests sont très souvent exécutés ET permettent la mise en place de processus à forte valeur ajoutée pour le client final.
Sans ces processus, Facebook n’aurait jamais pu mettre en place en 1 jour unes fonctionnalité comme le Safety Check.
Article écrit avec l’aide de Mickaël Carlin
Outil de gestion de branche : GIT – GITLab
Outil de déploiement : Chef, Ansible
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
