Getting started
Guides and examples
Reference documentation
Background concepts
Frequently Asked Questions
Integrations
Parallel Deployments
By default, Release deploys charts, services, and jobs serially. This is good if B depends on A and C depends on B. But this default serial process can also be very slow: even a series of 30 second deployments can add up to several minutes if executed serially. Hence, we allow for a workflow to be broken up into steps and each step can run tasks in parallel. Let's see how that works.
Steps
Steps run sequentially, because you might want to setup your prerequisites first, then deploy some dependent services or databases, then run some more jobs and services after that. The steps break your workflow into serial dependent steps, just like the default workflows.
Tasks
Tasks are grouped together under steps and each step can run in parallel as long as there are no interdependencies between tasks in a step.
Errors
Errors are typically ignored during tasks because Kubernetes can automatically restart and keep trying until a service succeeds. As an example, if you mistakenly run service B before service A that it depends on, service B may fail to start. However, Kubernetes will retry service B again and if service A is now functioning, then service B will start properly. This may not be the behaviour you want, however. For example, a critical job in a task might be critical to some further dependency in the tasks or steps, and you might want the whole chain to fail as soon as a failure is detected. In that case, you can use the
halt_on_error: true key to stop the stage and abort the deployment. Any successful services or jobs started in a previous step or task will still be running or have run, though, so think carefully about how you want to clean up on the next run.Waiting
You may not want to wait for a
task to succeed completely before moving on. This might be the case where a frontend takes a long time to deploy and has no particular dependencies in the steps as long as it finishes within a reasonable time. In that case, you can start the task in an earlier step and use the wait_for_finish: false key to let it run in parallel with the other steps.A Diagram to Look at
You can visualise the following workflow definition as follows:
1
workflows:
2
- name: setup
3
parallelize:
4
- step: frontend
5
tasks: [services.frontend]
6
wait_for_finish: false
7
- step: migrate
8
tasks: [jobs.migrate, jobs.scrub]
9
halt_on_error: true
10
- step: backend
11
tasks: [services.backend]
Copied!
Copy link