johanleroy/ENI-JSAdvanced_15
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
ENI-JSAdvanced_15/README.md
Johan 95d0b33581 First commit
2025-12-19 10:05:30 +01:00

7.6 KiB
Raw Permalink Blame History

Frontend Angular : démonstration CI/CD, DevSecOps et déploiement Cloud AWS

Objectif : Configurer un dépôt Git et GitHub pour automatiser le déploiement d'une application Angular (un site web statique) vers AWS S3 et CloudFront.

Contexte

Vous avez à votre disposition un projet Angular complet ainsi qu'un fichier de workflow GitHub Actions (.github/workflows/ci-cd.yml).

Votre infrastructure AWS est déjà prête (un bucket S3 pour stocker les fichiers et une distribution CloudFront pour les diffuser rapidement).

Votre mission est de vous concentrer uniquement sur la partie Git et GitHub Actions pour "connecter" votre code à l'infrastructure AWS et automatiser le déploiement.

Étapes à réaliser

1. Prise de connaissance et configuration du pipeline

Le fichier .github/workflows/ci-cd.yml est le "cerveau" de notre automatisation.

  1. Ouvrez et lisez ce fichier dans PyCharm. Essayez de comprendre son fonctionnement :

  • on: push: branches: [ master ] : le pipeline se déclenche à chaque push sur la branche master.

  • jobs: : il y a deux "jobs" (travaux) qui s'enchaînent.

    • Job test (La CI) : il installe Node.js, teste le code (npm test), "lint" le code (npm run lint), et surtout, il "build" l'application (npm run build). L'étape finale, upload-artifact, met de côté le résultat (les fichiers statiques HTML/CSS/JS).
    • Job deploy-aws-cloudfront (La CD) : il ne se lance que si la CI a réussi. Il télécharge les fichiers, se connecte à AWS, les envoie sur S3 (stockage), puis force CloudFront (le cache) à se mettre à jour.
    graph TD
    subgraph "Workflow GitHub Actions"
        A[Push sur 'master'] --> B(Lancement du job 'test');
        B -- "npm test, npm run build" --> C{CI Réussie ?};
        C -- Oui --> D(Lancement du job 'deploy-aws-cloudfront');
        C -- Non --> F(Échec);
        D -- "upload S3, invalidation CloudFront" --> E(Site web déployé);
    end
  1. Modifiez le fichier : ce pipeline a besoin d'une information cruciale.
  • Trouvez la ligne : CLOUDFRONT_DISTRIBUTION_ID: "VOTRE-ID-CLOUDFRONT"
  • Remplacez VOTRE-ID-CLOUDFRONT par l'identifiant qui vous a été fourni dans le canal TEAMS de ce cours.
  • Enregistrez le fichier.

2. Initialiser Git dans PyCharm

Votre projet n'est pas encore suivi par Git.

  1. Allez dans le menu VCS (Version Control System).
  2. Cliquez sur Enable Version Control Integration....
  3. Choisissez Git dans la liste et validez. (Vous verrez vos fichiers changer de couleur).

3. Créer le dépôt distant (GitHub)

  1. Allez sur GitHub.com et connectez-vous.
  2. Créez un Nouveau Dépôt (New Repository).
  3. Nommez-le (ex: hello-world-angular).
  4. Sélectionnez Private (Privé).
  5. IMPORTANT : Ne cochez AUCUNE case (ni README, ni .gitignore). Laissez-le vide.
  6. Cliquez sur Create repository.

4. Configurer les Secrets AWS dans GitHub

Le pipeline doit pouvoir se connecter à AWS. Pour cela, nous utilisons des secrets.

  1. Sur la page de votre nouveau dépôt GitHub, allez dans l'onglet Settings (Paramètres).
  2. Dans le menu de gauche, naviguez vers Secrets and variables > Actions.
  3. Cliquez sur New repository secret.
  4. Créez le premier secret (le nom doit être exact) :
  • Nom : AWS_ACCESS_KEY_ID
  • Valeur : (Insérez la valeur fournie dans le canal TEAMS de ce cours)
  1. Créez le second secret :
  • Nom : AWS_SECRET_ACCESS_KEY
  • Valeur : (Insérez la valeur fournie dans le canal TEAMS de ce cours)

5. Lier PyCharm et GitHub

