Auto Deploy

Introduced in GitLab 8.15.
Auto deploy is an experimental feature and is not recommended for Production use at this time.

As of GitLab 9.1, access to the container registry is only available while the
Pipeline is running. Restarting a pod, scaling a service, or other actions which
require on-going access will fail. On-going secure access is planned for a
subsequent release.

As of GitLab 10.0, Auto Deploy templates are deprecated and the
functionality has been included in Auto
DevOps.

Auto deploy is an easy way to configure GitLab CI for the deployment of your
application. GitLab Community maintains a list of .gitlab-ci.yml
templates for various infrastructure providers and deployment scripts
powering them. These scripts are responsible for packaging your application,
setting up the infrastructure and spinning up necessary services (for
example a database).

How it works

The Autodeploy templates are based on the kubernetes-deploy
project which is used to simplify the deployment process to Kubernetes by
providing intelligent build, deploy, and destroy commands which you can
use in your .gitlab-ci.yml as is. It uses Herokuish,
which uses Heroku buildpacks
to do some of the work, plus some of GitLab's own tools to package it all up. For
your convenience, a Docker image is also provided.

You can use the Kubernetes project service
to store credentials to your infrastructure provider and they will be available
during the deployment.

Private project support

When a project has been marked as private, GitLab's Container Registry requires authentication when downloading containers. Auto deploy will automatically provide the required authentication information to Kubernetes, allowing temporary access to the registry. Authentication credentials will be valid while the pipeline is running, allowing for a successful initial deployment.

After the pipeline completes, Kubernetes will no longer be able to access the container registry. Restarting a pod, scaling a service, or other actions which require on-going access to the registry will fail. On-going secure access is planned for a subsequent release.

PostgreSQL database support

In order to support applications that require a database, PostgreSQL is provisioned by default. Credentials to access the database are preconfigured, but can be customized by setting the associated variables. These credentials can be used for defining a DATABASE_URL of the format: postgres://user:password@postgres-host:postgres-port/postgres-database. It is important to note that the database itself is temporary, and contents will be not be saved.

PostgreSQL provisioning can be disabled by setting the variable DISABLE_POSTGRES to "yes".