Consolidated ASP Classic MVC framework from best components
Nelze vybrat více než 25 témat Téma musí začínat písmenem nebo číslem, může obsahovat pomlčky („-“) a může být dlouhé až 35 znaků.

4.8KB

Deployment Configuration

Dedicated defaults

The deployment controller and host installer use the same isolated defaults:

Parameter Default
SiteName AspClassicUnifiedFramework
AppPoolName AspClassicUnifiedFramework
DeployRoot D:\Deployments\AspClassicUnifiedFramework
BindingIpAddress 100.97.39.23
BindingPort 8085
HostHeader empty
ExpectedBranch master (controller)

Every value can be explicitly overridden. Site and pool names, deployment root, and host header containing Schedulicious are rejected as an additional safety boundary. The scripts do not enumerate another site as a configuration source and provide no adoption switch.

Configuration ownership

Repository public\web.config is the default template for first deployment. After the package is safely extracted and validated, the host installer initializes:

<DeployRoot>\shared\public.web.config

from the staged package's public\web.config. If InitialWebConfigPath is supplied on that first deployment, the validated host-local file at that path is used instead. The parameter does not replace an existing shared configuration. Configuration is never copied from another IIS site.

Every staged release receives the shared file before promotion. Change the shared file only through normal host configuration/change control and validate its XML. Keep secrets and production database paths out of source control.

IIS state owned by the pipeline

The pipeline owns only the named dedicated site and app pool. It may:

  1. create them, only when both are absent and only after a staged release validates;
  2. point the dedicated site at <DeployRoot>\releases\<release-id>\public;
  3. set system.webServer/asp enableParentPaths=true at that site's location;
  4. start/recycle the dedicated app pool and start a newly created site.

It does not alter unrelated sites, app pools, bindings, authentication, identities, ACLs, Windows features, or IIS modules. It does not add bindings to an existing site.

When the target already exists, the site and pool must both exist and exactly match the requested app pool, sole HTTP binding, and pipeline-owned release-public path. Any mismatch fails closed.

Controller parameters

scripts/deploy-iis-git.ps1 supports:

  • SiteName, AppPoolName, DeployRoot, BindingIpAddress, BindingPort, HostHeader: dedicated target identity and binding.
  • InitialWebConfigPath: optional host-local first-deployment seed.
  • RemoteTarget, RemotePort: OpenSSH transport.
  • SourcePath: standalone checkout to validate/package.
  • ExpectedBranch: remains master by default.
  • ReleaseId: optional immutable release identifier.
  • BaseUrl: explicit host-side smoke-test URL.
  • KeepReleases: reporting threshold only; no deletion.
  • LocalPreflightOnly: local source/XML/package/safety validation; no network.
  • PreflightOnly (HostPreflightOnly and RemotePreflightOnly aliases): run local/package checks, then stream the installer over SSH for host validation without writing remote files or changing IIS/deployment state.
  • DryRun: local package validation plus remote command preview; no network.
  • AllowAnyBranch, AllowDirty: reviewed provenance exceptions.
  • RunMigrations: explicit database migration opt-in.
  • SkipSmokeTest: explicit smoke-test exception.
  • Rollback and RollbackTo: switch the dedicated target to a validated prior release.

Host installer parameters

scripts/install-iis-release.ps1 accepts the same target/configuration parameters plus:

  • PackagePath, ReleaseId, ExpectedSha256: deployment artifact inputs.
  • PreflightOnly or DryRun: read-only host checks; the target may be absent.
  • RollbackTo: validated release ID for rollback.

Host preflight requires elevation and verifies WebAdministration, Classic ASP feature and AspModule, URL Rewrite, requested binding conflicts (including wildcard overlap), shared-pool conflicts, deployment drive/path accessibility, names, and exact existing-target state. It makes no IIS or deployment-root changes.

Failure scope

If creation or smoke testing fails, the installer removes only a site or app pool whose creation flags were set by that invocation. For an existing valid target, it restores the captured physical path and parent-path value. Unrelated IIS resources are never cleanup candidates.

Package staging/release files can remain as diagnostic evidence. Database migrations and external writes are outside IIS rollback.

Secrets, identity, and writable data

Use OpenSSH configuration, an SSH agent, or a CI secret store. Do not commit passwords, private keys, production connection strings, or database files. Put production databases and logs outside release directories. App-pool identity and filesystem ACL provisioning are explicit host-administration tasks, not inferred from another site.

Powered by TurnKey Linux.