Skip to main content

Creating Releases with Standard Manifest Files

This topic describes how to use the Replicated vendor portal or the replicated CLI to create and promote versions of your application using standard manifest files.

note

Replicated recommends using a git-based workflow. For more information about repository workflows and tagging, see Repository Workflow and Tagging Releases. For examples of CI/CD integration, see Tutorial: Integrating with an Existing CI/CD PLatform.

Using the Vendor Portal​

To create and promote a release in the vendor portal:

  1. From the Applications dropdown list, select Create an app or select an existing application to update.

  2. Click Releases on the left menu, and click Create release.

    Create Release

    View a larger image

  3. For the first release of an application, drag and drop your application files into the file directory in the YAML editor.

    If you are editing a draft or an existing non-promoted release, the files appear in the YAML editor. You can drag and drop new manifest files as needed.

    You can also click the plus icon to add a new, untitled YAML file.

  4. Edit the YAML files as needed, and click Save release. This saves a draft that you can continue to edit until you promote it.

    note

    To edit a draft release, click Edit YAML from the Releases page.

  5. Click Promote. In the Promote Release dialog that opens, edit the fields:

    FieldDescription
    ChannelSelect the channel where you want to promote the release. The defaults are Stable, Beta, and Unstable. If you created custom channels, they are listed here also.
    Version label

    Enter a version label.

    If semantic versioning is enabled for the channel, you must use a valid semantic version using the X.Y.Z format, where X is the major version, Y is the minor version, and Z is the patch version. These must be non-negative integers and cannot contain leading zeroes. Each element must increase numerically.

    For more information, see Enable Semantic Versioning in About Releases and Semantic Versioning on the Semantic Versioning website.

    Requirements

    Select Prevent this release from being skipped during upgrades to mark the release as required. When a release is required, the admin console requires users to upgrade to that version before they can upgrade to a later version.

    For example, if you select Prevent this release from being skipped during upgrades for release v2.0.0, users with v1.0.0 deployed must upgrade to v2.0.0 before they can upgrade to a version later than v2.0.0, such as v2.1.0.

    Required releases are supported in the app manager v1.68.0 and later.

    After users deploy a required version, they can no longer redeploy (roll back to) versions earlier than the required version, even if allowRollback is true in the Application custom resource manifest. See allowRollback in the Application custom resource topic.

    Release notesAdd detailed release notes. The release notes support markdown and are shown to your customer.

  6. Click Promote.

    The release appears in an Active state on the Releases page.

Using the CLI​

Prerequisites​

Before you can create your first release with Replicated, make sure that the following requirements are met:

  1. Configure the environment variables and install the replicated CLI. See Installing the replicated CLI.

    note

    Exporting the token environment variable is valid for a single session. You must export it for each new session.

  2. Create a new application using the replicated app create APP_NAME command. You only need to do this procedure once for each application that you want to deploy. See app create in Reference.

Create and Promote a Release​

This procedure shows how to create a new release using local application files and the replicated CLI.

To create and promote a new release:

  1. Make sure that you have a local folder with your application files.

  2. Lint the manifest files and ensure that there are no errors in the YAML:

    replicated release lint --yaml-dir=PATH_TO_APP_DIR

    Replace PATH_TO_APP_DIR with path to the directory of the YAML manifest files.

    For more information about linting, see release lint and Linter Rules in Reference.

  3. Create a new release:

    replicated release create --yaml-dir PATH_TO_APP_DIR

    Replace PATH_TO_APP_DIR with the path to the directory of the YAML manifest files.

    For more information, see release create or release update in Reference.

  4. Continue to edit and lint the release as needed, then update the release:

    replicated release update SEQUENCE --yaml-dir PATH-TO-APP-DIRECTORY

    Replace:

    • SEQUENCE with the release sequence number. This identifies the existing release to be updated.
    • PATH_TO_APP_DIR with the path to the directory of the YAML manifest files.

    For more information, see release update in Reference.

  5. Promote the release when you are ready to test it. Releases cannot be edited after they are promoted. To make changes after promotion, you have to create a new release.

    replicated release promote SEQUENCE CHANNEL_ID

    Replace:

    • SEQUENCE with the release sequence number.
    • CHANNEL_ID with the channel ID or case sensitive name of the channel.

    For more information, see release promote in the replicated CLI documentation.

  6. Verify that the release was promoted to the channel:

    replicated release ls

Next Steps​

The following are the recommended next steps to test the application in your development environment: