A pipeline rule is a rule that deploys changeset contents into an environment.
The pipeline rule is the core of a Job.
Tipically pipeline rules will revolve around the tasks necessary to change an environment:
So a pipeline rule should, at least, do one (if not all) of the previous activities.
The rule can also become the default for a given transition:
- Promote - Promotes a conceptually superior environment, for example from pre-production to production.
- Static - Used to redeploy changesets to the same environment they currently occupy.
- Demote - Demotes a conceptually inferior environment, for example from production (PROD) to pre-production (PREP).
When a pipeline rule is created, the 5 standard steps are preloaded. They are:
Control whether or not the job should be created in the first place.
CHECK step the job object not yet available.
There's no job id.
CHECK step fails, the job is not created and the user will get an
error message window, with the message thrown by the rule, in the web
INIT step is very similar to the
but the difference is that the job object is already
created in the system.
INIT step runs ops in user-time, so the user
will be waiting for the step to complete, just like
Throwing errors in the
INIT step will leave the job
Error state and it will not run. The
user will get an error message stating that
the job could not be started for the reason
stated in the
INIT step should be used for 2 main reasons:
when it's necessary that a failed job verification info is logged as part of the job log.
when we want the user to wait for confirmation that the job has been created.
Do not overload the
CHECK steps with
complex and potentially slow tasks. While both
steps run, the user is blocked out in the interface.
PRE step contains ops that will run immediately after
the job is created and the
INIT step is completed.
This is where activities that do not modify an environment should run, such as build, package or testing.
Do not put environment changing ops here, like deploying the app binaries or packages, or restarting servers.
PRE step to prepare everything that will be
needed by the
RUN step of the pipeline to deploy
This step contains the portion of the rule that will run at the scheduled time.
For pipelines that are not scheduled, the
RUN step may start immediately
PRE step. But if the job has been scheduled at a later time, then
the job will pause after the
PRE step has completed waiting for the schedule
time. This is shown in the monitor as the status
Ready of the step
POST step is where error control and final execution ops run.
POST activity may include:
- moving changesets and other topics to their desired status, like a
- sending email notifications to users
- updating repository branches with tags that indicate what commit corresponds to which environment.
POST step will always run. This includes the following:
- After a
- After a
- After a
RUNstep is successful