Skip to main content

Deployment files

A deployment file is the saved form of a deployment: a file you can commit to source control, attach to a task, or hand to an operator to re-run later. The Deployment tab's toolbar is the primary place you create, save, open, and run them.

Saving a deployment​

Three save options live on the Deployment tab's toolbar:

  • Save (Ctrl+S). Save to the deployment's current path. First-time saves open a file dialog so you can pick a location.
  • Save As (Ctrl+Shift+S). Save to a different path.
  • Export to Task. Attach the deployment file to a task in your task tracker (Jira or Azure Boards). You are prompted for a task ID each time and can look it up with Find to confirm it exists before exporting, so you can attach to any task, not just the one associated with the current branch. Only available when you're connected to a task tracker.

The default on-disk location and folder pattern for saved deployments are configured on the workspace's Settings → Release tab. That tab also controls whether deployments produced by the Release Workflow are stored as workspace files, attached to a task, or both.

Opening an existing deployment​

From the Deployment tab toolbar:

  • Open (Ctrl+O). Pick an existing deployment file.

From the main menu you also have:

  • Deployment → Open File…. Same as the toolbar Open.
  • Deployment → Recent Files. Pick from the recent list.
  • Deployment → Import from Task…. Load a deployment attached to a task. You're prompted for a task ID each time, so you can import from any task.
  • Deployment → Deploy from Manifest…. Load a deployment file and deploy it immediately.

Running a deployment​

Click Deploy (Ctrl+Shift+E) on the Deployment toolbar. This opens the Run Script dialog (the same dialog as the single-component Run) with a Mode picker for COMMIT vs ROLLBACK.

Pick the mode, click Run. DataStar executes every component in order; when it finishes a log tab opens showing the per-component results.

Previewing before you run​

Three toolbar actions run against the deployment without actually deploying:

  • What If. Preview of what the deployment would do.
  • Database Snapshot. Compare the deployment's items against the current database state.
  • SQL Export. Write the deployment out as a flat SQL script for review.

Reading the deployment grid​

Each row pins an item to a specific commit (the Version column). A few columns and indicators make it obvious when reality has moved on:

  • Latest Version. The newest commit where the file still exists. For a file that's been deleted upstream this is the last commit before the delete, not HEAD, so Update to Latest never tries to update to a version that doesn't contain the file.
  • Is Latest. Only ticked when the pinned version matches the latest version that contains the file.
  • Deleted-upstream rows are highlighted with a delete icon in the status column, and a banner at the top of the view tells you how many items are affected.

Per-row preview​

Right-click any row in the deployment grid for comparisons against specific targets:

  • Compare with Latest
  • Compare with Workspace
  • Compare Item with DB Snapshot
  • View History. Lists only the commits that actually changed this file. Merge commits that simply brought a branch forward are filtered out so they don't clutter the history with misleading "Modified" entries. The same rule applies wherever items get added to a deployment, including Add From Basket and the Release Workflow wizard.
  • Open Script. Opens the pinned version (not the working copy). The tab title shows the version, e.g. myscript.sql @1abb94c, and the file is read-only — it isn't locked while you're reading it. Works the same on Git and TFVC.

Deployment history​

Deployments that ran successfully appear in Deployment → History; see the history tab for the audit log, including links back to re-run or reverse a previous deployment.

What's next​

Last updated on