If following Cobalt guidelines, which environments can talk to each other and in which directions?

Ross Bradbury

**Specifically, can QED usually reach a PROD environment or can PROD reach QED through the firewall?** *Why?* I and some others are trying to figure out which of these types of processes are more appropriate for a particular problem to be solved. - **Content Load and Publish**: An internal-PROD-deployed application and external-PROD-deployed services are used to prepare changes to data, the changes are tested by retrieving "draft" state data, and then that data is published for consumption by public-facing PROD services. - **Environment Promotion**: Change data in DEMO database with a DEMO-deployed application, test it and promote to QED database, test and then promote to PROD database for consumption by public-facing PROD services. In both scenarios, Thomson Reuters employees would use an application to prepare the data, test that data and then click a button to promote it to production.

Andrew Gerber

Ross, it really is going to depend on your specific use case. There are a myriad of things going on in Cobalt that could impact your solution. That said, generally things shouldn't cross environments in Cobalt, especially data. Given that, your first bullet point would seem to be the more appropriate approach. I can't think of a situation where we would "promote" something from a DEMO to a QED database.

Timothy Sullivan

Are you wondering if the module in one environment can talk to its own database in another environment, or if a module can talk to another module in a different environment? I think part of the lack of responses comes from the fact that Cobalt developers generally do not create data, either the users do our it is served by Novus and other outside sources. For example Cobalt uses Novus PROD data in every environment, we try to contain content that isn't ready uses app logic, but it does occasionally bleed through.