Amazon SageMaker Unified Studio: Release Center

01 — Context

What is SMUS, what is DevOps, and why this integration matters

Amazon SageMaker Unified Studio (SMUS) is a unified off-console environment for data analytics and AI creation where teams build notebooks, data assets, ML models, and AI applications in one governed workspace. DevOps is the set of practices that connects development and operations through CI/CD, enabling faster and safer release cycles.

Adding a DevOps stage environment directly into SMUS is valuable because users no longer need to break flow between artifact creation and release preparation. Instead, they can create, validate, and promote artifacts with release intent visible across stage contexts before production rollout.

SMUS Overview What Amazon SageMaker Unified Studio includes

Amazon SageMaker Unified Studio overview

Amazon SageMaker Unified Studio is a unified data and AI development environment that brings project setup, data access and analysis, model/app building, and artifact collaboration into one governed workspace. These images represent that end-to-end SMUS flow, from project creation to data work and AI artifact creation in a single product experience.

E2E Story Diagram Release Center end-to-end workflow narrative

This diagram illustrates the project’s end-to-end story: domain and project setup, stage-aware artifact operations (Dev/Test/Pre-prod/Prod), and controlled progression toward production release inside the SMUS workflow.

Context SMUS product structure

This view explains the foundational SMUS structure: domains are the primary entities, and each domain can contain multiple projects. Domains are created in the AWS Console using AWS platform resources. After a domain is launched in the external SMUS off-console experience, data professionals can create projects inside that domain. Each project is provisioned using project profiles that data administrators preconfigure for the domain in the AWS Console.

The SMUS workflow and the customer need to release artifacts

In the SMUS workflow, teams discover and prepare data, build notebooks and models, and create AI applications and related artifacts inside a unified product surface. Work can move quickly during creation, but delivery confidence depends on a clear path to release.

Customer need was explicit: after building artifacts, they needed a reliable way to move those artifacts toward production through controlled environments without breaking context or relying on disconnected handoffs.

“Creation was already unified in SMUS. Customers needed release to be just as unified.”

This section reframes the core gap: artifact creation existed in SMUS, but release progression required clearer in-product stage flow to support safe production readiness.

Context SMUS product workflow

This end-to-end SMUS workflow shows how teams move from domain onboarding and project setup, into data discovery, query and transformation work, notebook/model/app artifact creation, repository commits, and collaboration handoffs. It also highlights where release operations were historically disconnected from the in-product creation flow, clarifying why stage-aware Release Center integration is critical for moving artifacts from active development toward controlled production readiness.

Context Customer problem framing

Context artifact showing why build and release fragmentation created friction across SMUS personas.

Context Key Subject terms Relevant to Release Center

Shared language used with partners and customers to align how domains, projects, artifacts, and release stages connect.

02 — DevOps + Stages

Bringing DevOps and CI/CD stages into the SMUS experience

DevOps combines development and operations practices so teams can continuously build, validate, and release software through CI/CD pipelines. In SMUS, users previously created artifacts, notebooks, models, and AI apps, then depended on external tools to manage release and deployment workflows.

Release Center introduces in-product stage awareness so users can work within Dev, Test, Pre-prod, and Prod contexts and move artifacts down a defined CD path while keeping delivery intent visible in SMUS.

Workshop Problem-to-solution translation

Release Center explanation of solution from workshop

Facilitation artifact used to translate customer pain points into a staged Release Center interaction model.

MVP Model High-level Release Center flow

AI/DevOps-oriented flow framing used to define how stages and promotion behavior should appear in-product.

MVP Scope Expanded workflow set

Detailed workflow set illustrating release actions, responsibilities, and system boundaries.

03 — Work Process

Collaboration process across design, engineering, PM, and customers

This work required intensive collaboration with back-end and front-end engineers, product managers, and technical writers, plus repeated customer conversations to validate release-stage assumptions and real-world pipeline behavior.

Customer discussions with Intuit, Siemens, and Oracle informed the journey mapping, stage semantics, and release guardrails represented in the final UX direction.

