### Description Deploying via shell scripts is powerful in that it's incredibly flexible, but sometimes it's too cumbersome, ugly, or not functional enough. We need a higher-level construct, especially for deploys, that let's developers easily configure common deployment scenarios. ### Proposal * Introduce specific keywords for various deployment scenarios such as `kubernetes`, ideally through extensible plugins (#14178). * The deploy plugin may run in the context of the GitLab rails server rather than the GitLab runner. There are various pros and cons to this. * Running in Rails allows access to deployment variables without having to expose them to the runners. * Running in Rails allows easier return of richer information than simple pass/fail exit code. e.g. return information needed for connecting a terminal to a container. (Runners could support this, but we'd have to extend the API) * Plugins running in Rails might be more approachable than writing in Go. * Either way, the plugin would be able to directly connect services via API without needing scripts or CLIs. * Plugins could be tightly tied to Services to provide the ability to store variables or otherwise configure deployment at a project level (#23859) * Richer interactions could allow actions beyond simple deployment such as: * access a terminal that connects to running environments * smart monitoring of deployments * incremental/rolling deploys, canary deploys, blue/green deploys, traffic vectoring, etc. * simplifying closing environments * restart/pause/etc of environments * The obvious downside is that this would be GitLab-specific, and up to us to maintain as things change. ``` review_app: kubernetes: pod: my/pod/file variables: MY_APP_DOMAIN: review-$DOMAIN.app.com environment: name: review/$APP ``` ### Links / references * From https://gitlab.com/gitlab-org/gitlab-ce/issues/22864#note_16790373 and #23286 * GitLab Runner plugins: #14178 /cc @ayufan