Migrations

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the MigrationVariation method to evaluate your feature flag and determine its migration stage. This method returns the migration stage and a tracker that you can use to build the analytics event to send back to LaunchDarkly.

Here’s how:

1
LDContext context = Context.Builder("example-context-key")
2
    .Build();
3
4
var (stage, tracker) = client.MigrationVariation("example-migration-flag-key", context, MigrationStage.Off);

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
// define the combination of reads and writes from the new and old systems
2
// that should occur at each migration stage
3
4
switch (stage)
5
    {
6
        case MigrationStage.Off:
7
        case MigrationStage.DualWrite:
8
        case MigrationStage.Shadow:
9
        case MigrationStage.Live:
10
        case MigrationStage.RampDown:
11
        case MigrationStage.Complete:
12
        default:
13
            // throw an error
14
    }

Finally, when the migration operation is complete, call the TrackMigration method to record your metrics:

1
client.TrackMigration(tracker);

To learn more, read IMigration, MigrationVariation, and TrackMigration.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the MigrationVariation method to evaluate your feature flag and determine its migration stage. This method returns the migration stage, a tracker that you can use to build the analytics event to send back to LaunchDarkly, and an error.

Here’s how:

1
context := ldcontext.New("example-context-key")
2
scopedClient := ld.NewScopedClient(client, context)
3
// LDScopedClient is in beta and may change without notice.
4
5
stage, tracker, err := scopedClient.MigrationVariation("example-migration-flag-key", ldmigration.Off)

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
// define the combination of reads and writes from the new and old systems
2
// that should occur at each migration stage
3
4
switch stage {
5
  case ldmigration.Off:
6
  case ldmigration.DualWrite:
7
  case ldmigration.Shadow:
8
  case ldmigration.Live:
9
  case ldmigration.RampDown:
10
  case ldmigration.Complete:
11
  default: {
12
    // throw an error
13
  }
14
}

Finally, when the migration operation is complete, call the TrackMigrationOp method to record your metrics:

1
event, _ := tracker.Build();
2
3
err := scopedClient.TrackMigrationOp(*event);
4
// LDScopedClient is in beta and may change without notice.

To learn more, read Migration and TrackMigrationOp.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migrationVariation method to evaluate your feature flag and determine its migration stage. This method returns the migration stage, a tracker that you can use to build the analytics event to send back to LaunchDarkly, and an error.

Here’s how:

1
LDContext context = LDContext.builder("example-context-key")
2
  .build();
3
4
MigrationVariation migrationVariation = client.migrationVariation("example-migration-flag-key", context, MigrationStage.OFF);

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
// define the combination of reads and writes from the new and old systems
2
// that should occur at each migration stage
3
4
switch (migrationVariation.getStage()) {
5
  case OFF:
6
  case DUAL_WRITE:
7
  case SHADOW:
8
  case LIVE:
9
  case RAMP_DOWN:
10
  case COMPLETE:
11
  default: {
12
    // throw an error
13
  }
14
}

Finally, when the migration operation is complete, call the trackMigration method to record your metrics:

1
MigrationOpTracker tracker = migrationVariation.getTracker();
2
3
client.trackMigration(tracker);

To learn more, read migrationVariation and trackMigration.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migrationVariation method to evaluate your feature flag and determine its migration stage. This method returns a promise that is resolved with the result LDMigrationVariation. This result includes the migration stage and a tracker that you can use to build the analytics event to send back to LaunchDarkly.

Here’s how:

1
  import { LDContext } from '@launchdarkly/node-server-sdk');
2
3
  const context: LDContext = {
4
     kind: 'user',
5
     key: 'example-user-key',
6
     name: 'Sandy',
7
  };
8
9
  const { value, tracker } = await client.migrationVariation(
10
    'example-migration-flag-key',
11
    context,
12
    false
13
  );

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
// define the combination of reads and writes from the new and old systems
2
// that should occur at each migration stage
3
4
switch (value) {
5
  case LDMigrationStage.Off: { },
6
  case LDMigrationStage.DualWrite: { },
7
  case LDMigrationStage.Shadow: { },
8
  case LDMigrationStage.Live: { },
9
  case LDMigrationStage.RampDown: { },
10
  case LDMigrationStage.Complete: { },
11
  default: {
12
    // throw an error
13
  }
14
}

Finally, when the migration operation is complete, call the trackMigration method to record your metrics:

1
const event = tracker.createEvent();
2
3
if (event) {
4
  client.trackMigration(event);
5
}

To learn more, read LDMigration. and LDMigrationOpEvent.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migrationVariation method to evaluate your feature flag and determine its migration stage. This method returns the migration stage and a tracker that you can use to build the analytics event to send back to LaunchDarkly.

