Photo par JJ Ying

Créer dynamiquement un pipeline par défaut avec Terraform dans Azure DevOps

Configurez les build definitions

Créé par Damien Aicheh le 27/10/2022 · 5 mins

Dans ce tutoriel, nous allons configurer le pipeline par défaut pour chaque repository que nous avons créé précédemment associé à notre projet Azure DevOps en utilisant Terraform !

Ce tutoriel fait partie d’une série complète de tutoriels sur la configuration d’Azure DevOps à l’aide de Terraform. Vous pouvez télécharger le projet de la partie précédente et suivre.

Cas d’usage

L’idée est de préparer le projet afin que l’équipe démarre avec le minimum de configuration pour ajouter un processus d’intégration et de livraison continue (CI/CD). Donc, pour les encourager à le faire au tout début du projet, vous pouvez directement créer un premier pipeline pour construire le projet à l’aide de Terraform.

Nous allons donc créer deux choses :

  • La définition de build qui cible le azure-pipelines.yml que nous avons précédemment ajouté aux repositories
  • Un groupe de variables pour stocker leurs potentiels secrets

De cette façon, vous configurez les conventions de dénomination à suivre, afin que les équipes aient un exemple sur lequel se baser.

Définition du groupe de variables

Créons un nouveau fichier appelé variables_group.tf, par défaut nous voulons y stocker le domaine et le nom de l’application. Après cela, l’équipe a suffisamment de droits pour ajouter ses propres variables et secrets dans le groupe dédié.

resource "azuredevops_variable_group" "this" {
  count        = length(var.repositories)
  project_id   = azuredevops_project.this.id
  name         = "${var.repositories[count.index].domain}.${var.repositories[count.index].application}.shared"
  description  = "The Variable Group for ${title(var.repositories[count.index].domain)} ${title(var.repositories[count.index].application)}"
  allow_access = true

  variable {
    name  = "Domain"
    value = var.repositories[count.index].domain
  }

  variable {
    name  = "Application"
    value = var.repositories[count.index].application
  }
}

Pour être plus flexible, nous ajoutons le préfixe shared à la fin du nom du groupe afin que les équipes puissent ensuite ajouter un autre groupe avec un autre préfixe si nécessaire, comme dev, stagging, prod, etc.. Vous pouvez trouver les définitions des secrets dans la documentation de Terraform.

Ajouter une définition de build

Dans le tutoriel précédent, nous avons ajouté un fichier azure_pipeline.yml par défaut dans chaque dépôt. Il est temps de l’utiliser !

Ajoutez un nouveau fichier appelé build_definition.tf, et pour chaque repository, vous pouvez créer la définition de build qui lui est associée.

resource "azuredevops_build_definition" "build_definitions" {
  count      = length(var.repositories)
  project_id = azuredevops_project.this.id
  name       = "${var.repositories[count.index].domain}_${var.repositories[count.index].type}_${var.repositories[count.index].application}"

  repository {
    repo_type   = "TfsGit"
    branch_name = "refs/heads/develop"
    repo_id     = azuredevops_git_repository.this[count.index].id
    yml_path    = "azure_pipelines.yml"
  }

  ci_trigger {
    use_yaml = true
  }
}

Cela fait, l’équipe n’aura plus qu’à mettre à jour azure_pipeline.yml pour répondre à ses besoins sans avoir à demander à l’administrateur le droit de créer ce premier pipeline.

Vous pouvez trouver toutes les propriétés disponibles dans la documentation de Terraform.

Executer Terraform

Vous pouvez maintenant exécuter la nouvelle commande de planification de Terraform comme ceci :

terraform plan -var-file=env.tfvars --out=plan.out

Et puis appliquez-le plan:

terraform apply plan.out

En conséquence, vous devriez voir dans Azure DevOps, vos définitions de build dans la section Pipelines et dans la section Library, le groupe de variables !

Touche finale

Les définitions de build avec leur groupe de variables associées ont été générées dans Azure DevOps à l’aide de Terraform. Vous trouverez le code source complet dans ce repository Github.

Et après?

Dans le prochain tutoriel de cette série, nous nous concentrerons sur l’ajout de politiques à chaque repository!

N'hésitez pas à me suivre sur pour ne pas rater mon prochain tutoriel !