Migre ton application vers Upsun Cloud sans avoir à la réécrire

Les migrations d'applications s'enlisent pour une raison prévisible : la partie la plus exigeante est rarement le code de l'application lui-même. C'est l'infrastructure qui l'entoure : la logique de déploiement, le pipeline et la configuration de l'environnement qui doivent être reconstruits. 

C’est tout ce travail annexe qui transforme une migration en un projet de plusieurs mois, et c’est pourquoi les équipes restent sur une infrastructure qui ne leur convient plus.

Upsun Cloud réduit la migration à une tâche bien plus simple. Tu décris tes environnements d'exécution, tes services et tes routes une seule fois, dans un fichier de configuration qui se trouve dans ton dépôt, tu transfères tes données, puis tu testes le résultat sur une branche. Le code de l'application reste tel quel.

Ce qu’implique la migration vers Upsun Cloud

Point clé : la migration consiste à décrire ta stack existante dans un seul fichier de configuration, pas à la reconstruire. Ton code d’application et tes outils d’intégration continue restent inchangés.

La migration consiste à décrire ta configuration existante plutôt qu’à la reconstruire ; la grande majorité de ce que tu as déjà reste en place :

• Ton code d’application. Si tu utilises Next.js, Django, Symfony ou un autre framework pris en charge, tu n’as pas besoin de réécrire la logique métier pour l’adapter à un nouveau modèle.
• Ton outil d’intégration continue (CI). Si tu en as déjà un qui te convient, tu n’as pas besoin de le remplacer.

Tout ce que tu ajoutes, c’est un seul fichier, `.upsun/config.yaml`, que tu valides dans ton dépôt comme n’importe quel autre code. Il n’est pas saisi dans un tableau de bord séparé ni dans une console propre à un fournisseur. Ce fichier déclare trois éléments :

• L’environnement d’exécution de ton application, le langage et la version sur lesquels elle fonctionne.
• Les services dont ton application dépend, comme une base de données, un cache ou un index de recherche. Tu n’as pas besoin d’un fournisseur tiers, mais tu peux tout de même en utiliser un si tu le souhaites.
• La manière dont ces éléments s’articulent entre eux, pour que la plateforme sache comment les connecter.

La rédaction de ce fichier s’apparente davantage à de la documentation qu’à de l’ingénierie d’infrastructure. Tu décris ce dont ton application a besoin, tu ne configures pas manuellement des serveurs.

Migration étape par étape vers Upsun Cloud

Point clé : chaque étape s’exécute sur une branche isolée, ce qui te permet de valider l’ensemble de la migration sur des données réelles avant que l’environnement de production ne soit affecté.

Une fois ton projet et ton dépôt Git configurés sur Upsun Cloud, la migration se déroule par petites étapes, chacune pouvant être exécutée sans nécessiter de fenêtre de maintenance. L’environnement de production n’est pas affecté tant que tu n’as pas choisi de fusionner les modifications.

1. Ajoute le fichier de configuration à côté de ton application existante dans ton dépôt. Cette étape ne déploie rien en soi. Tu décris simplement ta stack, sans t’engager à quoi que ce soit pour l’instant.

2. Envoie une branche. L’envoi crée un environnement isolé lié à cette branche. L’environnement de production n’est pas affecté. Tu testes dans un environnement réel et opérationnel, et non dans une approximation locale de celui-ci.

3. Ajoute tes variables d’environnement. Utilise la console ou l’interface en ligne de commande (CLI) pour ajouter toutes les variables nécessaires au fonctionnement de ton application.

4. Synchronise les données dans l’environnement de la branche. Exécute la commande `upsun environment:synchronize code data` pour récupérer une copie des données de l’environnement parent dans la branche. Lorsque la branche est créée à partir de l’environnement de production, ça signifie que tu testes avec de vraies données de production, et non avec des données de test qui ne reflètent pas forcément les conditions réelles.

5. Itère sur la configuration, pas sur le code. Si quelque chose est mal configuré, la correction s’effectue dans le fichier YAML de cette branche. La logique de ton application ne fait pas partie de la boucle de débogage.

6. Ne fusionne que lorsque la branche a fait ses preuves. La mise en production n’intervient qu’en dernier, une fois que l’environnement a déjà démontré son bon fonctionnement. À aucun moment de ce processus tu ne testes en production pour la première fois.

Chaque étape est réversible. Si l’étape 4 fait apparaître un problème, tu le corriges et tu recommences l’étape. Rien en aval ne dépend de la réussite d’une étape précédente dès le premier essai.

