Pour les applications de production, vous devez mettre en place un flux de développement clair, surtout si plusieurs personnes travaillent sur votre application. Un workflow de développement implique généralement la configuration et la gestion de plusieurs environnements.
Firebase propose différents niveaux de prise en charge pour les flux de travail des développeurs et les environnements constitutifs. Une fois que vous êtes familiarisé avec les termes et hypothèses du flux de travail des développeurs sur cette page, consultez nos bonnes pratiques générales et nos directives générales de sécurité pour la configuration d'un projet Firebase et de vos applications.
À propos des environnements
Dans le développement de logiciels, un environnement désigne l'ensemble du matériel et des logiciels nécessaires pour exécuter une instance d'une application ou d'un système d'applications.
Une série d'environnements offre une isolation pour le développement et le test de logiciels sans impact sur les utilisateurs. Comme le montre le diagramme ci-dessous, les environnements de haut niveau sont considérés comme des environnements de pré-production ou de production , et vous pouvez disposer d'autant d'environnements de pré-production que nécessaire. Le diagramme décrit également les pratiques et fonctionnalités courantes associées à chaque type d'environnement .
Le processus de progression d'une fonctionnalité ou d'une version dans ces environnements jusqu'à la production est appelé pipeline de déploiement .
Types d'environnements
Un environnement est composé de l'infrastructure sous-jacente dont vous avez besoin pour exécuter et prendre en charge votre application, son code et ses données. Développez chacun des termes suivants pour passer en revue les descriptions de certains environnements courants, y compris des conseils sur les types de données utilisés dans chaque type d'environnement.
Chaque développeur a besoin d'un environnement de développement : un endroit sûr et isolé pour tester les modifications au fur et à mesure de leur création. Idéalement, chaque développeur de votre équipe a accès à son propre environnement de développement. De plus, si l'environnement de développement est une instance locale, un développeur peut itérer beaucoup plus rapidement.
Les données d'un environnement de développement sont ensemencées avec des données qui ressemblent généralement aux données de production, mais ne doivent jamais contenir de données d'utilisateurs réels. Il peut également contenir des données qui ont provoqué des bugs dans le passé, comme des chaînes très longues.
Si vous disposez de tests automatisés, vous avez besoin d'un environnement dans lequel exécuter ces tests et vous devez réinitialiser les données à chaque fois que vous démarrez l'environnement de test.
Si vous avez des ingénieurs QA, ils peuvent avoir besoin d'un environnement qu'ils utilisent tous, ou ils peuvent avoir besoin d'environnements individuels pour tester une nouvelle version candidate.
Les données dans les environnements de test et d'assurance qualité sont ensemencées avec des données de qualité qui sont généralement représentatives des données de production, ainsi que des données qui représentent des cas extrêmes et des exemples de données qui ont provoqué des bogues dans le passé.
Pour des tests réalistes du fonctionnement d’une version en production, vous avez besoin d’un environnement de test qui imite le plus fidèlement possible l’infrastructure de production. Il est courant d'avoir plusieurs instances intermédiaires si vous devez tester des intégrations spécifiques de manière isolée.
Voici les différences courantes entre la mise en scène et la production :
Il se peut que la mise en scène manque certaines fonctionnalités ou intégrations qui pourraient provoquer des effets secondaires. Par exemple, la préparation peut être configurée pour ne pas envoyer d'e-mails.
La mise en scène peut avoir des données anonymisées ; les données peuvent être fausses, mais elles doivent être réalistes. Étant donné que la préparation est un endroit pour déboguer les problèmes en toute sécurité, vous pouvez accorder à l’équipe un accès plus large aux données de préparation qu’aux données de production. Ainsi, pour protéger la confidentialité des utilisateurs, vous ne devez pas utiliser les données utilisateur réelles lors de la préparation.
Pour chaque application que vous gérez, vous avez besoin d’un seul environnement de production. Il s'agit de l'instance avec laquelle vos utilisateurs interagissent.
Contrairement aux autres environnements dans lesquels vous pouvez modifier, supprimer et/ou recréer des données, les données de votre environnement de production sont très importantes ; la perte ou la modification de vos données de production affectera directement vos utilisateurs.
Dans la console Firebase, nous vous recommandons de baliser le projet Firebase associé à votre environnement de production en tant que type d'environnement « production » . Cette balise peut vous rappeler, à vous et à vos coéquipiers, que toute modification pourrait affecter vos applications de production associées et leurs données.
Prochaines étapes
Consultez nos bonnes pratiques générales pour la configuration de projets Firebase. Ce guide répond aux questions sur la hiérarchie des projets Firebase, sur la façon d'enregistrer les variantes de votre application et sur la multilocation.
Passez en revue les directives générales de sécurité pour différents environnements. Vous voulez vous assurer que chaque environnement et ses données sont sécurisés.
Consultez la liste de contrôle de lancement de Firebase .