Avant d'aller plus loin 🛑

Je vous montrerai comment déployer une application Next.js en format statique (SSG). Cette technique génère une application web en mode statique (HTML / CSS / JS) ultra rapide. Évidemment aucun calcul ou opération n'est nécessaire pour ce type d'application.

Si vous avez des services dans votre application qui nécessite des opérations à votre backend (BDD, ressources sécurisées). On parle alors de Server Side Rendering (SSR)

Définition

GitHub Actions

GitHub Actions est un outil de CI/CD directement inclus dans votre abonnement GitHub. À l'aide d'un simple fichier YML, nous allons être en mesure d'orchestrer tout le processus.

Si c'est disponible, pourquoi ne pas l'utiliser pour automatiser le déploiement de notre application Next.js sur l'environnement de production.

AWS

Amazon Web Services est l'un des grands fournisseurs d'infonuagique dans le monde. Nous allons utiliser quelques services (IAM, S3, CloudFront) pour les besoins de cette solutions.

• AWS IAM : afin de limité l'accès (ZeroTrust) à nos ressources par le CI/CD.
• AWS S3 : où nos fichiers seront stockés.
• AWS CloudFront : notre réseau de diffusion de contenu (CDN)

1. Création du fichier workflows YML

Vous devez créer un fichier .github/workflows/[actions].yml à la racine de votre projet afin de commencer à utiliser les GitHub Actions.

mkdir ./.github && mkdir ./.github/workflows && touch ./.github/workflows/deploy.yml

Avec cette commande, vous aurez un fichier prêt à être utilisé pour commencer à configurer votre workflow.

Vous pouvez aussi créer le fichier sur GitHub dans l'onglet Actions de votre projet.

2. Configuration de notre fichier

Dans votre éditeur de code préféré, vscode bien sûr 👨‍💻, vous pouvez commencer à configurer le CI/CD

2.1 Nom de l'action

Le nom permet de différencier les différentes actions qui peuvent d'exécuter dans le CI/CD

name: Deploy on s3 bucket

2.2 Les déclencheurs (on)

Les déclencheurs sont les règles lorsque l'action sera exécutée.

on:
    push:
        branches:
            - main

Dans ce cas-ci, le déclenchement se fait à chaque push sur la branche main

2.3. Les tâches (jobs) 💪

Les tâches sont les différentes étapes à effectuer pour construire l'application et la déployer dans ce cas-ci.

jobs: 
    build:
        runs-on: ubuntu-latest

        steps:
            - name: Checkout repository
              uses: actions/checkout@v4

            - name: Set up Node.js
              uses: actions/setup-node@v4
              with:
                node-version: 22

            - name: Install dependencies
              run: npm install

            - name: Build Next.js app
              run: npm run build

            - name: Upload to S3
              uses: jakejarvis/s3-sync-action@v0.5.1
              with:
                args: --delete
              env:
                AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
                AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
                AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
                AWS_REGION: "us-east-1"
                SOURCE_DIR: "out"

            - name: Invalidate CloudFront cache
              run: |
                  aws cloudfront create-invalidation --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} --paths "/*"
              env:
                AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
                AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
                AWS_REGION: "us-east-1"

Ce fichier peut paraître intimidant 😱 au départ mais si on le regarde tranquillement c'est assez clair.

On commence par une tâche que j'ai nommée build, celle-ci sera rouler dans un conteneur ubuntu-latest dans l'infrastructure de GitHub. Par la suite, toutes les étapes seront appelées de façon séquentielle.

• Checkout repository : checkout le code dans le conteneur
• Set up Node.js : installation de node.js dans le conteneur
• Install dependencies : installation des dépendances de notre projet
• Build Next.js app : build de notre application next.js
• Upload to S3 : téléverser les fichiers de votre build sur S3
• Invalidate CloudFront cache : vider la cache de notre CDN

3. Gestionnaire de secrets 🔒

Dans le fichier précédent, vous avez surement remarqué l'utilisation de variable comme
${{ secrets.AWS_ACCESS_KEY_ID }}.

C'est variable sont importantes car on ne veut pas exposer nos secrets dans notre codebase.

Ce qui est bien, c'est que GitHub Actions y a pensé :)
Dans GitHub, sous l'onglet Settings - Secrets and variables - Actions
Vous pouvez définir vos secrets sous forme de clé/valeur. De cette façon le tout reste sécuritaire et on aime ça. ❤️

Si vous utilisez vscode, une extension est disponible pour la gestion de vos secrets.
GitHub Actions

Conclusion

Nous avons vu comment il est facile avec simplement un fichier YML d'utiliser les GitHub Actions afin de déployer notre application sur un AWS.

J'espère vous avoir donné l'envie d'essayer GitHub Actions afin d'automatiser des tâches de CI/CD. Vous allez voir, vous n'allez plus vous en passez. 😍

Merci d'avoir suivi jusqu'à la fin. 🤪