Skip to content
fDeploy Documentation

Core concepts

fDeploy is built around a small set of concepts. If you have used other deployment tools before, most of these will be familiar — the details of how they compose are what matters.

Infrastructure

These describe where things run.

  • Deployment target — a Windows machine that runs the fDeploy Agent. Targets are where your software actually ends up.
  • Environment — a stage your software progresses through (e.g. Dev, Test, Production). A target can belong to one or more environments, so the same physical machine can serve multiple stages when that makes sense for your topology.
  • Target role — a tag on a target that describes what it’s for (e.g. web-server, app-server). A target can have multiple roles. Deployment steps pick targets by role + environment, which is how you reuse one process across all environments.

Projects

A project is one deployable thing — typically a single web application or service.

  • Project — owns a deployment process, a set of variables, and a history of releases.
  • Deployment process — the ordered list of steps that make up a deployment (IIS deploys, PowerShell scripts, email, HTTP requests, manual approvals). Each step can be scoped to specific target roles, environments, or conditions.
  • Variable — a named value used across the process and in target files. Variables can be scoped per environment, so ConnectionString resolves differently in Dev and Production. Sensitive values are encrypted at rest and masked in logs.
  • Progression — the phase pipeline the project must follow (e.g. Phase 1: Dev → Phase 2: QC → Phase 3: Production). fDeploy enforces the order: you cannot deploy a release to a later phase until the prior phase has succeeded for that release.

Runtime

These describe the act of deploying.

  • Release — an immutable snapshot of the project at a point in time: deployment process, variable values, and package references. You deploy releases, not projects directly.
  • Deployment — applying a release to one environment. The same release is typically deployed to several environments over its life (Dev → Test → Prod).
  • Task — a unit of executed work. Each deployment decomposes into one or more tasks (typically one per target per step). Tasks are where you watch progress and read logs.

Access

  • Team — a named group of users with one or more role assignments. Permissions are assigned to teams, not to individual users.
  • Role — a bundle of permissions scoped to projects, environments, or system-wide. See Available roles.

How they fit together

A concrete example:

  1. You define two environments (Dev, Prod) and register one target in each, tagging both with the web-server role.
  2. You create a progression with two phases (Phase 1: Dev, Phase 2: Prod).
  3. You create a project called CustomerPortal, assign it the progression, and define a deployment process with one step: Deploy IIS Website to web-server targets. You add a variable ConnectionString with different values per environment.
  4. When the code is ready, you create a release from the project — this snapshots the process, variables, and the selected package version.
  5. You deploy the release to Dev. fDeploy creates a task that runs the IIS deploy step on the Dev web-server target. The agent substitutes variables, installs the package, and reports success.
  6. With a successful Dev deployment recorded, the progression now unlocks Prod. You deploy the same release to Prod — fDeploy creates another task, this time against the Prod web-server target, using the Prod-scoped value of ConnectionString.

That loop — release → deploy to phase 1 → deploy to phase 2 → … — is the core workflow.