Here’s how:

1
$context = LaunchDarkly\LDContext::builder("example-context-key")->build();
2
3
$result = $client->migrationVariation('example-migration-flag-key', $context, Migrations\Stage::OFF);
4
5
/** @var Migrations\Stage */
6
$stage = $result['stage'];
7
/** @var Migrations\OpTracker */
8
$tracker = $result['tracker'];

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
// define the combination of reads and writes from the new and old systems
2
// that should occur at each migration stage
3
4
switch ($stage) {
5
  case Migrations\Stage::OFF:
6
  case Migrations\Stage::DUALWRITE:
7
  case Migrations\Stage::SHADOW:
8
  case Migrations\Stage::LIVE:
9
  case Migrations\Stage::RAMPDOWN:
10
  case Migrations\Stage::COMPLETE:
11
  default:
12
    // throw an error
13
}

Finally, when the migration operation is complete, call the trackMigrationOperation method to record your metrics:

1
$client->trackMigrationOperation($tracker);

To learn more, read Migrator and trackMigrationOperation.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migration_variation method to evaluate your feature flag and determine its migration stage. This method returns the migration stage and a tracker that you can use to build the analytics event to send back to LaunchDarkly.

Here’s how:

1
context = Context.builder("example-context-key").build()
2
3
stage, tracker = ldclient.get().migration_variation('example-migration-flag-key', context, Stage.OFF)

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
# define the combination of reads and writes from the new and old systems
2
# that should occur at each migration stage
3
4
if stage == Stage.OFF:
5
elif stage == Stage.DUALWRITE:
6
elif stage == Stage.SHADOW:
7
elif stage == Stage.LIVE:
8
elif stage == Stage.RAMPDOWN:
9
elif stage == Stage.COMPLETE:
10
else:
11
  # throw an error

Finally, when the migration operation is complete, call the track_migration_op method to record your metrics:

1
ldclient.get().track_migration_op(tracker)

To learn more, read ldclient.migrations and track_migration_op.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migration_variation method to evaluate your feature flag and determine its migration stage. This method returns the migration stage and a tracker that you can use to build the analytics event to send back to LaunchDarkly.

Here’s how:

1
context = LaunchDarkly::LDContext.create({key: "example-user-key", kind:"user"})
2
3
stage, tracker = client.migration_variation(
4
  "example-migration-flag-key",
5
  context,
6
  LaunchDarkly::Migrations::STAGE_OFF
7
)

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
# define the combination of reads and writes from the new and old systems
2
# that should occur at each migration stage
3
4
case stage
5
when LaunchDarkly::Migrations::STAGE_OFF
6
when LaunchDarkly::Migrations::STAGE_DUALWRITE
7
when LaunchDarkly::Migrations::STAGE_SHADOW
8
when LaunchDarkly::Migrations::STAGE_LIVE
9
when LaunchDarkly::Migrations::STAGE_RAMPDOWN
10
when LaunchDarkly::Migrations::STAGE_COMPLETE
11
else
12
  # throw an error
13
end

Finally, when the migration operation is complete, call the track_migration_op method to record your metrics:

1
client.track_migration_op(tracker);

To learn more, read Migrator and track_migration_op.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migration_variation method to evaluate your feature flag and determine its migration stage. This method returns the migration stage and a tracker that you can use to build the analytics event to send back to LaunchDarkly.

Here’s how:

1
let context = ContextBuilder::new("example-user-key")
2
    .kind("user")
3
    .build()
4
    .expect("Context failed to build");
5
6
let (stage, tracker) =
7
    client.migration_variation(&context, "example-migration-flag-key", Stage::Off);

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
// define the combination of reads and writes from the new and old systems
2
// that should occur at each migration stage
3
4
match stage {
5
    Stage::Off => todo!(),
6
    Stage::DualWrite => todo!(),
7
    Stage::Live => todo!(),
8
    Stage::Shadow => todo!(),
9
    Stage::Rampdown => todo!(),
10
    Stage::Complete => todo!(),
11
    _ => todo!(),
12
};

Finally, when the migration operation is complete, call the track_migration_op method to record your metrics:

1
client.track_migration_op(tracker);

To learn more, read Migrator and track_migration_op.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migrationVariation method to evaluate your feature flag and determine its migration stage. This method returns a promise that is resolved with the result LDMigrationVariation. This result includes the migration stage. It also returns a tracker, which you can ignore. (The tracker is normally used to build an analytics event to send back to LaunchDarkly. However, the Akamai SDK does not support sending events, so there is no need to build one.)

