Skip to content

Choose a service promotion path

Manual promotion lets a production EasyHosting environment deploy an image that was already built in another environment, without connecting the two EasyHosting servers or Kubernetes clusters.

For manual release promotion, both services must use the same Git repository and release stream. The producing service is normally configured for continuous delivery; the target service must be configured for manual promotion.

Choose between source and release promotion

EasyHosting supports several delivery models. Choose whether your production approval moves source code through Git or moves an already-built image through the EasyHosting UI.

Model Development service Production service How production is promoted What production deploys
GitFlow or environment branches Continuous from develop Continuous from main or production Merge a pull request into the production branch A new production build
Trunk-based manual promotion Continuous from the default branch Manual promotion with the same release stream Select and confirm a release in the production UI The exact image built from trunk
Fixed tag or commit promotion Continuous from one tag or commit Manual promotion with the same release stream Manually run the producer workflow, then confirm the release in production The exact image built from the pinned ref

GitFlow or environment branches

Use this model when merging into a protected production branch is your production approval:

flowchart LR
  Feature[Feature branch] -->|Merge| Develop[develop]
  Develop -->|Build and deploy| Dev[Development]
  Develop -->|Promotion pull request| ProductionBranch[main or production]
  ProductionBranch -->|Rebuild and deploy| Prod[Production]
  1. Configure the development service with source revision Branch, value develop, and Build and deploy continuously.
  2. Configure the production service with source revision Branch, value main or production, and Build and deploy continuously.
  3. Use separate release streams, for example my-application/api-develop and my-application/api-production.
  4. Merge feature changes into develop to deploy development.
  5. Promote source by opening and merging a pull request from develop into the production branch.

EasyHosting does not merge the branches. GitHub branch rules and reviewers control that action. After the merge, production builds again from its branch, so this model does not guarantee that production runs the exact image tested in development.

Trunk or release branch, build once and promote manually

Use this model when the same tested image must move from development to production:

flowchart LR
  Source[Trunk or release branch] -->|Continuous build| Image[Immutable image]
  Image --> Dev[Development]
  Image --> Catalog[Release catalog in Git]
  Catalog --> Releases[Production Releases page]
  Releases -->|User confirms| Prod[Production]
  Image --> Prod
  1. Configure the development or build service with Default branch and Build and deploy continuously.
  2. Enter a stable release stream such as my-application/api.
  3. Configure the production service from the same repository with Deploy only through manual promotion and exactly the same release stream.
  4. Merge changes to trunk and wait for the development build to publish a release.
  5. Open the production service's Releases page and manually promote the required digest.

Production does not rebuild the source and does not contact development. It reads the release record from Git and pulls the immutable image digest from the registry.

The producer can use a named integration or release branch instead of the default branch. Configure that branch for continuous delivery and use the same release stream in the manual production service. EasyHosting still promotes the built image; it does not merge the producer branch into a production branch.

Fixed tag or commit, then promote manually

Use this model for a deliberately pinned source snapshot:

flowchart LR
  Ref[Fixed tag or commit] -->|Run workflow manually| Image[Immutable image]
  Image --> Catalog[Release catalog in Git]
  Catalog --> Releases[Production Releases page]
  Releases -->|User confirms| Prod[Production]
  Image --> Prod
  1. Configure a producer service with source revision Release tag or Commit SHA and Build and deploy continuously.
  2. Enter the release stream that production will use.
  3. Manually run the generated workflow from GitHub Actions. Tag and commit sources are not triggered by pull-request merges.
  4. After the workflow publishes a release, select it from the production service's Releases page and confirm promotion.

A configured tag is one fixed tag, not a wildcard or a subscription to future tags. A later tag requires the producer configuration or generated workflow to be updated or recreated. Do not move an existing tag as a release mechanism.

Impact of the source revision choice

