Releases

Whenever you deploy code, or change a config var, or remove (or add) an add-on resources you implicitly create a new release and automatically will cause your application to restart. You can see a history of releases, and roll back a release to revert the prior changes (if needed) through the CLI (aka releases:rollback), UI or Platform Apps API.

Release Creation

Releases are named vNNN where the NNN indicates the release id. The release's are sequential and unique to the application. One way to create a release is by manually providing a set of sources to build.

aka releases:create https://example.com/source_code.zip -a myapp-myspace
Deploying https://example.com/source_code.zip to myapp-myspace ... ✓

You can also trigger a new release by commiting into a branch on a source control repository Akkeris is watching.

git commit -a -m 'My commit message' ; git push
remote: Counting objects: 75, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 62 (delta 27), reused 44 (delta 9)
Unpacking objects: 100% (62/62), done.

aka releases -a myapp-myspace
• v1    1 minute ago    Auto-Deploy 6d58b1ce - User (username) - My commit message - ef5c71a

Attaching your app to a repository

If you'd like your application to build on a commit, you can do so by telling Akkeris to watch a repository for your application.

aka repo:set -a myapp-myspace https://github.com/org/repo the_branch_to_watch -u github_username -t github_token

Note that if you do not specify a branch by default master is watched. In addition, if your installation has a default service account for Github installed leaving off the username and token will cause Akkeris to try and use the default service account instead.

Generating a Github token

The github_token must be a personal access token generated by a user who has administrative access to the specified repo and the scopes:

• repo
• repo:status
• repo_deployment
• public_repo
• admin:repo_hook
• write:repo_hook
• read:repo_hook
• read:user

You can generate a personal access token on Github by going to https://github.com/settings/tokens and following the instructions.

Listing Release History

To see the history of releases for an app:

aka releases -a myapp-myspace
• v1    16 days ago    Auto-Deploy 6d58b1ce - GithubUser2 (Github User 1) - Another commit - ef5c71a
• v2    14 days ago    Auto-Deploy e08c02cb - GithubUser3 (Github User 2) - Some merge commit  - 3ad31be
• v3    10 days ago    Auto-Deploy cbc06f1b - GithubUser1 (GithubUser 3) - yet another - ece6039
• v4    9 days ago    Auto-Deploy 52aeae74 - c4357b9

Rollback

Use the rollback command to revert to the previous release:

aka rollback -a myapp-myspace
Rolling back to v3 on myapp-myspace

You may choose to specify another release to target:

aka rollback v1 -a myapp-myspace
Rolling back to v1 on myapp-myspace

Rolling back will create a new release which is a copy of the state of the compiled slug and config vars of the release specified in the command. The state of your source code repository, database, and external state held in add-ons (for example, the contents of memcache) will not be affected and is your responsibility to reconcile with the rollback.

Running on a rolled-back release is meant as a temporary fix to a bad deployment. If you are on a rolled-back release, fix and commit the problem locally, and re-push to akkeris.

Building From Sources

If a new release is creating by specifying a url to a zip, tar-gzipped file or from a Github commit akkeris will look for a Dockerfile at the root for instructions on how to build the application. Akkeris will add any non-service (user specified) config vars and build arguments to the docker build. In addition, if the build came from a source control commit the build args AKKERIS_GIT_SHA1, AKKERIS_GIT_BRANCH, and AKKERIS_GIT_REPO will be added.