Overview
Decisions has historically supported designer version control and cross-environment promotion through a Repository Server. Repository Server workflows focus on project-level check-in/check-out, revision history, and branching to support parallel development and controlled merges.
Deployment Server provides a newer deployment workflow for packaging, reviewing, and promoting validated changes across environments.
The repository Server and the Deployment Server can coexist. Repository-based workflows remain available for existing implementations, while the Deployment Server provides an alternative workflow model for managing deployments across environments.
What is the Deployment Server?
The Deployment Server is a dedicated Decisions server type that coordinates the packaging, review, and promotion of validated changes across environments. Work is bundled into Deployment Packages, and each package contains one or more Builds that provide traceability, quality signals, and an audit history as changes progress toward target environments such as QA and Production.
Core Concepts
- Organizations: Top-level containers that group projects and connect Development, Deployment, and target environments under a single hierarchy.
- Deployment Packages: Deployment-scoped bundles used to track, review, audit, and promote related changes.
- Builds: Versioned units created under a deployment package to track Project–User Story work, including unit test and QA status indicators.
Project Management and PMIS Alignment
The Deployment Server workflow uses Projects, Sprints, and User Stories to organize and track development work that is promoted through deployment packages. User stories support CSV import for bulk creation, enabling intake of work items from external systems that can export story/task data. User stories are also tied to builds to maintain traceability between planned work and deployed work.
Repository Server vs Deployment Server
| Category | Repository Server | Deployment Server |
|---|---|---|
| Primary Purpose | Designer project version control and promotion via check-in/check-out. | Structured packaging, review, and promotion of changes across environments. |
| Core Units | Projects, branches, revisions (commit history), tags. | Organizations, deployment packages, builds, projects/sprints/user stories. |
| Change Grouping | Commits (revisions) are created when projects are checked in, or via an optional selective check-in via the Check-In Wizard. | User stories included in a deployment package; builds accumulate and track changes for a project–user story combination. |
| Parallel Work | Branching and merging support parallel development and controlled promotions. | Multiple builds and packages support iterative promotion; emphasis is on validated readiness and traceability. |
| Rollback / Immutability | Rollback to a date or revision supported through branch/project actions. | Builds are immutable once created; deletion or rollback is not supported to preserve audit history. |
| Readiness Signals | Repository health signals exist, but deployment gating is workflow-driven and branch/revision-centric. | Unit test indicators, QA indicators, and package readiness rules determine promotion eligibility. |
| Server-to-Server Registration | Repository Server URL configured in Designer Repository Settings; optional Repo-SSO proxy configuration. | Key-based environment registration per instance, with time-bound authentication keys. |
Concept Mapping
| Repository Server Concept | Deployment Server Concept |
|---|---|
| Branch | Deployment Package as a deployment-scoped container for bundled work moving through environments. |
| Revision (commit) | Build created for included user stories; tracks versioning, test results, and QA review state. |
| Selective check-in | Include in the Deployment Package at the user story level or edit the package to select relevant stories. |
| Repository folder tree | Organization hierarchy with deployments grouped under All Organizations > [Organization] > Deployments. |
Deployment Server Workflow Summary
- Create an Organization on the Deployment Server to establish the top-level container for project routing, access control, and deployment tracking.
- Register environments (Development/QA/Production) to the Deployment Server using key-based registration under Deployment Server Connection Parameters.
- Plan work on the Development Server using Projects and Sprints. Sprints group user stories into time-bound cycles for organized execution and tracking.
- Include user stories in a Deployment Package using the user story option to include work in the current active package, or by editing the package to select the required stories.
- Generate Builds as work is committed to the deployment package. Builds provide traceability (Build ID, project, user story) and quality control signals (unit tests and QA indicators).
- Promote changes by deploying a deployment package to the next target environment. Deployment package versioning communicates the progression of major/package/build across the lifecycle.
Repository Server Workflow Summary
- Install and configure a Repository Server as a dedicated server type, using a separate database from Development/Production environments.
- Connect a Decisions environment to the Repository Server through Designer Repository Settings by configuring the repository server address.
- Check-in and check-out projects to push and pull project resources between connected environments and the repository.
- Use branches and revisions to manage parallel work, track changes, and support controlled merges between branches.
- Automate repository events using Repository Action Flows (before/after project creation; before check-in) to enforce criteria and apply governance at key points.