Enable more environments than "Prod" via deployctl

[csvn]

What problem are you trying to solve?

Hello! We have a cloud service used for B2B customers where we have several projects where we need more than just "Prod" (main) and "Preview" (branch). This is because we have need for developer testing environments as well as a specialized environment used by our sales department. It looks something like this:

Environment	Deployment	Env variables / KV	Description
Production	main	prod	Primary site. Used by customers
Demo	main (schedule: [email protected])	prod	Used by the sales department
Dev	main	dev	Used to mirror prod, but with non-production data
QA	main	stage	Here we can point KV to a local path for SQLite usage to always start with the same data (?)
Preview	[branch]	dev	Created for every PR to preview changes

Right now, we must create three projects to set a domain, environment variables and a separate KV for each, but this feels very unnecessary as the deployments we create (files being uploaded) are the same and duplicated many times. For this feature to work, it would be necessary to register a domain for each "environment" and as well as environment variables and which KV instance to use (or share).

Describe the solution you'd like

It's possible to add a new parameter to deployctl. Instead of passing --prod, it's possible to pass --env=prod or --env-name=dev, or via the action. Passing a comma separated list would deploy the same files to multiple environments, thus being able to reduce deployment files multiple times with different env config:

jobs:
  deploy:
    if: github.ref_name == github.event.repository.default_branch
    # ..
    - uses: denoland/deployctl@v1
      with:
        project: ${{ vars.DENO_PROJECT_ID }}
        entrypoint: ./main.ts
        environment: prod,dev,qa 

The deployctl instance would then use the variables/kv-instance/domain configured for each environment name when creating the deployment.

Describe alternatives you've considered

I feel like doing this would help a lot with consolidating all the information in the Deno Deploy Dashboard. Right now we are using 6 projects for 3 Github repositories. So to view logs/analytics/KV would mean constantly swapping around between different projects. It also makes it more complicated to share KV data in a good manner.

So it's possible to work around this issue by creating multiple sites, but that also has the drawbacks I mentioned above, creating friction.

Documentation, Adoption, Migration Strategy

No response

[willnewby]

Hey @csvn , this is a super helpful piece of feedback. I've added it to the backlog to assess with the team, thanks for sharing it with us. :)

[lishaduck]

This would also be helpful in monorepos, where I've got both prod and preview environments, but for multiple apps (on multiple *.deno.dev domains). Right now they override each other.