From e54c8210ca350f52b2f0f853affad867d2285ed0 Mon Sep 17 00:00:00 2001 From: Jonathan Norris Date: Tue, 18 Jun 2024 17:08:50 -0400 Subject: [PATCH 1/4] chore: update ws and braces deps (#705) --- yarn.lock | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/yarn.lock b/yarn.lock index a89fb264..72f36f24 100644 --- a/yarn.lock +++ b/yarn.lock @@ -5530,11 +5530,11 @@ __metadata: linkType: hard "braces@npm:^3.0.2, braces@npm:~3.0.2": - version: 3.0.2 - resolution: "braces@npm:3.0.2" + version: 3.0.3 + resolution: "braces@npm:3.0.3" dependencies: - fill-range: "npm:^7.0.1" - checksum: 10/966b1fb48d193b9d155f810e5efd1790962f2c4e0829f8440b8ad236ba009222c501f70185ef732fef17a4c490bb33a03b90dab0631feafbdf447da91e8165b1 + fill-range: "npm:^7.1.1" + checksum: 10/fad11a0d4697a27162840b02b1fad249c1683cbc510cd5bf1a471f2f8085c046d41094308c577a50a03a579dd99d5a6b3724c4b5e8b14df2c4443844cfcda2c6 languageName: node linkType: hard @@ -7976,12 +7976,12 @@ __metadata: languageName: node linkType: hard -"fill-range@npm:^7.0.1": - version: 7.0.1 - resolution: "fill-range@npm:7.0.1" +"fill-range@npm:^7.1.1": + version: 7.1.1 + resolution: "fill-range@npm:7.1.1" dependencies: to-regex-range: "npm:^5.0.1" - checksum: 10/e260f7592fd196b4421504d3597cc76f4a1ca7a9488260d533b611fc3cefd61e9a9be1417cb82d3b01ad9f9c0ff2dbf258e1026d2445e26b0cf5148ff4250429 + checksum: 10/a7095cb39e5bc32fada2aa7c7249d3f6b01bd1ce461a61b0adabacccabd9198500c6fb1f68a7c851a657e273fce2233ba869638897f3d7ed2e87a2d89b4436ea languageName: node linkType: hard @@ -16132,8 +16132,8 @@ __metadata: linkType: hard "ws@npm:^7.3.1": - version: 7.5.9 - resolution: "ws@npm:7.5.9" + version: 7.5.10 + resolution: "ws@npm:7.5.10" peerDependencies: bufferutil: ^4.0.1 utf-8-validate: ^5.0.2 @@ -16142,13 +16142,13 @@ __metadata: optional: true utf-8-validate: optional: true - checksum: 10/171e35012934bd8788150a7f46f963e50bac43a4dc524ee714c20f258693ac4d3ba2abadb00838fdac42a47af9e958c7ae7e6f4bc56db047ba897b8a2268cf7c + checksum: 10/9c796b84ba80ffc2c2adcdfc9c8e9a219ba99caa435c9a8d45f9ac593bba325563b3f83edc5eb067cc6d21b9a6bf2c930adf76dd40af5f58a5ca6859e81858f0 languageName: node linkType: hard "ws@npm:^8.13.0": - version: 8.17.0 - resolution: "ws@npm:8.17.0" + version: 8.17.1 + resolution: "ws@npm:8.17.1" peerDependencies: bufferutil: ^4.0.1 utf-8-validate: ">=5.0.2" @@ -16157,7 +16157,7 @@ __metadata: optional: true utf-8-validate: optional: true - checksum: 10/5e1dcb0ae70c6e2f158f5b446e0a72a2cd335b07aba73ee1872e9bae1285382286a10e53ed479db21bdd690a5dfd05641a768611ebb236253c62fefa43ef58b4 + checksum: 10/4264ae92c0b3e59c7e309001e93079b26937aab181835fb7af79f906b22cd33b6196d96556dafb4e985742dd401e99139572242e9847661fdbc96556b9e6902d languageName: node linkType: hard From 6a01a3db73e5092e9417df6c8e3abae618b7d441 Mon Sep 17 00:00:00 2001 From: DevCycle Automation <33425951+taplytics-robot@users.noreply.github.com> Date: Wed, 26 Jun 2024 13:59:25 -0400 Subject: [PATCH 2/4] Update CLI version to v5.14.13 (#706) --- docusaurus.config.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docusaurus.config.js b/docusaurus.config.js index 34028ca3..e9102acf 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -49,7 +49,7 @@ const YouTubeTransformer = { * Pinned version of the CLI to use for docs * When bumping the version, add any new commands to the documents array */ -const DVC_CLI_VERSION = 'v5.14.12' // auto updated by dvc cli release workflow +const DVC_CLI_VERSION = 'v5.14.13' // auto updated by dvc cli release workflow const VSCODE_EXTENSION_VERSION = 'v1.4.10' // auto updated by extension release workflow From 6b2660ef3cfffca8c7b810c9e20c28921aef154b Mon Sep 17 00:00:00 2001 From: Kate MacFarlane Date: Fri, 28 Jun 2024 15:24:47 -0400 Subject: [PATCH 3/4] Updating Location of Experimentation Docs + small Debugger Edit (#708) * Updating Location of Experimentation Docs + small Debugger Edit - moved Feature Experimentation docs page under Essentials section - added a clarification on what properties can be updated via debugger * Updated links updated links to map to new page location for experimentation * Missed one link * (actual) last link update --- docs/best-practices/engineering-led-experiments.md | 4 ++-- docs/best-practices/feature-grouping.md | 2 +- docs/best-practices/product-led-experimentation.md | 2 +- .../feature-experimentation.md | 14 +++++++------- .../metrics/creating-and-managing-metrics.md | 6 +++--- docs/extras/web-debugger.mdx | 2 +- 6 files changed, 15 insertions(+), 15 deletions(-) rename docs/{extras/metrics => essentials}/feature-experimentation.md (99%) diff --git a/docs/best-practices/engineering-led-experiments.md b/docs/best-practices/engineering-led-experiments.md index 3d8835cb..eb372a9f 100644 --- a/docs/best-practices/engineering-led-experiments.md +++ b/docs/best-practices/engineering-led-experiments.md @@ -16,7 +16,7 @@ To complete this guide, you may want to review the following topics: - [Creating and Managing Variations](/essentials/variables) - [Random Distribution Targeting](/essentials/targeting) -- [Feature Experimentation](/extras/metrics/feature-experimentation) +- [Feature Experimentation](/essentials/feature-experimentation) - [Creating a Metric](/extras/metrics/creating-and-managing-metrics) and [Metric Types](/extras/metrics/creating-and-managing-metrics#types) ## Metrics in DevCycle @@ -116,7 +116,7 @@ Some of the simplest and most precise experiments are basic A/B tests comparing For more complex features you may compare more variations with several combinations of variable values. You would then randomly distribute the variations according to the number of variations you are including in the experiment. -For more information about comparing multiple variations in an experiment, refer to [Feature Experimentation](/extras/metrics/feature-experimentation#comparing-multiple-variations). +For more information about comparing multiple variations in an experiment, refer to [Feature Experimentation](/essentials/feature-experimentation#comparing-multiple-variations). ### Choosing Metrics diff --git a/docs/best-practices/feature-grouping.md b/docs/best-practices/feature-grouping.md index 6b16003c..f6cead11 100644 --- a/docs/best-practices/feature-grouping.md +++ b/docs/best-practices/feature-grouping.md @@ -10,7 +10,7 @@ This guide describes how to manage large amounts of feature flags with DevCycle. ## Why Group Flags? -Feature Flags can accumulate very quickly. Without an organizational mechanism, the feature management dashboard would be extremely cluttered. Imagine developing a complex feature with various parts, such as the [Metrics and Experimentation feature in DevCycle](/extras/metrics/feature-experimentation). Each piece of functionality needs a flag: There’s a flag for the API, the UI, each type of experimentation, string flags for naming, and so on. It would be helpful to have the ability to find all these flags in the same place. +Feature Flags can accumulate very quickly. Without an organizational mechanism, the feature management dashboard would be extremely cluttered. Imagine developing a complex feature with various parts, such as the [Metrics and Experimentation feature in DevCycle](/essentials/feature-experimentation). Each piece of functionality needs a flag: There’s a flag for the API, the UI, each type of experimentation, string flags for naming, and so on. It would be helpful to have the ability to find all these flags in the same place. Not only do we want flags for each part of a feature, but we also want the ability to turn off the entire feature, all at once, in case something goes wrong. Other Feature Flag management solutions require you to create complex feature flag dependencies to set up a “master switch” for a group of flags. In contrast, DevCycle allows you to easily group feature flags and disable them simultaneously with one switch. diff --git a/docs/best-practices/product-led-experimentation.md b/docs/best-practices/product-led-experimentation.md index 01b19c94..399fd6a8 100644 --- a/docs/best-practices/product-led-experimentation.md +++ b/docs/best-practices/product-led-experimentation.md @@ -19,7 +19,7 @@ To complete this guide, you may want to review the following topics: - [DevCycle Feature Hierarchy](/introduction/core-concepts/feature-hierarchy) - [Creating and Managing Variations](/essentials/variables) - [Random Distribution Targeting](/essentials/targeting) -- [Feature Experimentation](/extras/metrics/feature-experimentation) +- [Feature Experimentation](/essentials/feature-experimentation) - [Creating a Metric](/extras/metrics/creating-and-managing-metrics) and [Metric Types](/extras/metrics/creating-and-managing-metrics#types) ## Conducting Experiments: A Collaborative Approach diff --git a/docs/extras/metrics/feature-experimentation.md b/docs/essentials/feature-experimentation.md similarity index 99% rename from docs/extras/metrics/feature-experimentation.md rename to docs/essentials/feature-experimentation.md index bed633be..620c0de7 100644 --- a/docs/extras/metrics/feature-experimentation.md +++ b/docs/essentials/feature-experimentation.md @@ -1,14 +1,8 @@ --- title: Feature Experimentation -sidebar_position: 3 +sidebar_position: 10 --- -:::info -Experimentation relies on custom events. - -Experimentation is available to all customers on any plan. However, to perform experiments, events must be sent to DevCycle to calculate metrics. These events are added to your existing plan. To learn more, read about our pricing, or contact us. -::: - ## Overview At DevCycle we believe that experimentation should be a part of the natural lifecycle of all features. So no matter the [feature type](/essentials/features) selected, can be experimented on. Experiments can be as simple as comparing any target audiences against a metric, or can be fully [randomized](/essentials/targeting#serving-a-random-variation-experimentation--random-distribution) A/B tests using statistical methodologies. @@ -49,6 +43,12 @@ To set this up, create a targeting rule in Production that delivers to All Users ## Adding Metrics to Your Feature +:::info +Experimentation relies on custom events. + +Experimentation is available to all customers on any plan. However, to perform experiments, events must be sent to DevCycle to calculate metrics. These events are added to your existing plan. To learn more, read about our pricing, or contact us. +::: + Now that you have two segments receiving different experiences, the only other thing you need to run an experiment is a metric to evaluate the comparative performance of those experiences. To add a metric to your feature, click “Comparative Analysis” under the “Data & Results” section on the sidebar of the feature editing page. Click the “Choose a Metric” dropdown. This will bring up the option to add a metric that has already been created in the project or to create a new one. diff --git a/docs/extras/metrics/creating-and-managing-metrics.md b/docs/extras/metrics/creating-and-managing-metrics.md index fe2b6723..67957983 100644 --- a/docs/extras/metrics/creating-and-managing-metrics.md +++ b/docs/extras/metrics/creating-and-managing-metrics.md @@ -94,7 +94,7 @@ To run a test, the following fields must be set: **Feature** - This is the specific feature this Metric should be applied to. Any event that has been sent since the creation of this Metric from a user receiving any variation of this feature will be part of this Metric. In the event that an error is shown, this means the event has not been seen from this feature yet. -**Control** - After selecting a Feature, a "control" variation must be selected. This is what will be used to show a comparative analysis against all other variations in a feature. Typically, an "off" or "Baseline" variation would act as the control. For more information on this, please refer to the [Feature Experimentation documentation](/extras/metrics/feature-experimentation). +**Control** - After selecting a Feature, a "control" variation must be selected. This is what will be used to show a comparative analysis against all other variations in a feature. Typically, an "off" or "Baseline" variation would act as the control. For more information on this, please refer to the [Feature Experimentation documentation](/essentials/feature-experimentation). **Date Range** - This range will default from the moment the Metric (or feature) was created, to now within 30 days. If 30 days have passed since the creation of the Metric or feature, the date range must be a 30 day range. @@ -132,7 +132,7 @@ Here are some steps you can follow to track metrics within a feature: While the setup has some default values, the Metric requires the following fields to be filled: - - **Control** - This is what will be used to show a comparative analysis against all other variations in a feature. Typically, an "off" or "Baseline" variation would act as the control. For more information on this, please refer to the [Feature Experimentation documentation](/extras/metrics/feature-experimentation). + - **Control** - This is what will be used to show a comparative analysis against all other variations in a feature. Typically, an "off" or "Baseline" variation would act as the control. For more information on this, please refer to the [Feature Experimentation documentation](/essentials/feature-experimentation). - **Date Range** - This range will default from the moment the Metric (or feature) was created, to now within 30 days. If 30 days have passed since the creation of the Metric or feature, the date range must be a 30 day range. @@ -158,4 +158,4 @@ To read more on the queries behind the Metrics, see [How Metrics Are Calculated] With Metrics on a feature, experimentation can be easily executed on any Feature. At DevCycle we believe that experimentation should be a part of the natural lifecycle of all features. So no matter the [feature type](/essentials/features) selected, experimentation will always be available for use. -To learn more on how to run experiments with DevCycle, read [Feature Experimentation](/extras/metrics/feature-experimentation) +To learn more on how to run experiments with DevCycle, read [Feature Experimentation](/essentials/feature-experimentation) diff --git a/docs/extras/web-debugger.mdx b/docs/extras/web-debugger.mdx index 6454eb58..3997e9c1 100644 --- a/docs/extras/web-debugger.mdx +++ b/docs/extras/web-debugger.mdx @@ -125,7 +125,7 @@ Once set, you can now view and modify your Overrides for any Feature in your pro In the "Live Configuration" section, you'll find a list of the Features and Variations that you are currently being served by DevCycle on this page. Each row can be clicked to expand and see the set of Variables and their values which are associated with that Feature and Variation. -At the top of this section you can also see the current user data that you've been identified with on this page, and modify any property. +At the top of this section you can also see the current user data that you've been identified with on this page, and modify User ID or Email and/or any custom property. Applying changes to that data will trigger the SDK's `identify` function and trigger a new configuration to be retrieved from DevCycle. ### Events From 964f23868888724c86893878998c1a104b2e83aa Mon Sep 17 00:00:00 2001 From: Jamie Sinn Date: Tue, 2 Jul 2024 11:09:48 -0400 Subject: [PATCH 4/4] SSE Beta Docs (#707) * SSE Beta Docs Also bump to node20 * Don't update node yet * Update docs/sdk/server-side-sdks/go/go-usage.md Co-authored-by: Adam Wootton * Update order --------- Co-authored-by: Adam Wootton --- .../server-side-sdks/go/go-gettingstarted.md | 9 ++++---- docs/sdk/server-side-sdks/go/go-usage.md | 21 +++++++++++++++++++ .../node/node-gettingstarted.md | 3 ++- docs/sdk/server-side-sdks/node/node-usage.md | 20 ++++++++++++++++++ 4 files changed, 48 insertions(+), 5 deletions(-) diff --git a/docs/sdk/server-side-sdks/go/go-gettingstarted.md b/docs/sdk/server-side-sdks/go/go-gettingstarted.md index 32ef85c2..611f6050 100644 --- a/docs/sdk/server-side-sdks/go/go-gettingstarted.md +++ b/docs/sdk/server-side-sdks/go/go-gettingstarted.md @@ -52,13 +52,13 @@ initialize for any reason- it'll return as an error here. ## Async Initialization -Additionally, local bucketing mode supports an optional `OnInitializedChannel` parameter which will tell the sdk to run the initialization -process in a separate go routine. When the channel receives a message, you will know the initialization process is complete. +Additionally, local bucketing mode supports an optional `ClientEventHandler` parameter which will tell the sdk to run the initialization +process in a separate go routine. This can be useful if you want to wait for the client to be fully initialized before proceeding. ```go -onInitializedChannel := make(chan bool) +onInitializedChannel := make(chan api.ClientEvent) options := devcycle.Options{ - OnInitializedChannel: onInitializedChannel, + ClientEventHandler: onInitializedChannel, // other options omitted for this example } @@ -73,3 +73,4 @@ log.Println("DevCycle client not guaranteed to be initialized yet") <-onInitializedChannel log.Println("Devcycle client initialized") ``` + diff --git a/docs/sdk/server-side-sdks/go/go-usage.md b/docs/sdk/server-side-sdks/go/go-usage.md index aee40471..1ca24870 100644 --- a/docs/sdk/server-side-sdks/go/go-usage.md +++ b/docs/sdk/server-side-sdks/go/go-usage.md @@ -144,3 +144,24 @@ making bucketing decisions. In this example, the `Variable` call would make an API request and send along the user data specified by the call. That data would be used in combination with EdgeDB data to make correct bucketing decisions before returning the variable's value. + + +## Enabling Beta Realtime Updates +:::warning +This feature is in beta, and may not function as expected. Please ensure that you have the latest version of the SDK. +::: + +This functionality will reduce the number of polling requests that are made to the DevCycle Config CDN, and instead will +use a long-lived HTTP connection (Server Sent Events) to receive updates when there is a new config available. +This reduces outbound network traffic, as well as optimizes the SDK for efficiency. + +To enable Beta Realtime Updates, pass in the `EnableBetaRealtimeUpdates` option to the SDK initialization: +```go +options := devcycle.Options{ + EnableBetaRealtimeUpdates: true, + // other options omitted for this example +} + +devcycleClient, err := devcycle.NewClient(sdkKey, &options) +``` + diff --git a/docs/sdk/server-side-sdks/node/node-gettingstarted.md b/docs/sdk/server-side-sdks/node/node-gettingstarted.md index 8f50e341..51644797 100644 --- a/docs/sdk/server-side-sdks/node/node-gettingstarted.md +++ b/docs/sdk/server-side-sdks/node/node-gettingstarted.md @@ -52,7 +52,7 @@ const devcycleClient = await DevCycle.initializeDevCycle( ``` | DevCycle Option | Type | Description | -| ---------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +|------------------------------|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | logger | DevCycleLogger | Logger override to replace default logger | | logLevel | String | Set log level of the default logger. Options are: `debug`, `info`, `warn`, `error`. Defaults to `info`. | | enableCloudBucketing | Boolean | Switches the SDK to use Cloud Bucketing (via the DevCycle Bucketing API) instead of Local Bucketing. | @@ -65,3 +65,4 @@ const devcycleClient = await DevCycle.initializeDevCycle( | flushEventQueueSize | Number | Controls the maximum size the event queue can grow to until a flush is forced. Defaults to `1000`. | | maxEventQueueSize | Number | Controls the maximum size the event queue can grow to until events are dropped. Defaults to `2000`. | | apiProxyURL | String | Allows the SDK to communicate with a proxy of DevCycle bucketing API / client SDK API. | +| enableBetaRealtimeUpdates | Boolean | Enables the usage of Beta Realtime Updates for DevCycle. This feature is currently in beta. | \ No newline at end of file diff --git a/docs/sdk/server-side-sdks/node/node-usage.md b/docs/sdk/server-side-sdks/node/node-usage.md index ed0601fb..cc1dac3f 100644 --- a/docs/sdk/server-side-sdks/node/node-usage.md +++ b/docs/sdk/server-side-sdks/node/node-usage.md @@ -142,6 +142,26 @@ This will send a request to our EdgeDB API to save the custom data under the use In the example, Email and Country are associated to the user `test_user`. In your next variable call for the same `user_id`, you may omit any of the data you've sent already as it will be pulled from the EdgeDB storage when segmenting to experiments and features. +## Enabling Beta Realtime Updates +:::warning +This feature is in beta, and may not function as expected. Please ensure that you have the latest version of the SDK. +::: + +This functionality will reduce the number of polling requests that are made to the DevCycle Config CDN, and instead will +use a long-lived HTTP connection (Server Sent Events) to receive updates when there is a new config available. +This reduces outbound network traffic, as well as optimizes the SDK for efficiency. + +To enable Beta Realtime Updates, pass in the `enableBetaRealtimeUpdates` option to the SDK initialization: +```javascript +const devcycleClient = DevCycle.initializeDevCycle( + '', + { + enableBetaRealtimeUpdates: true, + }, +) +``` + + ## Close Client If you need to close the DevCycleClient object to stop all open connections and timers, call `devcycleClient.close()`.