Ok I want at least 3 versions of the database: LOCAL-DEV, TEST, and PRODUCTION, corresponding to 3 environments. Pretty standard.
My data is pretty simple, each environment has the same half-dozen tables, would each fit in 1 DB.
How do I set this up? Is this three different Clusters? Projects? Databases? Collections? What?
(I’ve been here so many times… I’m starting a new platform or service. One of the first thing you do is setup your dev, text, and prod environments. But I’m not familiar enough with the completely new nomenclature to know what corresponds to what… and intro documentation never covers this stuff.)
There’s no one way to do this but our generally recommendation is to use different Atlas Projects within your Organization for these different environments. In each project you’d then have a different cluster (you might use a much smaller cluster for dev, and maybe you frequently pause your test cluster, etc).
Projects offer security/authorization level isolation (e.g. which team members have access) as well as isolation of configurations like Alerts which make them ideal for separating Prod from non-prod environments. A common pattern is to restore a backup from prod to a non-prod environment for test purposes. https://docs.atlas.mongodb.com/best-practices/#the-project-level may be of use.
Taking a step back, I love the question because it’s good for thought for us to figure out how to make it easier for users to set up best practices.
I went ahead with that: organized environments at the project level: project-dev, project-test, project-production.
I’ve started using Realm (to provide id and user access, plus expose part of the data to an open api) … now I’m super confused again. Realm Application also have environments?
Are Realm environments supposed to all use the same database?
Are we expected to migrate entire Realm applications from project to project throughout a development cycle?
What’s the correct to organize MongoDB and Realm intro environments?
Why do I always have trouble finding documentation on this online?
Hi Tim – We actually cover this in a recent blog and .Live talk and are working on incorporating this guidance into our documentation as well. Hope this helps!
My understanding of this isssue is that App Services has environments and each environment has values and secrets and can point to its own Atlas cluster in linked data sources.
So for instance an application might have something like this.
Development(environment in App Services)
Development secrets and values
Will use a specific development database cluster in linked sources.
Users and data are specific to the development environment and stored in the development cluster.
Staging(environment in App Services)
Staging secrets and values
Will use a specific staging database cluster in linked sources.
Users and data are specific to the staging environment and stored in the staging cluster
Production(environment in App Services)
Production secrets and values
Will use a specific production database cluster in linked sources.
Users and data are specific to the production environment and stored in the production cluster.
Then changes to the app configuration can be moved to each environment during the development process. For instance following the guide above. Can someone confirm this?