How do we do deploys

We need to do deploys to:

• container schedulers
• (cook/play)books to configuration management systems
• ssh support would be nice
• zero-downtime deploys/feature flags/etc. would be nice https://about.gitlab.com/direction/cicd/

We need it for environment deploys and review apps https://gitlab.com/gitlab-org/gitlab-ce/issues/20255

Options:

1. CI script howto: redspread for k8, Ansible for BitBucket pipelines (hard to configure and test)
2. Runner plugins similar to drone plugins (hard to set up and test credentials, we have to maintain an interface and a registry, Drone plugins can't send structured data back, how does it work with every plugin being a container)
3. Project services, intuitive suggestion for deploy to Terraform (user friendly but unclear how that works since coordinator has to do the work instead of the Runner)
4. Deploy/environment API https://developer.github.com/v3/repos/deployments/ (we probably want to do the deployment instead of just an API for it)
5. A library like or similar to the dpl gem

Adjunct concern is creation/destruction of environments, particularly for review apps. Alternatively, sharing multiple deploys in a single environment. e,g, use subdirectories to run multiple review apps in a single instance/container.

@markpundsack Good point that we need to think about this. Maybe a boolean for environments to mark them as transient. I can imagine multiple deploys with the same endpoint (Kubernetes staging cluster) but I'm not sold on using subdirectories.

Also in the Google Doc 'How do we do deploys', GitLab Inc. team members only.

Ugly solution, no plugins for now:

• $APP_NAME
• when: merge_request_update

Make nicer with magic later.

Technically, we don't even need $APP_NAME since the user can construct it, but we do need some url declaration associated with the environment that should be declared inside .gitlab-ci.yml.

@markpundsack cool, I agree we don't need $APP_NAME, some people might just use $CI_BUILD_MR_NUMBER.

mentioned in issue #20255 (closed)

Added ~19173 label

@ayufan and I discussed an even simpler MVP which just adds a way to specify the URL of a deployment. No $APP_NAME and no when changes. And wouldn't rely on any awareness of merge requests. You would create apps for each branch (regardless of MR or not). You'd have to manually clean up dead branches. Total minimalism here, but might be enough to test out the space.

One concern is that it implies a change to our environment model to move the URL to the deployment record rather than the environment. More importantly, all review apps would be in a single environment, which doesn't match the 12-factor definition of environment that we agreed to abide by.

@markpundsack

My idea is to try to create a new environments and update them with URL instead of using single environment.

I'll create a proof of concept so we can test that and see what implications it does have.

@ayufan that sounds like great idea!

Moved to https://gitlab.com/gitlab-org/gitlab-ce/issues/21971

Status changed to closed

Mentioned in issue gitlab-com/blog-posts#308 (closed)