Example Pipelines
Let's take a simple example of a typical pipeline. For every merge to the master branch of your GitRepo, you need to:
- Build a Docker image
- Push it to a Docker registry
- Deploy it to a Kubernetes development environment
- Run tests against the deployed app and send a notification of the result
Single step approach
Technically, you can bundle all these steps into one Bash step. Your pipeline diagram will be a single step, triggered by a change to your GitRepo resource:
The approach above has the following characteristics:
- There is no discrete status. If this step fails, at a glance you cannot tell if build, deployment, or functional tests failed.
- The entire pipeline runs as one unit, so there is no way to separate out parts for special treatment. For example, you cannot run the functional test suite on a node with a custom runtime with supporting components.
Multiple steps approach
Let's look at an alternative approach to the same pipeline using a combination of native steps and Bash steps:
As you can see, the pipeline has a much more discrete structure and each step can send its status notifications.
You can also run the "run tests" step on a node with a custom runtime, or even split it up into parallel steps if needed.
This is the recommended approach to define steps that are sufficiently discrete to be able to perform interim actions such as identify status, send notifications, and evaluate results.