Source revision Continuous service behavior Manual-promotion service behavior
Default branch Builds the repository default branch after a pull request is merged into it; can also be run manually Stored for context but does not filter the releases available for promotion
Named branch Builds the named branch after a pull request is merged into it; can also be run manually Stored for context but does not filter the releases available for promotion
Release tag Checks out that fixed tag when the workflow is manually run Stored for context but does not filter the releases available for promotion
Commit SHA Checks out that fixed commit when the workflow is manually run Stored for context but does not filter the releases available for promotion

For manual promotion, the shared repository and exact release-stream value select the release candidates. The source revision does not merge branches, create tags, or add another filter to the release list.

Manual release-promotion procedure

Publish a release in development

  1. Create or configure the development service with Build and deploy continuously.
  2. Select its source: the default branch, a named branch, a release tag, or a commit SHA.
  3. Enter a new release stream, choose the generated suggestion (for example my-application/api), or choose an existing compatible stream from the autocomplete suggestions. The field starts empty.
  4. Merge the configured branch change or manually run the generated GitHub workflow.
  5. Wait for the build to finish. It publishes an immutable image digest and adds it to the repository's release catalog.

Configure production

Create the production service from the same repository and select Deploy only through manual promotion. Enter the same release stream used by development, or choose it from the autocomplete suggestions.

The suggestions are read from the release catalog in the shared Git repository. A stream appears as a suggestion after a continuous service has successfully published its first release, but users can always enter a new stream manually. This discovery does not connect the EasyHosting servers or Kubernetes clusters to each other.

Production does not start a build workflow. It reads release choices from Git and pulls the selected image from the shared registry. Registry credentials remain local to the production cluster.

Promote through the UI

  1. Open the production service.
  2. Select the Releases tab.
  3. Review the build time, source commit, and image digest.
  4. Select Promote for the required release.
  5. In the confirmation dialog, compare the source commit, target digest, and currently deployed digest.
  6. Select Confirm promotion.

EasyHosting records who requested the promotion, commits the digest-pinned image to this environment's manifest, and asks this environment's Argo CD to synchronize. The Promotion history changes from Pending to Deploying, then Succeeded when Argo CD reports the service healthy and synchronized to that promotion's manifest commit.

Nothing is promoted merely by opening the page or publishing a release. Confirmation in the target environment's UI is always required.

Roll back

Rollback is another manual promotion. Select an older known-good release, review its digest, and confirm it. This keeps both actions in the audit history.

Troubleshooting

  • A release stream is not suggested: enter it manually, or confirm a producer build has completed and production can read the shared repository's configuration branch. A configured producer alone is not enough to create a catalog suggestion; its first successful build creates the catalog entry.
  • No releases are shown: confirm both services use the same repository and selected release stream, and production can read the repository's configuration branch.
  • The deployed image changed while reviewing: refresh the Releases tab and confirm again. EasyHosting rejects stale confirmations.
  • Promotion failed before deployment: check repository permissions and branch rules. Correct the problem and explicitly promote again.
  • Promotion remains Deploying: inspect the service in Argo CD and Kubernetes. Common causes are unavailable registry credentials, an image that cannot start, or failed health checks.
  • A producer workflow says .easyhosting/releases is ignored: regenerate the service workflow or change its catalog staging command to git add -f "$release_file", then rerun it. Current generated workflows force-add EasyHosting-owned release records even when the repository ignores .easyhosting.
  • The repository deploy key or WRITE_DEPLOY_KEY secret is missing or no longer works: open Code repositories, select the repository, and choose More options > Refresh deploy key with WRITE access. After a successful refresh, rerun the failed workflow. See Repair a deploy key for permissions and failure recovery.
  • A producer workflow fails with GH013 and says changes require a pull request: verify that its configuration checkout uses ssh-key: ${{ secrets.WRITE_DEPLOY_KEY }} and that EasyHosting provisioned the repository deploy key and secret. Workflows generated without this setting must be regenerated after upgrading EasyHosting.