feat: Feature Versioning V2

[matthewelwell]

Changes

Adds logic for a 'version 2' of feature versioning. The way it behaves is such that every feature, environment combination has a relationship to a new EnvironmentFeatureVersion entity. This new entity includes a sha attribute, much like a commit in git. Using this, it is possible to show a history of a given feature and to roll back as needed.

Still TODO:

• Add parameter to automatically publish the version
  • This is actually not the desired behaviour. We are sticking to multiple endpoints for now.
• Update change requests logic so that a change request can point to multiple environment versions
  • To be done in a separate PR.
• Ensure that environment document rebuilds are triggered when a new version is published
• Add AuditLog records
  • For now, audit log records will not be written for changes to a feature version - since the feature history will suffice.
• Multivariate?
  • This needs discussion. The current logic in this PR matches that of the current change request logic.
• Exports?
• Webhooks
  • To be done in a separate PR

TODO:

• Open separate PRs for:
  • Webhooks
  • Change requests

How does it work?

Instead of directly making a change to a feature in a given environment, the expectation is that, when a first change is made, the FE makes a request to create a new version. It can include the initial change in the request to create the version so that it saves the change set as a 'draft'. Users* can then add further changes to the version (e.g. segment overrides) as they please. Once they're happy with the changes, they can publish it (TODO: handle change requests).

By using this workflow, all users can then see a version history of a feature in a given environment. They can also trivially roll back to a previous version as needed.

My current expectation is that users will also be able to add multiple unpublished versions to a change request.

Current thinking is that this behaviour will be 'opt-in' for existing environments but default for new environments. This is so that we have a trigger for creating the initial version. This will need to be changed in the future so that new environments are defaulted to version 2, however, I imagine this will also require a substantial change to a lot of our tests.

Front-end Integration

These changes are currently restricted to environments which have use_v2_feature_versioning: true - this can be set with a PUT / PATCH request to the environment detail endpoint.

The expectation is that the frontend will hit the following endpoints now to make a change to a flag.

POST /api/v1/environments/:id/features/:id/versions

This will return a sha attribute and will ensure that all of the feature states from the previous version are transferred to the new version. To make a change to a given feature state, or to add a new segment override, the FE will need to make requests such as

POST /api/v1/environments/:id/features/:id/versions/:sha/feature-states/
PUT /api/v1/environments/:id/features/:id/versions/:sha/feature-states/:id/

Once the changes are complete, the FE will need to hit the following endpoint to publish the change:

POST /api/v1/environments/:id/features/:id/versions/:sha/publish/

This endpoint does take an optional live_from parameter, but this will need more work to ensure that the current scheduling UI ties in correctly.

Considerations:

1. Can we create an endpoint that takes the new state and value for an environment default and automatically creates and publishes a version (to simplify the simple workflow)
2. Should we have an endpoint like: GET /api/v1/environments/:id/features/:id/versions/latest/

How did you test this code?

Added one long integration test and updated existing tests where necessary.

TODO:

• Test with Multivariate
• Test with identity overrides
• Test with multiple segment overrides

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 21, 2023 11:50am
flagsmith-frontend-preview	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 21, 2023 11:50am
flagsmith-frontend-staging	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 21, 2023 11:50am

[matthewelwell]

This is due to the addition of the get_object_or_404 function call here: https://github.com/Flagsmith/flagsmith/pull/2382/files#diff-9e42c40eece4b1da492acaad6b58480687eab073351781b6a0fec0a91435df9aR543

This was necessary to simplify the code in the versioning module.

[github-actions]

Uffizzi Preview deployment-33803 was deleted.