Depuis Hatchbox.io
Hatchbox et Railyard misent sur la même chose, vos serveurs, le déploiement par push. Voici à quoi ressemble la migration, et où Railyard fait plus pour l'après-lancement.
Pourquoi les équipes regardent au-delà de Hatchbox
Hatchbox a réussi l’essentiel : déployer sur des serveurs qui vous appartiennent, sans majoration sur le calcul. Si ça fonctionne pour vous, rien ne presse de migrer.
Là où les gens commencent à chercher : Hatchbox est une couche fine au-dessus d’une configuration assez manuelle, proche de la configuration Nginx et des entrailles du serveur, et la surface gérée s’arrête tôt. Il n’y a pas de version vérifiée puis échangée avec bascule contrôlée par vérification de santé, pas d’environnement d’aperçu par pull request, pas de rôles, de 2FA ou de journal d’audit, et les sauvegardes sont à organiser vous-même. C’est aussi un produit porté par une seule personne, avec une feuille de route discrète.
Railyard fait le même pari « vos serveurs », avec plus de ce qu’il faut pour l’exploiter en production, déjà pris en charge pour vous.
Ce qui vous suit
- Votre dépôt et votre Dockerfile, ou le chemin Nixpacks / buildpacks de Railyard si vous déployez sans Dockerfile aujourd’hui.
- Vos types de processus Procfile.
- Vos variables d’environnement.
- Votre base de données. Les Postgres / MySQL / Redis gérés de Hatchbox correspondent aux modules complémentaires de Railyard, avec chaînes de connexion injectées.
- Vos serveurs, si vous voulez les garder : rattachez une machine existante en SSH plutôt que d’en provisionner une nouvelle.
La migration
- Rattachez un serveur. Pointez Railyard vers un de vos serveurs Hatchbox actuels, ou vers un nouveau serveur de votre compte cloud.
- Ajoutez votre dépôt et confirmez la méthode de build. Un Dockerfile se déploie tel quel.
- Apportez votre environnement et ajoutez les bases de données dont vous avez besoin.
- Déployez vers une URL temporaire et vérifiez-la de bout en bout, y compris une tâche de release si vous exécutez des migrations.
- Déplacez vos données avec une sauvegarde standard, restaurée dans le module complémentaire géré.
- Repointez le DNS. L’ancienne application continue de répondre jusqu’au changement de l’enregistrement, rien ne s’arrête. Ensuite, fermez l’application Hatchbox.
Ce qui change
Vous obtenez une bascule vérifiée et sans interruption à chaque déploiement, un retour arrière en un clic avec le commit et l’auteur enregistrés, un déploiement d’aperçu pour chaque PR, de vrais rôles et un journal d’audit, et des sauvegardes dont la restauration est testée, en plus de la propriété que vous aviez déjà.