Retool permet aux développeurs de créer rapidement des outils et des applications internes, mais la gestion de cycles de développement logiciel (SDLC) complexes dans plusieurs environnements peut s'avérer difficile, en particulier pour les grandes équipes. Source Control, disponible pour les déploiements Enterprise Retool auto-hébergés, permet de synchroniser les applications, les ressources et les requêtes entre plusieurs instances. Cela permet de prendre en charge des flux de développement avancés en plusieurs étapes avec des environnements de développement, de mise à l'essai et de production distincts. Cet article traite en profondeur de l'architecture des déploiements multi-instances à l'aide de Source Control afin de permettre aux utilisateurs d'accéder aux applications et aux requêtes. Retool avec Source Control pour permettre des cycles de développement de niveau entreprise.
Configuration des environnements multi-instances Retool
La première étape consiste à déployer des instancesRetool distinctes pour les environnements de développement, d'essai et de production. Pour que les conteneurs Retool conteneurs sans état et évolutifs de manière indépendante, [externaliser la base de données Postgres qui stocke les données de l'application Retool'. Cela permet de faire évoluer les instances de Retool en fonction des différents modèles d'utilisation des développeurs par rapport aux utilisateurs finaux.
Par exemple, provisionnez trois instances Retool avec un stockage backend partagé :
- `retool-dev.company.com` : Environnement de développement
- `retool-staging.company.com`: Environnement de staging/QA
- `retool-prod.company.com`: Environnement de production
Configuration du contrôle du code source pour le développement multi-instances
Ensuite, configurez un dépôt Git pour chaque instance Retool . Protégez les ressources fondamentales telles que les sources de données et les configurations d'environnement dans toutes les instances. Pour l'instance de développement, permettez aux développeurs de travailler sur les branches de fonctionnalités.
Voici un exemple de configuration de Source Control :
- `retool-dev` : Les développeurs collaborent sur les branches de fonctionnalités
- `retool-staging` : Les administrateurs révisent et fusionnent les demandes d'extraction provenant de dev
- `retool-prod` : Les administrateurs promeuvent les changements de staging vers 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. Lorsqu'ils sont prêts, les développeurs ouvrent des demandes de téléchargement pour fusionner leurs branches de fonctionnalités dans le site instance de préproduction. Cela permet à d'autres personnes d'examiner les modifications et d'effectuer des tests d'intégration.
3. Après validation, les administrateurs fusionnent le site branche préproduction dans l'instance prod via PR. Cela permet de déployer les changements auprès des utilisateurs finaux de manière contrôlée.
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.
Meilleures pratiques pour un SDLC complexe avec 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
L'architecture des déploiements multi-instances de Retool avec Source Control permet aux grandes équipes de développement de suivre des pratiques structurées de SDLC de niveau entreprise. En externalisant l'état, en mettant en place des environnements de mise en scène et en configurant des flux de travail Git avancés, les organisations peuvent construire et livrer des outils internes de manière évolutive et contrôlée.
Cependant, les déploiements multi-instances s'accompagnent d'une augmentation de la charge DevOps et des coûts d'hébergement à gérer. La sécurité et la conformité sont également cruciales lorsque l'on déplace le code d'une application d'un environnement à l'autre. Mais pour de nombreuses entreprises, les avantages en termes de productivité de la plateformeRetool's low-code combinés à la sécurité de Source Control ouvrent la voie à un nouveau paradigme pour le développement d'outils internes à grande échelle.
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.
