Managing Releases with the CLI

This topic describes how to use the Replicated CLI to create and promote releases.

For information about creating and managing releases with the Vendor Portal, see Managing Releases with the Vendor Portal.

For information about creating and managing releases with the Vendor API v3, see the releases section in the Vendor API v3 documentation.

Prerequisites

Before you create a release using the Replicated CLI, complete the following prerequisites:

Install the Replicated CLI and then log in to authorize the CLI. See Installing the Replicated CLI.
Create a new application using the replicated app create APP_NAME command. You only need to do this procedure one time for each application that you want to deploy. See app create in Reference.
Set the REPLICATED_APP environment variable to the slug of the target application. See Set Environment Variables in Installing the Replicated CLI.

Example:
```
export REPLICATED_APP=my-app-slug
```

Create a Release From a Local Directory

You can use the Replicated CLI to create a release from a local directory that contains the release files.

To create and promote a release:

(Helm Charts Only) If your release contains any Helm charts:
1. Package each Helm chart as a .tgz file. See Packaging a Helm Chart for a Release.
2. Move the .tgz file or files to the local directory that contains the release files:
```
mv CHART_TGZ PATH_TO_RELEASE_DIR
```
  Where:
  - CHART_TGZ is the .tgz Helm chart archive.
  - PATH_TO_RELEASE_DIR is path to the directory that contains the release files.
  Example
```
mv wordpress-1.3.5.tgz manifests
```
3. In the same directory that contains the release files, add a HelmChart custom resource for each Helm chart in the release. See Configuring the HelmChart Custom Resource.
Lint the application manifest files and ensure that there are no errors in the YAML:
```
replicated release lint --yaml-dir=PATH_TO_RELEASE_DIR
```
Where PATH_TO_RELEASE_DIR is the path to the directory with the release files.

For more information, see release lint and Linter Rules.
Do one of the following:
- Create and promote the release with one command:
```
replicated release create --yaml-dir PATH_TO_RELEASE_DIR --lint --promote CHANNEL
```
  Where:
  - PATH_TO_RELEASE_DIR is the path to the directory with the release files.
  - CHANNEL is the channel ID or the case sensitive name of the channel.
- Create and edit the release before promoting:
  1. Create the release:
    replicated release create --yaml-dir PATH_TO_RELEASE_DIR
    Where PATH_TO_RELEASE_DIR is the path to the directory with the release files.
    
    For more information, see release create.
  2. Edit and update the release as desired:
    replicated release update SEQUENCE --yaml-dir PATH_TO_RELEASE_DIR
    Where:
    - SEQUENCE is the release sequence number. This identifies the existing release to be updated.
    - PATH_TO_RELEASE_DIR is the path to the directory with the release files.
    For more information, see release update.
  3. Promote the release when you are ready to test it. Releases cannot be edited after they are promoted. To make changes after promotion, create a new release.
    replicated release promote SEQUENCE CHANNEL
    Where:
    - SEQUENCE is the release sequence number.
    - CHANNEL is the channel ID or the case sensitive name of the channel.
    For more information, see release promote.
Verify that the release was promoted to the target channel:
```
replicated release ls
```

Prerequisites​

Create a Release From a Local Directory​

Prerequisites

Create a Release From a Local Directory