Here’s how:

1
  import {
2
    LDContext,
3
  } from '@launchdarkly/akamai-server-edgekv-sdk';
4
5
  const context: LDContext = {
6
     kind: 'user',
7
     key: 'example-user-key',
8
     name: 'Sandy',
9
  };
10
11
  const { value, tracker } = await client.migrationVariation(
12
    'example-migration-flag-key',
13
    context,
14
    false
15
  );

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
import { LDMigrationStage } from '@launchdarkly/akamai-server-edgekv-sdk';
2
3
// define the combination of reads and writes from the new and old systems
4
// that should occur at each migration stage
5
6
switch (value) {
7
  case LDMigrationStage.Off: { },
8
  case LDMigrationStage.DualWrite: { },
9
  case LDMigrationStage.Shadow: { },
10
  case LDMigrationStage.Live: { },
11
  case LDMigrationStage.RampDown: { },
12
  case LDMigrationStage.Complete: { },
13
  default: {
14
    // throw an error
15
  }
16
}

To learn more, read LDMigration.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migrationVariation method to evaluate your feature flag and determine its migration stage. This method returns a promise that is resolved with the result LDMigrationVariation. This result includes the migration stage and a tracker that you can use to build the analytics event to send back to LaunchDarkly.

Here’s how:

1
  import {
2
    LDContext,
3
  } from '@launchdarkly/cloudflare-server-sdk'
4
5
  const context: LDContext = {
6
     kind: 'user',
7
     key: 'example-user-key',
8
     name: 'Sandy',
9
  };
10
11
  const { value, tracker } = await client.migrationVariation(
12
    'example-migration-flag-key',
13
    context,
14
    false
15
  );

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
import { LDMigrationStage } from '@launchdarkly/cloudflare-server-sdk';
2
3
// define the combination of reads and writes from the new and old systems
4
// that should occur at each migration stage
5
6
switch (value) {
7
  case LDMigrationStage.Off: { },
8
  case LDMigrationStage.DualWrite: { },
9
  case LDMigrationStage.Shadow: { },
10
  case LDMigrationStage.Live: { },
11
  case LDMigrationStage.RampDown: { },
12
  case LDMigrationStage.Complete: { },
13
  default: {
14
    // throw an error
15
  }
16
}

Finally, when the migration operation is complete, call the trackMigration method to record your metrics:

1
import {
2
  LDClient,
3
  LDMigrationTracker,
4
} from '@launchdarkly/cloudflare-server-sdk';
5
6
const event = tracker.createEvent();
7
8
if (event) {
9
  client.trackMigration(event);
10
}

To learn more, read LDMigration and LDMigrationOpEvent.

Customizing your migration

Customizing your migration is rare. If you want to customize your migration, configure your migration information as before.

Then, use the migrationVariation method to evaluate your feature flag and determine its migration stage. This method returns a promise that is resolved with the result LDMigrationVariation. This result includes the migration stage and a tracker that you can use to build the analytics event to send back to LaunchDarkly.

Here’s how:

1
  import {
2
    LDContext,
3
  } from '@launchdarkly/vercel-server-sdk';
4
5
  const context: LDContext = {
6
     kind: 'user',
7
     key: 'example-user-key',
8
     name: 'Sandy',
9
  };
10
11
  const { value, tracker } = await client.migrationVariation(
12
    'example-migration-flag-key',
13
    context,
14
    false
15
  );

Next, perform the migration for the appropriate stage. At each stage, the migration may involve reading or writing from one or both systems. You must define the behavior for each stage. To learn more about how LaunchDarkly defines the stages, read Use SDKs to manage a migration, above.

The structure looks like this:

1
import { LDMigrationStage } from '@launchdarkly/vercel-server-sdk';
2
3
// define the combination of reads and writes from the new and old systems
4
// that should occur at each migration stage
5
6
switch (value) {
7
  case LDMigrationStage.Off: { },
8
  case LDMigrationStage.DualWrite: { },
9
  case LDMigrationStage.Shadow: { },
10
  case LDMigrationStage.Live: { },
11
  case LDMigrationStage.RampDown: { },
12
  case LDMigrationStage.Complete: { },
13
  default: {
14
    // throw an error
15
  }
16
}

Finally, when the migration operation is complete, call the trackMigration method to record your metrics:

1
import {
2
  LDMigrationTracker,
3
  LDClient
4
} from '@launchdarkly/vercel-server-sdk';
5
6
const event = tracker.createEvent();
7
8
if (event) {
9
  client.trackMigration(event);
10
}

To learn more, read LDMigration and LDMigrationOpEvent.