[Epic] GitLab Deploy (multiple steps, one step per release)
GitLab Deploy is continuous delivery functionality that bridges the gap between code and scheduler. For now it assumes you application consists of a set of (docker) containers that you want to deploy to a scheduler. For now we'll use Kubernetes or GCE as the scheduler but others such as Mesosphere DCOS and AWS ECS should work the same.
The tagline for GitLab Deploy can be: "Version controlled operations".
Three files in the repo specify how your application is deployed
- the Dockerfile(s) specify how the containers should be build
- the .gitLab-ci.yml file uploads the docker containers as part of the build artifacts
- the Kubernetes yml file determines what constellation of containers the application needs, in Kubernetes this is called a pod.
The functionality is based on two models (and corresponding database tables): deploy and environment. A deploy specifies the time when a specific commit was deployed to an environment. Shutting down an environment also counts as a deploy. And environment is similar to a pod in Kubernetes; a collection of docker containers configured in the scheduler that run an application.
The three UI steps
=> Moved to #20255 (closed)
- You can also specify an environment to deploy to in .gitlab-ci.yml for automatic deployments.
- Both the GitLab admin and project masters can add new providers to deploy to by adding Kubernetes credentials.
- It should be possible to also use this for database servers that need persistent storage by using Kubernetes volumes.
- Manual confirmation of a deployment DONE
- Container registry DONE
- Tagging builds with .gitlab-ci.yml ?
- Releases DONE
- Do a partial rollout where only part of the containers will be replaced (for example if only nginx needs to be replaced).
- Run .gitlab-ci.yml again on the same commits to recreate docker images with more recent Ubuntu packages (if a security fix was released).
- Specify secrets in encrypted storage that will become Kubernetes secrets => Moved to #20199 (closed)
- Add more information on the environment page if it is not available via a web interface (in Kubernetes): interactive shell, streaming logs and performance graphs.
- A view of what version of applications are deployed on the different environments. DONE
- Support for other container schedulers and PaaS platforms => Moved to #20199 (closed)
- Support for non-Paas deployments: SSH, S3, iOS testflight, Maven, Artifactory and sFTP
- Support for Chef, Puppet, Ansible and Salt (it is not clear to me at this time how this should work, upload cookbooks, manifests, playbooks, and modules?)
- Offer an API to trigger deployments and read the status.
- Offer an API to register as a scheduler/deploy target (look at the GitHub Deploy API)
- In the deploy new screen you can select 'always deploy to this environment' to make future deployments one-click instead of two.
@stanhu might be interested to work on this