Mon parcours HNG. Sixième étape : exploiter Python pour exposer les métriques DORA

Introduction

Pour l'étape 6, nous avons été chargés d'exposer DORA (DevOps Research) et je me suis récemment lancé dans un projet visant à exposer les métriques DORA (DevOps Research and Assessment) à l'aide de Python. Cette expérience m'a appris de précieuses leçons sur les pratiques DevOps et les subtilités de travailler avec des API. Dans cet article, je vais vous guider tout au long du processus, expliquer la signification de chaque métrique et souligner quelques pièges courants à surveiller.

Que sont les métriques DORA ?
Avant de plonger dans le code, discutons brièvement de ce que sont les métriques DORA :

• Fréquence de déploiement : à quelle fréquence une organisation réussit à passer en production.
• Délai de mise en œuvre des modifications : le temps nécessaire à un engagement pour passer en production.
• Taux d'échec des modifications : pourcentage de déploiements provoquant un échec en production.
• Délai de restauration du service : combien de temps faut-il pour se remettre d'une panne de production.

Ces métriques aident les équipes à mesurer leurs performances de livraison de logiciels et à identifier les domaines à améliorer.

Démarrage
Pour commencer à exposer ces métriques, vous aurez besoin de :

• Python 3.7 ou supérieur
• Un compte GitHub et un jeton d'accès personnel
• Connaissance de base de l'API de GitHub

Tout d'abord, installez les bibliothèques nécessaires :

pip install requests prometheus_client

La structure du code
J'ai structuré mon script Python comme une classe appelée DORAMetrics. Voici une version simplifiée de son initialisation :

class DORAMetrics:
    def __init__(self, github_token, repo_owner, repo_name):
        self.github_token = github_token
        self.repo_owner = repo_owner
        self.repo_name = repo_name
        self.base_url = f"https://api.github.com/repos/{repo_owner}/{repo_name}"
        self.headers = {
            'Authorization': f'token {github_token}',
            'Accept': 'application/vnd.github.v3+json'
        }

        # Define Prometheus metrics
        self.deployment_frequency = Gauge('dora_deployment_frequency', 'Deployment Frequency (per day)')
        self.lead_time_for_changes = Gauge('dora_lead_time_for_changes', 'Lead Time for Changes (hours)')
        self.change_failure_rate = Gauge('dora_change_failure_rate', 'Change Failure Rate')
        self.time_to_restore_service = Gauge('dora_time_to_restore_service', 'Time to Restore Service (hours)')

Cette configuration nous permet d'interagir avec l'API GitHub et de créer des métriques Prometheus pour chaque métrique DORA.

Récupération de données depuis GitHub
L’un des aspects les plus difficiles consistait à récupérer les données nécessaires depuis GitHub. Voici comment j'ai récupéré les déploiements :

def get_deployments(self, days=30):
    end_date = datetime.now()
    start_date = end_date - timedelta(days=days)

    url = f"{self.base_url}/deployments"
    params = {'since': start_date.isoformat()}
    deployments = []

    while url:
        response = requests.get(url, headers=self.headers, params=params)
        response.raise_for_status()
        deployments.extend(response.json())
        url = response.links.get('next', {}).get('url')
        params = {} 

    return deployments

Cette méthode gère la pagination, garantissant que nous obtenons tous les déploiements dans le délai spécifié.

Calcul des métriques DORA
Voyons comment j'ai calculé la fréquence de déploiement :

def get_deployment_frequency(self, days=30):
    deployments = self.get_deployments(days)
    return len(deployments) / days

Ce calcul simple nous donne le nombre moyen de déploiements par jour sur la période indiquée.

Délai pour les modifications
Le calcul du délai de réalisation des modifications était plus complexe. Cela nécessitait de corréler les commits avec leurs déploiements correspondants :

