Add ADR 002 which partially pivots on ADR 001 #382
Conversation
|
|
||
| This partially reverses the approach outlined in [ADR 001](001-porting-to-postgresql.md). We were going to piggy back on work by the Publishing Team who are building a proxy app to split requests between old and new router/router-api and content-store. However they've hit several issues and can't get it working. | ||
|
|
||
| On recommendation from the Tech Lead of the Platform Engineering team we are going to just use feature flags to manage the roll out. |
There was a problem hiding this comment.
Can you expand a bit on the feature flag approach please? Also, a brief outline on the rollout plan would be handy, if possible. It feels like there's a bit of extra context here that would be useful to get out of your head soon
There was a problem hiding this comment.
@sihugh can you check that the expansion on feature flagging is ok?
There was a problem hiding this comment.
@sihugh @chao-xian So after discussing with @sengi it seems the feature flag is just unneeded complication.
Because Router doesn't hold any data whatsoever, simply reads from what is available, there isn't any need to have a separate live version of it ready to go.
For simplicity, we came to the conclusion that assuming that the separate postgres version of router-api is running in the background already, and is fully up to date (as in, all changes before it went "live" are synced, plus anything new after the fact), then there is no reason for Router to not just be delivered as normal.
It's a big change but also not a change that cares about what environment it's running on - so if we get it delivered and comfortable on Staging for a while to ensure it's fully working, we can just up it to production with minimal fuss.
There was a problem hiding this comment.
OK I'm going to close this, and simply open a PR to update the previous ADR to "rejected" status instead, referencing this as part of the trail.
|
Let's do this instead: #395 |
No description provided.