`dev, staging, production`. We run into issues where our apps have to ignore certain JSON structs because we lack the abiliy to roll out backend features.
We are also forced to test dangerous features such as Push messaging with production settings because of this lack of separation.
Also on the rendering side we often need to work with backend when designing formats for custom embeds for new features that should not be exposed to production or staging.
Guest
Cool, thanks. I certainly agree about giving pre-production apps write access to production data. I don't know what the architecture looks like, so I guess I was picturing this more in the case of read-only access.
Hi Chad - the good news about our new platform is that it's really easy to provision new servers (or, indeed whole clusters of servers) for an afternoon or for a year and deploy a version of code to them for whatever ones intended purpose might be. Since we'll have an arbitrary number of application environments we can deploy in to, we'll also be able to create any combination of (code environment, database environment) we want.
That said, It's usually not a great practice to connect pre-production apps that can Write/Delete to production data sources, but we can certainly connect dev apps to stage sources or "dark prod" apps to dev data sources, etc.
It sounds like this is already much better than what we're working with now, but here is a clarifying question:
Say, for example, that an updated version of the API will now use a different data structure for Instagram embeds, and we want to test this with the full, live, production content. Is this possible, or can this only be tested against test or stage content?
This may not map the same way as it currently does in the rainbow tool, but what we're currently faced with is that we only 'test' content is available in the test environment, which must be manually populated with stories, and there usually isn't a good way to test what will happen when this change goes into effect across all content.
Each ARC microservice is a Nile application, which "bakes in" the notion of a progression of environments (test -> stage -> prod, for example). Each environment can leverage isolated data sources like a "test db" or a "stage db", etc. So I'd consider this feature request to already exist.