Concurrent deployments to reduce deploy times.

[erikkrieg]

Is your feature request related to a problem?
Many of our projects using DevSpace spin up deployments that are not dependent on each other that we would like to deploy concurrently, like how images are built, to reduce deploy times.

For example, we may have an project with the following deployments:

• postgres (using helm)
• redis (using helm)
• server (using helm)

In such a case, the postgres and redis deployments do not have any dependency on another deployment, while the server relies on both the cache and database. We have projects with 3x more independent deployments than in this example and would like to have the option to concurrently apply select deployments.

Which solution do you suggest?

A colleague (@kuuji ) and I were hoping to make a contribution to the project to allow deployments to be applied concurrently following the example set by concurrent image builds with some differences.

The main difference is that we think there is value in specifying which deployments can be applied concurrently and another is that concurrency should be disabled by default to in order to maintain backwards compatibility.

For enabling concurrency on a deployment, we are suggesting an additional boolean on deployments like this:

deployments:
- name: postgres
  helm: { ... }
  concurrency: true
- name: redis
  helm: { ... }
  concurrency: true
- name: server
  helm: { ... }
  concurrency: false # could be omitted as we suggest this value be false by default.

Which alternative solutions exist?
Since we are using helm for everything we could create a custom umbrella chart that wraps all our deployments that can be deployed concurrently and have that as the first DevSpace deployment in the list so that it is applied first. But this approach shifts more complexity to the user and supporting it feels in line with DevSpace's goal of "develop[ing] and deploy[ing] cloud-native software faster".

Additional context
We are excited to work on this and would really appreciate feedback. Can't promise we won't get started testing something out before that, tho :P

/kind feature

[FabianKramm]

@erikkrieg thanks for creating this issue! Sounds great, if you want to give it a shot, we are happy to review your PR! Yes introducing a new concurrency option is a good idea which also prevents a breaking change.