- v1.0.0-latest-prod
Sandboxes are the primary concept used to identify a temporary space where user changes are explored and vetted before final application to production. Sandboxing requires that a user be able to make a change to a sandboxable entity and have those changes isolated to an individual instance that only that user can see. Furthermore, promotion workflows require that a user be able to promote a change forward into one or more approval views that possibly have visibility to multiple users.
Users may revert changes made in the user’s sandbox. Approvers may reject changes made in an approval sandbox, which results in one or more changes being moved backwards in the workflow - possibly all the way back to the originating user.
Users capable of scheduling deployments may do so once the change has passed all approval gateways. Scheduling for deployment may be immediate, or may be set for a future date/time.
The primary goal of the sandbox service is to manage the creation and upkeep of Sandbox and ChangeSummary related
domain. This information is available to tooling (e.g. the admin tool) to drive sandbox selection and is
included during request interaction with other microservices that themselves manage sandboxable domain. See
Sandboxing In Detail for more information on how
sandboxId is utilized during microservice request calls for filtering and persistence.
The sandbox service manages status of ChangeSummaries, which mark sandbox state of sandboxable entites
across various resource tier services. The sandbox service provides API for managing the state of
the ChangeSummaries and is capable of communicating requests for sandbox transition to many
sandboxable resource tier services via the messaging channel. The sandbox service provides a unified
view and single point of management for workflow change state across the entire service fabric.
Specific types of transition may be scheduled - namely deployments. The sandbox service is also capable of managing immediate or scheduled deployment transitions. It interacts with the Scheduled Job Service to setup a deployment transition that will execute in the future.
The actual persistence behavior in regard to sandboxable entities is handled as a result of consumption of an event emitted by the Sandbox service. As such, the sandbox service is a state management component, while sandboxable services themselves execute state management commands on their local entities. Review Data Workflow for more information on how sandboxable services interact with sandbox information.