I think there may already be some discussion around this in some other tasks too, but I would separate the "build" concept from the "deploy" concept, and introduce the idea of a "release" as well. Purely from a UX perspective, this could look like:

• build: Does what it does now, i.e. takes source code and creates an application image that is pushed to the container registry.
• release: This would take an image and deploy it, i.e. start a webservice if there is none, or restart the webservice if this is an update. Any one-off jobs that are part of the deployment such as db migrations are run as part of this process.
• deploy: A shortcut for build followed by release.

Implementation wise, it could be a good thing to keep these concerns separate as well, e.g. not use the build pipeline to trigger a webservice restart.

In T341065#8990009, @Slst2020 wrote:

I think there may already be some discussion around this in some other tasks too, but I would separate the "build" concept from the "deploy" concept, and introduce the idea of a "release" as well. Purely from a UX perspective, this could look like:

• build: Does what it does now, i.e. takes source code and creates an application image that is pushed to the container registry.
• release: This would take an image and deploy it, i.e. start a webservice if there is none, or restart the webservice if this is an update. Any one-off jobs that are part of the deployment such as db migrations are run as part of this process.
• deploy: A shortcut for build followed by release.

Implementation wise, it could be a good thing to keep these concerns separate as well, e.g. not use the build pipeline to trigger a webservice restart.

I like the separation :)

On the user side, would that be different top-level clis? like:

>$ toolforge deploy

Or would it be a subcomand of some sort?

>$ toolforge webservice deploy
# or, maybe more generic if we allow having other non-webservice applications
>$ toolforge app deploy

hmm... it feels though that it should be a new API too, either moving webservice to an API and extending it with the deploy endpoint, or creating a new 'apps' api.

Maybe by default it should be just like webservice, and we can extend it later to allow passing an 'app/name' parameter, like a first iteration would be:

>$ toolforge deploy  # just creates/update the webservice

In the future:

>$ toolforge deploy --app-name=worker  # starts a non-webservice app
>$ toolforge deploy --app-name=webservice  # start a webservice (probably we can make it the default value for the option also, keeping backwards compatibility)
>$ toolforge deploy # same as the one above

This means though moving some/most of the webservice logic to that deploy api (as it has to create a webservice itself).
We can make it only k8s though, and leave the grid stuff in the webservice cli.

We can pair that with extending the buildservice to be able to build more than one image, adding the --app-name parameter to it too, having 'webservice' as the default also.

I have to think a bit more about this, but starts looking like a plan xd

As we begin to expand our focus beyond the build system, it may be wise to pause and consider the broader perspective before venturing further. Given that many team members will be on vacation over the next 4–6 weeks, this discussion may need to be postponed slightly. I've created a task about this: https://phabricator.wikimedia.org/T342077