Phase Status Technical Workflows

Overview

The DCP Data Access Service (DAS) uses a synchronous state management system. This design choice was for the short-term and offers simplicity and speed-to-market. However, it also is much too tightly coupled and does not scale as well as an async state system. We describe this as synchronous because the one state handler is responsible for actioning the state to the next system. For example, the /approve callback is responsible for the logic needed to action to Starting. This unnecessarily blurs logic between states.

In the near future, after GA, when scale becomes an issue, we will make the state handling more asynchronous with queues and listenersthat listen for states. For example, the Starting listener will listen for items in an Approved State, and perform the logic needed to action to Starting. This allows us accomodate a state that takes longer by adding more listeners and scaling horizontally

Details

Note: when a phase begins by starting or approving, the parent Deployment is set to its "Started" state.

1. deployment phase created, state set to NEW
   1. in the future, we will raise a 'Created' event.
2. inititalize (set aproving or starting)
   1. evaluate any checks for the Phase's environment
   2. if pre-requisites are unmet for the Phase's environment, state is set to Approving. If all pre-requisites are approved or none exist, state is set to Starting.
   3. If the phase is kgstg or kprod, the phase will be scheduled, even if scheduledAt is current time (gusCaseAuto)
3. Approving
   1. submits approval workkflow (human, gus case, etc)
   2. waits for approval or rejection.
   3. Argo workflow creates case with Gus CLI and then calls back to DCP to set the case Id, risk, and scheduledAt
4. Approved
   1. workflow calls back to /approve route when the approval is approved or rejected
   2. if approved
      1. Approved event emitted
      2. immediately begin "starting step" or sets to startScheduled
      3. begin "starting step" logic if state is not startScheduled
   3. if approval is rejected,
      1. Cancel event emitted
      2. see Cancel logic below.
5. Starting
   1. if a gov env, check that the scheduledAt UTC time is after current UTC time, cancels phase if not.
   2. if state = starting, submits deploy workflow
   3. Starting or StartScheduled event emitted
6. StartScheduled
   1. when a gov phase, we may need to start the phase after the ScheduledAt time, so we can support release windows.
   2. periodically, we will query for phases in this state and start them when ready.
7. Started
   1. workflow calls back to say work is beginning
   2. Started event emitted
   3. Completed event emitted
8. Completed
9. workflow calls back to say work is successful
10. Completed event emitted
11. complete deploy set if all phases done
12. start next deployment phase
13. Failed
14. event emitted (handled)
15. fail deploy set if not already failed
16. Cancelled
17. cancel deploy set if not already cancelled
18. event emitted (? handled)

More Topics

• Phase Status
• Phase Approval