The deployment wizard

Run dp-deploy with no arguments, in a terminal, and it asks you what you want to do and does it:

C:\deploy> dp-deploy
DPLens deployment wizard. Blank keeps the value in brackets; q cancels.
Only your CHOICES are saved (deploy-plan.json). The deployment key is shown once by the capture and never written by this tool.

How will the agent reach the hosts?
  1. push — dp-deploy installs / updates the hosts over WinRM (workgroup: HTTPS + a local administrator)
  2. gpo — Group Policy Software Installation of the signed derived MSI; the key via Group Policy Preferences
  3. intune — Intune Win32 app: the derived MSI with a requirement / pre-install script staging the key
  4. sccm — SCCM / MECM application or task sequence
  5. rmm — an RMM tool runs the key snippet then msiexec
  6. cloud — cloud image / user-data runs the key snippet then msiexec
  7. hand install — one host by hand with the legacy MSI properties (no payload)
  8. transform bundle — the secret-free .mst bundle (dp-deploy bundle) for a config with no secrets

Every prompt shows its default in brackets; press Enter to keep it, type q to stop without saving anything. Nothing runs until you have answered everything the step needs.

What it walks you through

For any choice that uses the deployment MSI:

1. Capture. If DPLens is installed on this machine, the wizard offers to capture it as the reference — the output folder, the console port if it is not the default, whether to carry the console certificate, each portability finding to acknowledge, and an expiry in days. Otherwise it asks for the folder of a capture you made elsewhere. The capture prints the deployment key once; the wizard reminds you to put it in your secrets manager before it moves on.
2. Build. The signed product MSI, an output folder, and licence key files one per line until you leave one blank. A file that does not exist is skipped by name, not silently.
3. Then, for a push: the targets file, an optional share, the canary size, the abort threshold, the concurrency, HTTPS with its thumbprints and credential files, where to stage the key, and — if you have pushed before — the previous bundle as the rollback choice. Finally, whether to run the push now. If you do, you paste the deployment key when asked; it is held in memory for the run and never saved.
4. For every other channel: the wizard prints the channel's next steps — sign the package, stage the key with the emitted script, the msiexec line, the detection rule — the same steps documented under Group Policy and Intune, Configuration Manager, RMM and cloud images.

Hand install and transform bundle need no capture: the wizard prints the dp-deploy properties or dp-deploy bundle command for the older, secret-free routes.

The plan file

At the end the wizard saves deploy-plan.json in the current directory and prints:

Replay these choices later: dp-deploy run --plan deploy-plan.json

The plan holds your choices only — paths, the channel, the rollout numbers. It cannot hold a deployment key, a password or a credential: the file format has no field for one, and a plan containing such a field is refused by name. Check it in, share it, put it in a ticket.

dp-deploy run --plan deploy-plan.json replays it without prompts:

• the capture runs unless deploy.payload already exists in the plan's capture folder;
• the build runs unless bundle.json already exists in the plan's output folder;
• then the push runs — the key on standard input, as for dp-deploy push — or the channel's next steps are printed.

So a plan replayed twice does the work once, and a plan checked into your change-control repository is a repeatable, reviewable deployment.

When there is no terminal

dp-deploy with no arguments from a script, a pipe or a scheduled task prints the usage text and exits with code 2. The wizard only starts when both its input and its output are a terminal, so a tool that runs dp-deploy expecting a command never finds itself answering prompts.