Reduce interdependencies between builds, environments and deployments
Description
Interdependencies between pipeline, builds, environments and deployments are really tricky now.
Because we do not have ReviewApp
class, review app is an implicit concept reflected by associations between builds, environments and deployments.
Review app exists for given branch when:
- environment object exists with name
staging
- environment is associated with deployment
- deployment is the latest one
- deployment has a
ref
set for given branch - deployment has a
deployable
associated, which is usuallyCi::Build
- deployment has an environment associated
The things are getting more tricky when we have manual deployments:
- deployments needs to have manual actions associated
- manual actions are defined in
deployable
that created deployment - deployable inspects pipeline to see different builds with
when: manual
- environment depends on manual actions
- if there are other manual builds associated with
deployable
and have different name thandeployable.name
these are considered manual actions for environment.
And now we can have environments with a teardown job defined:
- environment reaches deployable through last deployment to check manual actions
- environment has a stop job defined, which references manual action by name, not relation
- build also has many deployments, and last deployment, and we use that in the UI extensively
Least but not last, Ci::Build
is associated with environment by name, not by ActiveRecord
relation, which makes things even more difficult to understand.
This is not all, but because it is quite difficult to remember all rules related to intedependencies it requires careful inspection of codebase to describe all rules in this issue.
Proposal
It seems that we are missing some important domain class in the model. We should find it, and resolve problem with proliferating interdependencies between objects related to environments.