Release Process

Here are some notes about the process we use to run releases. The code for building kibana and pushing the release is a part of the repo but there are a few manual steps in the process.

Prereqs

Before running the release you need to have credentials for s3 that will allow you to upload the builds for the download.elastic.co bucket.

Setup credentials

1. Get the keys from another contributor and place in a .aws-config.json file at the root of the kibana repo. Use the following format:

```json
{
  "key": "<access key>",
  "secret": "<secret>"
}
```

2. Make a copy of this file outside of the repo, in case it gets deleted (via git clean for instance)

3. You will need AWS console access for S3 to do the non-staging public release.

Create a branch for this version

If there isn't one already, make sure to create a branch on git for this specific version. The branch name should exactly match the version in the README.md and package.json.

git checkout -b <version>

Create a release candidate

You'll create multiple snapshot builds for internal testing and QA. For the final release, you'll end up repeating these steps in addition to a few others.

1. Make sure you're on the branch with all of the relevant commits you want to build

2. Check your node version

It's imperative that you are using the exact same node version that is listed in `.node-version` and `package.json`. Manually double check that:

```sh
node -v
```

3. Clean out all changes (including .DS_Stores files and other hidden files)

```sh
git clean -fdxn -e ".aws-config.json" -e "config/kibana.dev.yml"
## check files that would be removed
git clean -fdx -e ".aws-config.json" -e "config/kibana.dev.yml"
```

4. Install node modules

```sh
npm install
```

5. Run the release task

```sh
npm run release -- --release
```

6. Distribute links to the team so they can test

Release day

When you're ready to pull the trigger on the public release, you'll publish the most recent release candidate, which at this point should have no outstanding known issues.

1. Create a tag

Make sure you're on the exact same commit as the release candidate you're about to publish.

Ideally, all version tags will be GPG signed. https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

git tag -s "v<version>" -m "version <version>"
git push upstream v<version>

2. Publish the most recent release candidate builds

For now, this process is manual. Log into AWS console and navigate to the S3 bucket/path of the release candidate that you just tagged. Copy all of the artifacts (.zip, .tar.gz, .rpm, .deb, .sha1.txt) to the public kibana path.

3. Make sure there is a blog post, the downloads page is updated including links to release notes and this verion's readme, there's a forum post, and there's a tweet.