If you have have purchased ISM in the cloud you have 3 tenants at your disposal and they each have a purpose.
STG (Staging): The STG tenant is where you do your design/development work in ISM. It’s where you create/modify/delete parts of ISM to improve your system. Staging is where you can test out new ideas, build new dashboards, change business rules and see what they affect, etc. This is your development sandbox essentially. Staging holds a copy of your current Production DB so you can test out how things will work with real data behind it. You can package up those changes once you’re done and move them to the next tenant, UAT.
UAT (User Acceptance Testing): UAT is your testing tenant for changes you have made in STG. This is where after you push your package from STG to UAT you can have other outside users test your changes and see if they are working as intended. UAT is not development. It’s just for testing development changes. If the changes you made aren’t working properly, simply request that UAT be refreshed with PROD data then fix the changes in STG. Once your changes are done package them up again and apply it to UAT and begin testing again.
PROD: This is your LIVE system and by default the metadata is locked so you can’t make too many changes here. It is best practice to keep this locked at all times and any changes to the system follow the STG>UAT>PROD path of deployment. Once your UAT is done and everything is working as it should you can promote the package you created in STG to PROD and it will be live in real time.
Having and using the three tenants is vital to the stability of the system. It is crucial that changes aren’t made on the fly in PROD. We don’t want any downtime and it’s very easy to make a simple typo and bring the system down. Many other products use this methodology, so it’s not anything new. When developing for ISM it’s is always best practice you follow the STG>UAT>PROD package promotion path.
-Chris Revelia, Consultant