Retool enables developers to quickly build internal tools and applications, but managing complex software development lifecycles (SDLC) across multiple environments can be challenging, especially for larger teams. Source Control, available for self-hosted Enterprise Retool deployments, allows syncing apps, resources and queries across multiple instances. This supports advanced multi-stage development workflows with separate development, staging, and production environments. This article dives deep into architecting multi-instance Retool deployments with Source Control to enable Enterprise-grade development lifecycles.
Setting Up Multi-Instance Retool Environments
The first step is deploying separate Retool instances for development, staging, and production environments. To make the Retool containers stateless and independently scalable, [externalize the Postgres database that stores Retool's application data. This allows scaling Retool instances based on the different usage patterns of developers vs end users.
For example, provision three Retool instances with shared backend storage:
- `retool-dev.company.com`: Development environment
- `retool-staging.company.com`: Staging/QA environment
- `retool-prod.company.com`: Production environment
Configuration du contrôle du code source pour le développement multi-instances
Next, set up a Git repository for each Retool instance. Protect foundational resources like data sources and environment configs in all instances. For the development instance, enable developers to work on feature branches.
Here's an example Source Control setup:
- `retool-dev`: Developers collaborate on feature branches
- `retool-staging`: Admins review and merge pull requests from dev
- `retool-prod`: Admins promote changes from staging to prod
Flux de développement avec Source Control
Avec un contrôle de source multi-instances configuré, les équipes de développement peuvent suivre des flux de travail structurés :
1. Les développeurs créent des applications et des requêtes sur des branches fonctionnalités dans l'instance de développement. Par exemple :
`git checkout -b "new-crm-integration"`
2. When ready, developers open pull requests to merge their feature branches into the staging instance. This allows others to review changes and conduct integration testing.
3. After validation, admins merge the staging branch into the prod instance via PR. This deploys the changes to end users in a controlled manner.
4. En cas de bogues ou de problèmes, les administrateurs peuvent rapidement ramener l'instance de production à un état stable antérieur en annulant les modifications.
Best Practices for Complex SDLC with Retool Source Control
Pour optimiser les flux de développement multi-instances avec Source Control :
- Établir une stratégie de ramification claire comme Git Flow avec des branches principales et des branches de développement
- Mettre en place des branches protégées pour la pré-prod/la production avec des examens de pull request (PR) obligatoires
- Mettre en œuvre des contrôles d'accès précis pour controler qui peut déployer en production
- Surveiller les événements Source Control pour les changements entre les instances
- Envisager d'automatiser les déploiements entre les instances en utilisant des pipelines CI/CD qui monitorent les fusions de PR
Architecting multi-instance Retool deployments with Source Control enables large development teams to follow structured, Enterprise-grade SDLC practices. By externalizing state, setting up staging environments, and configuring advanced Git workflows, organizations can build and ship internal tools in a scalable yet controlled manner.
However, multi-instance deployments do come with increased DevOps overhead and hosting costs to manage. Security and compliance is also crucial when moving application code across environments. But for many enterprises, the productivity benefits of Retool's low-code platform combined with the safety of Source Control unlocks a new paradigm for internal tool development at scale.
Que sont les instances multiples d'une application ?
Construire avec des applications low-code et deep-code ont leur similarités. Vous devez tester fréquemment les fonctionnalités que vous ajoutez. En les construisant, vous pouvez casser des interfaces. C'est pourquoi le développement de logiciels repose sur la trinité sacrée des instances : dev, pré-prod et prod. L'instance de production de l'application est là où se trouvent vos utilisateurs ; elle est en direct et fonctionne 24 heures sur 24, 7 jours sur 7. L'environnement de développement est utilisé pour casser des choses, ajouter des mèmes de chat et utiliser des textes lorem-ipsum. Une fois qu'une fonctionnalité est terminée dans l'environnement de développement, elle est soit déployée directement dans l'environnement de production pour les petits projets, soit, pour les projets plus importants, nous utilisons un troisième environnement : l'environnement de développement. L'environnement pré-prod contient généralement des données obsolètes et souvent anonymisées provenant de l'environnement prod, donc plus de chats ou de textes lorem ipsum. Ici, nous sommes presque en production et nous pouvons tester l'application en profondeur avec des données quasi réelles. Nous pouvons effectuer des tests de stress, des audits de sécurité et des tests de performance.
Pour être honnête, il y a souvent plus d'exemples. L'intégration est utilisée spécifiquement pour tester les connexions entre votre application et le reste de vos outils et logiciels. Dans certains cas, nous pouvons même avoir une instance par fonctionnalité, afin que chacune puisse être testée indépendamment en premier lieu pour éviter de longues heures de débogage de multiples fonctionnalités fusionnées qui ont un impact les unes sur les autres.
