Skip to main content

Step 3: Deployment File

The third step. Curate the deployment manifest that will go out with this release.

Release Workflow, Step 3: Deployment File

  1. Step indicator: numbered breadcrumb showing all four steps; Step 3 is highlighted.
  2. Toolbar: Open, Save, Add, Deploy, and positioning controls.
  3. Deployment grid: the components in this deployment, with version, path, and status columns.
  4. Back / Next: navigate between wizard steps.

What's on screen​

This step embeds the full Deployment view directly in the wizard: the same grid, toolbar, and context menu you'd get from Deployment → New Deployment. If a deployment file already exists for this task, it's loaded automatically.

All the normal Deployment-view actions are available here:

  • Add. Bring in components from the basket, the branch, a commit, a date range, a task, a work item's changesets, or the file system. See Add to a deployment.
  • Move Up / Move Down (Alt+↑ / Alt+↓). Reorder.
  • Pos: textbox + Move To. Jump a row to a specific position.
  • Update to Latest. Refresh a row against the current version.
  • What If, Database Snapshot, SQL Export. Preview the deployment.
  • Save / Save As / Export to Task. Persist the deployment file.

See ordering and filtering for the full detail on those actions.

How the file is filled​

When the step opens, the deployment file is filled in this order:

  1. The existing file. A deployment file already saved for the task, in the workspace or attached to the task as the Release settings say, is loaded.
  2. Your commits. On Git, every outgoing commit: each commit on the branch that is on no remote branch yet, including commits made outside the wizard. A merge commit brings only the files the merge itself changed, and deleted files are left out. On TFVC, the check-ins made in Step 2. Only component files are added (a .sql, or a .json data document where the folder's template writes JSON), and files that are cloaked or outside the workspace's path filters are skipped.
    • A file new to the deployment is pinned to the commit that touched it. If two of the commits touched it, it takes the later one.
    • An item already in the deployment moves to the commit only when the commit is newer than the one it is at: an item already at a newer commit (moved by Update to Latest after a pull, say) stays where it is, unless it is flagged as not in the branch.
  3. The basket, when there were no commits to add. See below.

More than 200 new items asks first, as any add does (Add Many Items).

When there are no commits​

With no commits to add, the wizard offers the components in your basket instead, once per run of the wizard, in Add From Basket (buttons Add From Basket and Skip). Only basket items not yet in the deployment file are offered. A basket item counts as there already when its component is in the file in any form (its script, its data document, or this work item's changeset for it) at any version; an item at another version is neither offered nor moved, which is Update to Latest's job.

  • None of the basket is there: No commits were found to add to this deployment. Would you like to add the components currently in your basket instead?
  • Some of it is: only the rest is listed and added, for example No commits were found to add to this deployment. 10 items in your basket are in the deployment file already. Add the 3 basket items not yet in the deployment file?
  • All of it is: nothing is asked.

Where the file is saved​

Where the deployment file ends up is controlled by the Release tab of Workspace Settings:

  • Task Attachment. Uploaded to the tracked task.
  • Workspace Location. Written to a folder under the workspace root (using the configured Folder Pattern).

Moving on​

Next advances to Step 4: Finalize.