# 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.
   
    ```mermaid
    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
    ```
    
2.  **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](https://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)
5.  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.

```mermaid
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`).

```mermaid
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
```