GCTC-NTGC / gc-digital-talent

GC Digital Talent is the new recruitment platform for digital and tech jobs in the Government of Canada. // Talents numériques du GC est la nouvelle plateforme de recrutement pour les emplois numériques et technologiques au gouvernement du Canada.
https://talent.canada.ca
GNU Affero General Public License v3.0
19 stars 8 forks source link

✨ Version snapshots #10913

Closed esizer closed 1 week ago

esizer commented 2 months ago

✨ Feature

Add some sort of versioning to our pool candidate snapshots to more easily handle legacy data.

🕵️ Details

Our snapshots are drifting pretty far as our schema changes and it is getting a little difficult to reason about that data in a snapshot is legacy and what we should expect it to contain. I think adding a version to these snapshots could make things much easier.

This way, we could indicate the version on places where the snapshot is rendered to at least make it a little more identifiable. Since recently we have had some items where bugs were reported due to missing or incorrect data in a snapshot actually being related to a legacy snapshot rather than an actual bug. With a version number, we could likely troubleshoot this quicker.

Also, with a version number, we can be more confident about what data each version should contain which should make rendering the actual information easier.

Rendering example

const snapshot = parseSnapshot(poolCandidate.profileSnapshot);
const { version } = snapshot;

if(version === 1) return <SnapshotV1 snapshot={snapshot} />;

type ProfileSnapshotV1 = { ...expectedFields };

interface SnapshotV1Props { 
  snapshot: ProfileSnapshotV1;
}

🙋‍♀️ Proposed Implementation

This depends on how we want to do it. We first need to decide if we want to attempt to retroactivley version older snapshots. If so, we would need to find each PR that modified the snapshot and likely write an artisan command to find snapshots created between deployments of said PRs and inject a version somewhere.

Or, we can just treat everything without a version unstable and use our current approach for that and only start versioning forward.

As for storing the version, I'd just add it as a property in the actual JSON of the snapshot and we can maintain a config value of the current version and somehow enforce someway for bumping it as needed? :thinking:

$SNAPSHOT_VERSION = 2;

$candidate->profile_snapshot = [ 'version' => $SNAPSHOT_VERSION, ....$snapshot];

✅ Acceptance Criteria

esizer commented 3 weeks ago

I have an idea for this using ValueObject as a cast for the snapshot so we can encapsulate it in a single cast. But to make it simpler we should wait on #11225

REF: https://laravel.com/docs/11.x/eloquent-mutators#anonymous-cast-classes