Refacto/makefile

Contexte :

Le Makefile précédent était fonctionnel mais souffrait de certains inconvénients en termes de lisibilité, maintenabilité et modularité. Il centralisait une grande partie des tâches dans un seul fichier, incluant des environnements comme OVH et Outscale avec des règles spécifiques pour chaque environnement. Pour améliorer cette situation, nous avons décidé de le refactorer afin de mieux organiser les tâches et de faciliter les futures évolutions.

Avant : L’ancien Makefile avait une structure monolithique avec une duplication de code pour différentes tâches (init, plan, apply, destroy, beauty) selon l'environnement (ovh, outscale). Par exemple :

init_ovh: check
	terraform -chdir=./10_backend_ovh init -backend-config=$(DIMAIL_CONFIG_PATH)/env-$(DIMAIL_ENV)/backend.tfbackend -reconfigure
	terraform -chdir=./20_network init -backend-config=$(DIMAIL_CONFIG_PATH)/env-$(DIMAIL_ENV)/backend.tfbackend -reconfigure
	terraform -chdir=./30_vms init -backend-config=$(DIMAIL_CONFIG_PATH)/env-$(DIMAIL_ENV)/backend.tfbackend -reconfigure

init_outscale: check
	terraform -chdir=./30_outscale init -backend-config=$(DIMAIL_CONFIG_PATH)/env-$(DIMAIL_ENV)/backend.tfbackend -reconfigure

Cette structure répétait plusieurs blocs similaires pour des environnements et configurations différentes, rendant le fichier lourd à modifier et difficile à maintenir.

Modifications apportées :

1. Séparation des environnements et des règles spécifiques :
   • Les tâches spécifiques à un environnement, comme OVH ou Outscale, ont été déplacées dans des fichiers Makefile séparés.
   • Cela permet de réduire la duplication de code et de mieux organiser les commandes par environnement.
2. Règles centralisées et génériques :
   • Les tâches génériques telles que init, plan, apply ou destroy appellent désormais des règles spécifiques à l'environnement via des sous-Makefiles inclus dynamiquement.
   • Cela simplifie la lecture du Makefile principal et permet de gérer facilement de nouveaux environnements ou de nouvelles configurations.
3. Modularité accrue :
   • L’ancien Makefile était monolithique et contenait beaucoup de tâches imbriquées. Désormais, chaque fichier Makefile correspondant à un environnement contient uniquement les tâches qui le concernent. Le Makefile principal se contente de les inclure, selon la configuration choisie.
4. Meilleure gestion des vérifications :
   • Les vérifications d'environnement et de configuration (comme DIMAIL_ENV ou DIMAIL_HOSTING) ont été isolées dans un fichier séparé, ce qui facilite leur réutilisation et leur maintenance.

Nouveau Makefile principal :

Le Makefile principal est maintenant simplifié et se contente de déléguer les appels aux sous-Makefiles :

default: 
	@echo "Usage: make <init|plan|apply|destroy|beauty|test>"

include makefiles/env_checks.mk
include makefiles/$(DIMAIL_HOSTING).mk

Avantages de cette refactorisation :

• Modularité : l'ajout ou la modification d’un environnement devient plus facile grâce à la séparation des fichiers.
• Lisibilité : le Makefile principal est plus concis et facile à comprendre.
• Maintenance facilitée : la gestion des tâches spécifiques à un environnement se fait désormais dans un fichier dédié, évitant ainsi les risques d'erreurs lors de modifications ou d’ajouts de nouvelles règles.

Instructions de test :

• Commandes principales : tester les commandes init, plan, apply, destroy, et beauty pour chaque environnement (OVH, Outscale).
• Vérifications : s’assurer que les vérifications des environnements et configurations se comportent comme prévu.
• Tests Ansible : la commande make test doit toujours fonctionner pour exécuter les tests Python sur les plugins Ansible.

L'utilisation de %:

Avec l'introduction de la règle générique %, nous avons automatisé l'exécution des vérifications communes (check) avant chaque tâche, simplifiant ainsi la gestion des environnements. Cela permet de garantir que les prérequis de chaque environnement sont validés avant toute action, sans avoir à répéter explicitement ces vérifications dans chaque tâche. Cependant, cette automatisation n'empêche pas OVH ou tout autre environnement de conserver ses tâches spécifiques, comme apply_backend, apply_network et apply_vms, qui exécutent des commandes Terraform distinctes pour chaque composant. Ces tâches restent séparées, permettant un contrôle granulaire sur les processus d'application tout en bénéficiant de l'automatisation des vérifications.