Votre code est en local, le dépôt est sur GitHub. Il faut maintenant les lier.

  1. Dans PyCharm, allez dans Git > Manage Remotes....
  2. Cliquez sur le +.
  3. Pour l'URL, collez l'URL fournie par GitHub (celle en https. ex: https://github.com/votre-nom/hello-world-angular.git).
  4. Laissez le nom origin. Cliquez sur OK.

6. Le premier commit & push (Déclenchement)

Tout est prêt. Envoyons le code !

  1. Ouvrez la fenêtre Commit (souvent à gauche ou via Ctrl+K / Cmd+K).
  2. Cochez tous vos fichiers pour les "Stager" (les inclure dans le commit).
  3. Écrivez un message de commit (ex: Initial commit).
  4. Cliquez sur la flèche à côté de Commit et choisissez Commit and Push....
  5. Confirmez le push vers la branche origin/master.

7. Observer le Pipeline

  1. Retournez sur votre dépôt GitHub.
  2. Cliquez sur l'onglet Actions.
  3. Vous devriez voir votre pipeline en cours d'exécution (une icône jaune).
  4. Cliquez dessus pour voir les étapes en direct. Attendez que le job test finisse, puis que le job deploy-aws-cloudfront se lance et se termine.
  5. Une fois terminé, votre site est en ligne !

8. Provoquer un nouveau déclenchement

Faisons un changement pour prouver que l'automatisation fonctionne.

  1. Retournez dans PyCharm.
  2. Ouvrez le fichier src/app/app.component.html.
  3. Ajouter un espace en fin de fichier (juste pour modifier quelque chose).
  4. Ouvrez la fenêtre Commit.
  5. Écrivez un message (ex: Mise à jour du titre).
  6. Faites Commit and Push....
  7. Retournez sur l'onglet Actions de GitHub : un nouveau pipeline s'est automatiquement lancé pour déployer votre modification.

Note importante : comment cela se passe en entreprise ?

Ce que nous avons fait est une simplification pour l'exercice.

Trunk Based Development

Avec la stratégie Trunk Based Development, on s'autorise à travailler directement sur la branche master (ou main), mais on s'autorise tout de même à créer des branches de fonctionnalité avec une durée de vie très courte (quelques heures). Une telle stratégie est recommandée pour exécuter la CI/CD plus souvent.

graph TD
    M1["master (c1)"] --> M2["master (c2)"]
    M2 --> F1["feature/A (fA1)"]
    F1 --> M3["master (m1 - merge)"]
    M3 --> F2["feature/B (fB1)"]
    F2 --> M4["master (m2 - merge)"]
    M4 --> M5["master (c3)"]

Git Flow

En entreprise, vous verrez également la stratégie Git Flow, qui est un peu plus formelle :

  1. Branche master (ou main) : contient le code en production. Personne n'y touche directement.
  2. Branche develop : contient la version en cours de développement.
  3. Branches de fonctionnalité (ou bug) : pour chaque nouvelle tâche ou bug (ex: feature/add-login), vous créez une branche à partir de develop, avec une durée de vie plus longue (quelques jours).

Le pipeline de CI (Tests) : Le pipeline de test (comme celui de notre job test) se déclencherait automatiquement lorsque vous essayez de "merger" (fusionner) votre branche de fonctionnalité dans develop (via une Pull Request).

Le pipeline de CD (Déploiement) : Le déploiement en production (notre job deploy-...) ne se déclencherait PAS sur un simple commit, mais seulement lorsque le chef de projet décide de créer une nouvelle "version" (un tag Git, ex: v1.0.1).

graph TD
    %% Définir les lignes principales
    subgraph Ligne master
        M0("init") --> M1("v1.0.0") --> M2("v1.0.1")
    end

    subgraph Ligne develop
        D1("d1") --> D2("d2 (merge login)") --> D3("d3") --> D4("d4 (merge release)") --> D5("d5 (merge hotfix)")
    end

    %% Créer les liens entre les lignes
    M0 --> D1;
    
    %% Branche de fonctionnalité
    D1 --> F1("feature/login")
    F1 --> D2
    
    %% Branche de release
    D3 --> R1("release/v1.0")
    R1 --> M1
    R1 --> D4

    %% Branche de hotfix
    M1 --> H1("hotfix/auth-bug")
    H1 --> M2
    H1 --> D5
Reference in New Issue View Git Blame Copy Permalink