def get_lead_time_for_changes(self, days=30):
    commits = self.get_commits(days)
    deployments = self.get_deployments(days)

    lead_times = []
    for commit in commits:
        commit_date = datetime.strptime(commit['commit']['author']['date'], '%Y-%m-%dT%H:%M:%SZ')
        for deployment in deployments:
            if deployment['sha'] == commit['sha']:
                deployment_date = datetime.strptime(deployment['created_at'], '%Y-%m-%dT%H:%M:%SZ')
                lead_time = (deployment_date - commit_date).total_seconds() / 3600  # in hours
                lead_times.append(lead_time)
                break

    return sum(lead_times) / len(lead_times) if lead_times else 0

Cette méthode calcule le décalage horaire entre chaque commit et son déploiement correspondant. Il est important de noter que tous les commits ne peuvent pas aboutir à un déploiement, nous ne prenons donc en compte que ceux qui le font. Le résultat final est le délai moyen en heures.
L’un des défis auxquels j’ai été confronté ici consistait à faire correspondre les engagements aux déploiements. Dans certains cas, un déploiement peut inclure plusieurs validations, ou une validation peut ne pas être déployée immédiatement. J'ai dû faire des hypothèses basées sur les données disponibles, qui pourraient nécessiter des ajustements pour différents flux de travail de développement.

Taux d'échec des modifications
La détermination du taux d'échec des changements nécessitait d'analyser l'état de chaque déploiement :

def get_change_failure_rate(self, days=30):
    deployments = self.get_deployments(days)

    if not deployments:
        return 0

    total_deployments = len(deployments)
    failed_deployments = 0

    for deployment in deployments:
        status_url = deployment['statuses_url']
        status_response = requests.get(status_url, headers=self.headers)
        status_response.raise_for_status()
        statuses = status_response.json()

        if statuses and statuses[0]['state'] != 'success':
            failed_deployments += 1

    return failed_deployments / total_deployments if total_deployments > 0 else 0

Cette méthode compte le nombre de déploiements ayant échoué et le divise par le nombre total de déploiements. Le défi ici consistait à définir ce qui constitue un déploiement « raté ». Je considérais qu'un déploiement avait échoué si son statut le plus récent n'était pas « succès ».
Il convient de noter que cette approche peut ne pas prendre en compte tous les types d'échecs, en particulier ceux qui surviennent après un déploiement réussi. Dans un environnement de production, vous souhaiterez peut-être l'intégrer à votre système de surveillance ou de gestion des incidents pour une détection plus précise des pannes.

Exposer des métriques avec Prometheus
Pour que Prometheus puisse récupérer ces métriques, j'ai utilisé la bibliothèque prometheus_client :

from prometheus_client import start_http_server, Gauge

# In the main execution block
start_http_server(8000)

# Update metrics every 5 minutes
while True:
    dora.update_metrics()
    time.sleep(300)

Cela démarre un serveur sur le port 8000 et met à jour les métriques toutes les 5 minutes.

Pièges courants
Durant ce projet, j'ai rencontré plusieurs défis :

• Limitation du débit API : GitHub limite le nombre de requêtes API que vous pouvez effectuer. J'ai dû mettre en œuvre la pagination et faire attention à la fréquence à laquelle je mettais à jour les métriques.
• Autorisations du jeton : assurez-vous que votre jeton GitHub dispose des autorisations nécessaires pour lire les déploiements et les validations.
• Interprétation des données : déterminer ce qui constitue un « déploiement » ou un « échec » peut être subjectif. J'ai dû faire des hypothèses basées sur les données disponibles.
• Délai de restauration du service : cette mesure était particulièrement difficile car elle nécessite généralement des données provenant d'un système de gestion des incidents, qui ne sont pas disponibles uniquement via l'API de GitHub.

Conclusion
Exposer les métriques DORA à l'aide de Python a été une expérience enrichissante. Cela a approfondi ma compréhension des pratiques DevOps et amélioré mes compétences en matière de travail avec les API et de traitement des données.
N'oubliez pas que ces mesures sont destinées à guider l'amélioration, et non à servir de bâton pour battre les équipes. Utilisez-les judicieusement pour favoriser une culture d’amélioration continue dans votre processus de développement.
Merci d'avoir lu ❤

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!