Identify environment to be tagged as production
The following table guides you on the principles and rationale behind tagging an environment as production.
| Principle | Rationale | Examples |
|---|---|---|
| Include all releases regardless of their type. | Ensures it tracks all the productivity tasks, including tasks focused on both business value and operational excellence. | - Production deployment of new product features - Publish golden images for customers to consume - Publish reusable templates for customers to consume (e.g. SIAC, SHIP-HATS templates) - Production security patches - Production monitoring rules - Production backup configurations - Production bug fixes Similar activities performed on Non-Production environments IF they are services provided to customers, e.g. CStack DEV & STG, APEX STG are used by customers directly |
| Include only final release action and exclude intermediary steps. |
Ensures there is no double-counting of ‘releases’. If the final action is manual, drive behaviour to automate it. | - Building a container image in repo A pipeline and updating repo B to use the new image and trigger a release. Then Repo A should be excluded from counting as a release. - Building a binary in repo A pipeline, and manually deploying the binary without using pipeline. Then Repo A should be excluded. No deployment will be counted for the release. - Building a container image in repo A pipeline, and it is automatically pulled by the target environment and deployed. Then Repo A should be included as a release action since it is the final deployment action. |
