177 lines
7.6 KiB
Markdown
177 lines
7.6 KiB
Markdown
# 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
|
|
```
|