Les rules, règles, viennent remplacer only/except dans les fichiers de CI de gitlab.
Cela permet d'étendre les conditions à d'autres variables et d'en simplifier l'écriture.
Comme tout bon produit, Gitlab propose une API REST pour contrôler son application. Cela va permettre d'automatiser des tâches répétitives telles que :
Jusqu'à peu de temps, j'utilisais essentiellement un seul repo gitlab (monorepo) pour gérer la plupart de mes projets. Mais voilà, certains projets ont tellement grossi que la gestion du ci est devenu trop complexe. Cela ralentit énormément la productivité et ce malgré l'utilisation des include.
En tant que développeurs, nous connaissons tous l'acronyme DRY : don’t repeat yourself Et donc nous savons tous qu'il faut autant que possible factoriser notre code. Pour nos Gitlab-ci, nous avons à notre disposition les templates.
Dans le cadre de l'automatisation du build et de l'intégration continue, je vous propose de voir comment générer des releases dans un CI GitLab.
Après vous avoir présenté une méthode utilisant postman/newman je suis parti d’une autre solution et je suis tombé sur dredd qui est nettement plus simple à mettre en oeuvre. En effet il fonctionne sans aucune création de fichier puisqu’il se base sur le fichier de déclaration de l’API.
En bon devops, on cherche tous à optimiser les temps de déploiement de nos applications, et bien voici une nouveauté du CI de Gitlab qui va permettre d’y parvenir : les DAG pour Directed Acyclic Graphs.
Pouvoir tester ces endpoint d’API fait parti des impératifs avant tout déploiement d’une nouvelle version pour voir si une régression entre autre n’est pas survenue avec cette mise jour.
A ce jour il existe peu d’outils permettant de le faire assez rapidement. L’idée est de pouvoir à partir du fichier de description de votre API générer en quelques clics voir automatiquement les tests. Ce traitement pourra bien sur être intégré dans votre CI via une image docker. Nous verrons aujourd’hui la solution Postman et de son compagnon Newman.