E2E Workflow Collaborative workflow artifact for Release Center stage setup and operation

Release Center end-to-end workflow with release stages

Screenshot of a collaborative workflow artifact created with design, PM, and engineering partners to map the end-to-end path users follow to configure Release Center stages and operate within those stages in SMUS before releasing artifacts to production.

Workshop Workflow and journey-map synthesis

Release Center workshop journey and workflow diagram

Cross-functional workshop board used to align customer journeys with CI/CD-stage behaviors.

04 — Wireframes

Design work in progress: wireframe exploration

Wireframes were used to test information architecture, stage visibility, and commit/promotion interactions before visual polish. The focus was behavior clarity first, then visual refinement.

Wireframe Snapshot from multi-round, multi-board wireframing

Release Center wireframes across multiple rounds

This image is a snapshot from a broader multi-step wireframing phase. Across multiple rounds and boards, I worked closely with PM and developers to iterate on ideas, test interaction directions, and refine stage setup and artifact-release flows before moving to hi-fi design.

Wireframe Project creation with stages

Wireframe for project creation with stage setup

Wireframe concept for embedding stage configuration early in project creation.

Wireframe Project homepage stage state changes

Wireframe for project homepage stage changes

Stage-change behavior in early homepage concepts before hi-fi implementation.

Wireframe Query Editor tool commit interaction

Wireframe of query editor tool commit flow

Wireframe exploration of how users working in the project Query Editor make a code change and commit that change into the project repository flow.

Wireframe Project commits and stage pipeline

Wireframe for project commits in release center CD pipeline

Exploration of commit visibility and stage-based progression mechanics.

05 — Hi-Fi Comps

Integrating DevOps stages into domains and projects

Hi-fi comps formalized the core interaction concept: admins configure DevOps stages at domain level, then every project created in that domain inherits stage-aware release contexts. Users can work on artifacts in any stage and advance artifacts down the CD pipeline, while pipeline monitoring and management remain connected to third-party tools such as GitHub and GitLab.

Hi-Fi Release Center hi-fi prototyping round 1

First hi-fi pass refining visual hierarchy, stage cues, and promotion affordances.

Hi-Fi Release Center hi-fi prototyping round 2

Second hi-fi round validating stage operations and artifact progression behavior before finalization.

Hi-Fi Domain-level DevOps stage configuration

Hi-fi domain management with DevOps stage configuration

Admin-level stage setup in domain configuration establishes release structure for downstream project work.

Hi-Fi Project creation with Release Center stages

Hi-fi project creation with DevOps stages

Project setup inherits and operationalizes stage strategy defined at domain level.

Hi-Fi Project homepage stage contexts

Users can work inside explicit stage contexts (Dev/Test/Pre-prod/Prod) while editing artifacts.

Hi-Fi Query Editor code change and Dev-stage commit

Data analyst commits Query Editor code change in Dev stage

This screen shows a data analyst working in the Amazon Query Editor tool inside SMUS, making a code change and committing that change to the project repository while operating in the Dev stage environment.

Hi-Fi Commit flow from Dev to Prod

Hi-fi commit stage change toward production

Artifacts can be advanced down the CD path from lower-risk environments toward production readiness.

Hi-Fi Stage transitions and commit progression

Stage-change controls support explicit release progression while preserving environment separation.

06 — Outcome

Safer, faster release operations inside the SMUS platform

Release Center adds structured stage isolation and governance into everyday SMUS workflows. Teams can isolate risk, apply guardrails at each stage, and still move faster because release context stays connected to artifact creation and collaboration.

The result is a more reliable release loop: clearer ownership, safer promotions, and expedited delivery pipelines for analytics and AI artifacts.

Outcome SMUS Information architecture before Release Center

Before Release Center: release behavior lived outside the main SMUS operating model.

Outcome Release Center integrated architecture

SMUS information architecture after Release Center

After Release Center: stage-aware release operations become a first-class part of SMUS project workflows.

Amazon SageMaker Unified StudioRelease CenterDevOps Experience