Centralize the production checks logic
Throughout the coordinated pipeline, several jobs execute rake tasks that call different classes that later execute the production checks, I believe this has caused some technical debt. Currently, we have the following paths:
job | rake task | class |
ProductionStatus check |
---|---|---|---|
baking_time |
baking_time |
AutoDeploy::BakingTime.new.execute |
CanaryUp |
promote |
promotion_checks |
AutoDeploy::PromotionChecks.new.execute |
CanaryUp and ActiveDeployment
|
production_checks |
gprd_guard |
AutoDeploy::CheckProduction.new.execute that calls manager.authorize
|
ActiveDeployment |
/chatops run auto_deploy blockers |
auto_deploy:check_production |
ProductionCheck::Chatops.new.execute |
CanaryUp and/or ActiveDeployments
|
I believe all the jobs, should use the same class and perhaps even the same rake task. Some reasons why I think we should refactor this:
- It's difficult to reason all these paths, if we require to add a new production check, should we create another class that calls
ProductionStatus
or just re-use one of the paths? -
ProductionStatus
performs anActiveIncident
check by default, so it shouldn't be necessary to add it as an extra check. - I don't see any strong reason why the additional checks (
CanaryUp
andActiveIncidents
) differ amongst classes. All the jobs should check if canary is up. - Having all these extra classes imply more code maintenance and extra specs.
Proposal
Let's have a single class that verifies the production checks, ideally this class should be called by the different rake tasks.