Une configuration qui t’accompagne

Point clé : les outils et habitudes sur lesquels tu t’appuies déjà — git, la CLI, ton langage et tes services — sont repris dans Upsun au lieu d’être remplacés.

• Ton processus Git. Fais des push et crée des branches comme tu le fais déjà.
• Tes habitudes avec la CLI. Upsun Cloud est scriptable via la CLI et l’API, et ne se limite pas à une console web.
• Ton langage et ton environnement d’exécution. Next.js, Django, Symfony et Laravel en sont des exemples courants, et la plateforme en prend en charge bien d’autres, notamment Go, Ruby et des plateformes CMS comme WordPress et Drupal.
• Tes versions de services existantes, lorsqu’elles sont prises en charge, notamment PostgreSQL, MySQL et Redis.

Ce qui change

Point clé : les changements concernent la manière dont l’infrastructure est définie et sécurisée ; elle est désormais déclarée dans la configuration plutôt que configurée manuellement.

Ton processus et ta stack restent les mêmes, mais certaines choses fonctionnent différemment une fois que tu es sur Upsun Cloud. Voici ce qui change vraiment.

• Les services sont déclarés : tu spécifies toujours les services dont tu as besoin, mais tu le fais en les déclarant dans le fichier de configuration au lieu de provisionner manuellement des instances de base de données et de configurer l’accès réseau. Une fois déclarés, la plateforme les provisionne et les sécurise.
• Les variables sont limitées à un projet ou à un seul environnement. Les identifiants sensibles sont définis comme des variables au niveau du projet ou de l’environnement via l’interface en ligne de commande (CLI) ou la console, plutôt que d’être intégrés au code ou copiés manuellement d’un environnement à l’autre.

Essaie-le sur une branche

La migration semble risquée car la validation se fait généralement au mauvais endroit. Avec une migration en une seule fois, le premier vrai test pour savoir si ça a marché a lieu après le basculement, quand l’application est déjà en ligne et sert les utilisateurs. Cette approche avance le test.

Tu ajoutes un fichier de configuration à ton dépôt, tu pousses une branche, puis tu regardes ton application tourner sur Upsun Cloud avec une copie de tes vraies données de production. Rien ne change sur ton site en production pendant que tu fais ça. Si la branche fonctionne, tu en as la preuve et tu continues. Si ce n’est pas le cas, tu corriges la configuration et tu pousses à nouveau, ou tu abandonnes après avoir passé un après-midi plutôt qu’un trimestre.

C’est là toute la différence qu’apporte une approche incrémentale. Tu ne t’engages pas dans une migration avant de savoir si elle fonctionne. Tu testes la migration, tu observes le résultat et tu prends ta décision en te basant sur des preuves plutôt que sur des espoirs. Le coût de cette vérification se résume à une seule branche.

Foire aux questions (FAQ)

Dois-je réécrire le code de mon application pour effectuer la migration ? 
Non. La migration vers Upsun Cloud ne nécessite aucune modification de la logique de ton application. Le seul nouvel élément est un fichier de configuration qui définit ton environnement d’exécution et tes services. Ton code est transféré tel quel.

Est-ce que tester une migration va affecter mon site de production en ligne ? 
Non. Les tests de migration se font sur une branche, dans son propre environnement isolé. L'environnement de production reste intact jusqu’à ce que tu décides de fusionner, et à ce moment-là, l’environnement a déjà été testé sur une copie des données de production.

Comment les variables d’environnement et les secrets sont-ils gérés lors de la migration vers Upsun Cloud ? Les identifiants sensibles
sont définis comme des variables au niveau du projet ou de l’environnement via l’interface CLI ou la console, plutôt que d’être copiés manuellement d’un environnement à l’autre. Il n’est pas nécessaire de migrer tel quel un fichier .env partagé. Chaque variable est définie au niveau où elle doit s’appliquer, ce qui garantit une portée correcte dès le départ.

Qu’advient-il de mon pipeline CI/CD existant ? Le processus de compilation et de déploiement d’Upsun
Cloud est déclenché par un « git push » et gère automatiquement le provisionnement. Un outil CI distinct pour le linting, les tests ou les vérifications de révision du code peut continuer à fonctionner en parallèle ; tu n’as donc pas besoin de supprimer ton pipeline existant pour tester une migration.

Quels frameworks et langages Upsun prend-il en charge ? 
Upsun Cloud prend en charge un large éventail de langages et de frameworks, notamment Next.js, Django, Symfony, Laravel, Go et Ruby, ainsi que des plateformes CMS comme WordPress et Drupal.