Skip to content
fDeploy Documentation

Your first deployment

With the project from Your first project in place, you can now create a release and deploy it. This page covers the simple PowerShell path; if you are deploying IIS content, read Option B first.

1. (Option B only) Upload a package

If your deployment step is Deploy to IIS, your project needs a package in the library for the release to snapshot against. Navigate to Library → Packages and upload a .nupkg containing the web content you want to deploy. See packages for the expected package structure and how versioning works.

If your step is Execute a script (Option A), skip this — PowerShell steps embed the script body in the deployment process itself and do not need a package.

2. Create a release

Open your project and navigate to the Releases tab, then create a new release. Give it a version string (e.g. 1.0.0) and — if you uploaded a package — pick the package version it should reference.

Creating the release freezes a snapshot of the project’s deployment process and variable values as they exist now. Later edits to the project will not affect this release. See creating releases for more detail, and variable snapshots for how the snapshot is updated if you need to.

3. Deploy to your environment

From the release details view, click Deploy and pick the environment (the one you created in first-project). Confirm — fDeploy creates a deployment and begins executing it.

Because your progression has only one phase, no gating is in play. In a real multi-phase progression, you would only be able to deploy to Phase 2 environments after a successful deployment to every Phase 1 environment — see deployment gating.

4. Watch progress in Tasks

Navigate to Tasks to see the deployment execute. The deployment decomposes into one task per step per target; for this walkthrough, that’s one task. Click the task to open its detail view and watch the log stream live — the log auto-refreshes while the task is running.

  • Running tasks refresh every 5 seconds.
  • Completed tasks stay in the history.
  • Failed tasks also stay — click into the log to see the error, fix the problem, and either redeploy the same release or create a new one.

See tasks for the full task lifecycle and filtering.

5. What just happened

When you clicked Deploy:

  1. fDeploy resolved the step’s target roles against the target environment and picked the matching targets (your single web-server target).
  2. It dispatched the step over TLS to the fDeploy Agent on each target, with server-side variable substitutions already applied.
  3. The agent executed the step (ran the PowerShell script or installed the IIS package) and streamed the output back to the server as task log entries.
  4. On step success, the task was marked Completed and — because your progression gates on success — the release is now eligible to deploy to the next phase (if any existed).

Where to next

  • If your deployment failed, the task log is the first place to look.
  • If you want to add more environments and promote releases through phases, see environments and progressions.
  • If you want to add more deployment steps, see deployment steps — the catalog covers IIS, PowerShell, HTTP requests, manual approvals, and email notifications.
  • If you are ready to invite your team, see teams and user management.

Option B: Deploy an IIS package

The walkthrough above uses a PowerShell script because it requires no extra setup. If your real use case is IIS, the full path is:

  1. Build your web application and pack its output into a NuGet package. See packages for the expected file layout.
  2. Upload the package to Library → Packages.
  3. In your project’s deployment process, add a Deploy to IIS step instead of (or in addition to) the script step. Configure the site name, application pool, and binding — most fields accept variable binding so you can parameterize per environment.
  4. If the binding is HTTPS, upload the certificate to the certificate library first and reference it from the binding — the agent will install it into the target’s certificate store automatically on deploy.
  5. Create a release that references the package version, and deploy as above.

From there, IIS deployments work the same as any other step — targets are selected by role, variables substitute per environment, and the task log shows each target’s progress.