Testing/Staging on dedicated test-Product or within test-environment of Product which also holds the prod-environment?

[mail-2]

Hello!

Is it recommended to test/stage on dedicated test-Product or within test-environment of Product which also holds the prod-environment?

The second option would require to restrict access to the test-environment so that registered apps (which should only access prod-env) cannot access it. That can be done by restricting environments in the Product settings. But what if some proxy policies depend on settings of the product? How would I replicate that then?

It seems to me that a specific test-Product is the cleaner and more reproducible approach. Potentially even in a dedicated test-org?

Generelly speaking, what is the recommended CI/CD-flow?

Regards

Raffael

[dchiesa1]

The approach you take depends on your general philosophy of testing. Here are a few criteria through which you can consider the choice.

	single Product, test environment	dedicated test Product in test environment
"noisy neighbor" performance impacts	Because environments in Apigee typically use the same resources in the cloud, running tests, especially volume throughput tests, can impact production performance.	The same is true with a dedicated test product. Apigee will use the same pool of cloud resources to service the requests.
Analytics	If you view analytics charts in Apigee, using a single product for production and testing will muddle the data. You will not be able to distinguish between data from testing efforts and data from actual production traffic. You can still analyze by environment; but the product slices will be muddled.	If you analyze API analytics data by product, using a separate product will By slicing the data for a particular product, you will be able to distinguish test from prod traffic.
metadata	API Products are entities on which to hang metadata - attributes. This could be quota limits, or it could also be public or private keys, target endpoints, and so on. If you use a single product for prod and test, then you cannot use distinct metadata for those cases.	Different products can carry different metadata. That means a test run could use a distinct target endpoint, a distinct private key or certificate, and so on.

My preference is to use a distinct Product for testing. But your preference may be different. Some people don't value the separation, take a YAGNI approach. And that's a reasonable view also.

[mail-2]

Thanks for the comparison. Seems to me that a dedicated Product for testing is the obvious choice if a clean CI/CD flow is desired. Same Product would be just a bit more comfortable.

Especially this point is important: "You will not be able to distinguish between data from testing efforts and data from actual production traffic."

Testing will obviously produce errors which have to be filtered out for monitoring the live system. If that is not possible the this point alone requires a separate Product.

I think this subject should be covered in the documentation. Possible providing a reference implementation on GitHub.