Retours en arrière et reprise après sinistre
Concevez et mettez en œuvre des procédures efficaces de retour en arrière et des plans de reprise après sinistre dans vos pipelines d’intégration et de livraison continues.
Retours en arrière et reprise après sinistre est une leçon CI/CD with GitHub Actions & DevOps Pipelines gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage CI/CD with GitHub Actions & DevOps Pipelines, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours CI/CD with GitHub Actions & DevOps Pipelines comprend 4 leçons au total.
Des problèmes inattendus peuvent survenir !
Le développement logiciel ne se déroule pas toujours sans encombre. Il arrive que de nouveaux déploiements introduisent des bogues ou interrompent des fonctionnalités existantes. C'est là que les restaurations et la reprise après sinistre interviennent.
Elles sont essentielles pour préserver la stabilité du système et la confiance des utilisateurs.
Comprendre les restaurations
Une restauration est le processus qui consiste à ramener un système ou une application à un état antérieur et stable après un déploiement problématique. C'est comparable à un bouton « annuler » pour vos modifications récentes.
Les restaurations sont généralement déclenchées rapidement afin de limiter l'impact d'une mise en production défectueuse et de rétablir le fonctionnement normal.
Approches courantes de restauration
Il existe plusieurs façons d'effectuer une restauration, selon votre stratégie de déploiement :
- Rétablir le code : Déployer la version précédente, dont le bon fonctionnement est établi, du code de votre application.
- Réorienter le trafic : Rediriger le trafic des utilisateurs de la nouvelle version défectueuse vers l'ancienne.
- Restaurer la base de données : Rétablir le schéma ou les données de la base de données, ce qui constitue souvent la partie la plus complexe.
Automatiser les restaurations avec Actions
GitHub Actions peut automatiser les procédures de restauration. Vous pouvez créer des flux de travail qui se déclenchent lors d'événements précis, comme un déclenchement manuel, afin de redéployer une version stable précédente ou de rétablir des modifications de l'infrastructure.
Cela garantit un processus de restauration rapide, cohérent et moins sujet aux erreurs, en réduisant les erreurs humaines dans les situations stressantes.
Flux de travail pour une restauration manuelle
Voici comment configurer un déclenchement manuel pour déployer une version précédente précise, par exemple une balise ou un condensat de validation. Ce flux de travail reçoit une valeur version de l'utilisateur.
name: Manual Rollback Deployment
on:
workflow_dispatch:
inputs:
version:
description: 'Tag or commit hash to deploy'
required: true
default: 'main'
jobs:
rollback:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
ref: ${{ github.event.inputs.version }}
- name: Deploy previous version
run: |
echo "Deploying version: ${{ github.event.inputs.version }}"
# Add your specific deployment commands here
# e.g., helm upgrade, kubectl apply, etc.
Au-delà des restaurations : reprise après sinistre
La reprise après sinistre (DR) est une stratégie plus large visant à récupérer vos systèmes et vos données après un événement catastrophique. Il peut s'agir d'une panne de centre de données, d'une catastrophe naturelle ou d'une cyberattaque majeure.
Contrairement à une restauration, qui corrige un déploiement défectueux, la reprise après sinistre vise à rétablir l'ensemble du service après une défaillance totale du système ou la perte de l'environnement principal.
Planifier la reprise après sinistre dans l'intégration et la livraison continues
Lors de la planification de la reprise après sinistre dans vos flux d'intégration et de livraison continues, tenez compte des éléments suivants :
- Sauvegardes : Sauvegarder régulièrement les données, les configurations et les artefacts.
- Redondance : Déployer dans plusieurs régions ou zones de disponibilité.
- Flux de récupération : Prévoir des flux de travail dédiés pour restaurer les services à partir des sauvegardes ou les déployer sur une nouvelle infrastructure.
- Tests : Tester périodiquement votre plan de reprise après sinistre pour vérifier qu'il fonctionne au moment voulu.
Stocker les artefacts de compilation pour la récupération
GitHub Actions peut stocker les artefacts de compilation, qui sont essentiels à la reprise après sinistre. Il peut s'agir de fichiers binaires compilés, d'images Docker ou de manifestes de déploiement. Vous pouvez les téléverser lors d'une compilation réussie.
Ces artefacts peuvent ensuite être téléchargés et déployés dans un nouvel environnement dans le cadre d'un flux de récupération.
name: Build and Archive Artifacts
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Build application
run: |
echo "Building app..."
mkdir -p build_output
echo "App version 1.0.0" > build_output/app.txt
- name: Upload build artifact
uses: actions/upload-artifact@v4
with:
name: application-build
path: build_output/
Vérification : restauration ou reprise après sinistre
Le déploiement d'une nouvelle fonctionnalité a provoqué un bogue critique, rendant votre application inaccessible. Quelle stratégie est principalement utilisée pour corriger rapidement ce problème précis et rétablir le service ?
Restaurations et reprise après sinistre : points essentiels
Dans cette leçon, nous avons étudié les concepts essentiels de la restauration et de la reprise après sinistre. Nous avons appris que les restaurations rétablissent rapidement les déploiements défectueux, tandis que la reprise après sinistre consiste à restaurer les systèmes après des défaillances majeures.
GitHub Actions peut jouer un rôle essentiel dans l'automatisation de ces deux processus, afin de garantir la résilience de vos applications et de limiter les interruptions pour vos utilisateurs.
Questions Fréquemment Posées
La leçon « Retours en arrière et reprise après sinistre » est-elle gratuite ?
Oui — le texte complet de « Retours en arrière et reprise après sinistre » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours CI/CD with GitHub Actions & DevOps Pipelines, passe à CoddyKit PRO. Le cours CI/CD with GitHub Actions & DevOps Pipelines comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Retours en arrière et reprise après sinistre » ?
Concevez et mettez en œuvre des procédures efficaces de retour en arrière et des plans de reprise après sinistre dans vos pipelines d’intégration et de livraison continues. Tu pratiques CI/CD with GitHub Actions & DevOps Pipelines avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer CI/CD with GitHub Actions & DevOps Pipelines ?
Aucune expérience préalable n'est requise. CI/CD with GitHub Actions & DevOps Pipelines sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.
Combien de temps prend la leçon « Retours en arrière et reprise après sinistre » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon CI/CD with GitHub Actions & DevOps Pipelines ?
Oui. Chaque leçon CI/CD with GitHub Actions & DevOps Pipelines inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Déploiements bleu-vert
- Mises en production progressives avec Actions
- Retours en arrière et reprise après sinistre
- Indicateurs de fonctionnalité et déploiements progressifs