mirror of
https://github.com/Unleash/unleash.git
synced 2024-10-28 19:06:12 +01:00
d5fbd0b743
## What This (admittedly massive) PR updates the "physical" documentation structure and fixes url inconsistencies and SEO problems reported by marketing. The main points are: - remove or move directories : advanced, user_guide, deploy, api - move the files contained within to the appropriate one of topics, how-to, tutorials, or reference - update internal doc links and product links to the content - create client-side redirects for all the urls that have changed. A number of the files have been renamed in small ways to better match their url and to make them easier to find. Additionally, the top-level api directory has been moved to /reference/api/legacy/unleash (see the discussion points section for more on this). ## Why When moving our doc structure to diataxis a while back, we left the "physical' files lying where they were, because it didn't matter much to the new structure. However, that did introduce some inconsistencies with where you place docs and how we organize them. There's also the discrepancies in whether urls us underscores or hyphens (which isn't necessarily the same as their file name), which has been annoying me for a while, but now has also been raised by marketing as an issue in terms of SEO. ## Discussion points The old, hand-written API docs have been moved from /api to /reference/api/legacy/unleash. There _is_ a /reference/api/unleash directory, but this is being populated by the OpenAPI plugin, and mixing those could only cause trouble. However, I'm unsure about putting /legacy/ in the title, because the API isn't legacy, the docs are. Maybe we could use another path? Like /old-docs/ or something? I'd appreciate some input on this.
85 lines
6.0 KiB
Plaintext
85 lines
6.0 KiB
Plaintext
---
|
|
title: How to schedule feature releases
|
|
---
|
|
import ApiRequest from '@site/src/components/ApiRequest'
|
|
|
|
:::info Placeholders
|
|
Placeholders in the code samples below are delimited by angle brackets (i.e. `<placeholder-name>`). You will need to replace them with the values that are correct in _your_ situation for the code samples to run properly.
|
|
:::
|
|
|
|
There's a whole host of reasons why you may want to schedule the release of a feature, such as:
|
|
- **to release a feature at a specific date and time** (for a product launch, for instance)
|
|
- **to make a feature available only up until a specific moment** (for a contest cutoff, for instance)
|
|
- **to make a feature available during a limited period** (for a 24 hour flash sale, for instance)
|
|
|
|
There's two distinct ways to do this, depending on which version of Unleash you are running:
|
|
- If you're using version 4.9 or later of Unleash Pro or Enterprise, you can (and should) [use strategy constraints](#strategy-constraints)
|
|
- Otherwise, [use custom activation strategies](#custom-activation-strategies)
|
|
|
|
In this guide we'll schedule a feature for release at some point in time. The exact same logic applies if you want to make a feature available until some point in the future. Finally, if you want to only make a feature available during a limited time period, you can easily combine the two options.
|
|
|
|
## Prerequisites
|
|
|
|
This guide assumes that you've got the following:
|
|
- some basic experience with Unleash
|
|
- a running instance of Unleash and connected clients (where applicable)
|
|
- an existing feature toggle that you want to schedule the release for
|
|
|
|
## Schedule feature releases with strategy constraints {#strategy-constraints}
|
|
|
|
[Strategy contstraints](../reference/strategy-constraints.md#date-and-time-operators) are the easiest way to schedule feature releases ([as long as your SDKs are up to date](../reference/strategy-constraints.md#incompatibilities)). You can use this approach with _any_ strategy you want. The strategies will work just as they normally do, they just won't become active until the specified time. For example: with the standard strategy, the feature would become available to all your users at the specified time; with a gradual rollout, the rollout would start at the specified time.
|
|
|
|
### Step 1: Add an activation strategy with a date-based constraint
|
|
|
|
#### Scheduling a release via the UI
|
|
|
|
To schedule a feature release via the UI:
|
|
1. Add the desired activation strategy to the feature
|
|
2. Open the constraint creator by using the "Add constraint" button
|
|
3. Add a date-based constraint by selecting the `currentTime` context field (step 1 in the below image), choosing the `DATE_AFTER` operator (step 2), and setting the point in time where you want the feature to be available from (step 3)
|
|
|
|
|
|
#### Scheduling a release via the API
|
|
|
|
To add an activation strategy via the Admin API, use the feature's `strategies` endpoint to add a new strategy (see the [API documentation for adding strategies to feature toggles](/reference/api/legacy/unleash/admin/features-v2.md#add-strategy) for more details).
|
|
|
|
The payload's `"name"` property should contain the name of the strategy to apply (see [activation strategies reference documentation](../reference/activation-strategies.md) for all built-in strategies' _modeling names_).
|
|
|
|
The `"constraint"` object should have the same format as described in the code sample below. The activation date must be in an [RFC 3339-compatible format](https://datatracker.ietf.org/doc/html/rfc3339#section-5.8), e.g. `"1990-12-31T23:59:60Z"`.
|
|
|
|
<ApiRequest verb="post" payload={{
|
|
"name": "default",
|
|
"constraints": [
|
|
{
|
|
"value": "<activation-date>",
|
|
"operator": "DATE_AFTER",
|
|
"contextName": "currentTime"
|
|
}
|
|
]
|
|
}} url="api/admin/projects/<project-id>/features/environments/<environment>/strategies" title="Add a feature activation strategy with a scheduled activation time."/>
|
|
|
|
The `"operator"` property in the code sample can be replaced with [any of the other date and time-based operators](../reference/strategy-constraints.md#date-and-time-operators) according to your needs.
|
|
|
|
## Schedule feature releases with custom activation strategies {#custom-activation-strategies}
|
|
|
|
To schedule feature releases without using strategy constraints, you can use custom activation strategies. This requires defining a custom strategy and then implementing that strategy in your SDKs. For detailed instructions on how to do either of these things, refer to their respective how-to guides:
|
|
- [How to _define_ custom strategies](../how-to/how-to-use-custom-strategies.md#step-1)
|
|
- [How to _implement_ custom strategies](../how-to/how-to-use-custom-strategies.md#step-3)
|
|
|
|
### Step 1: Define and apply a custom activation strategy
|
|
|
|
**Define a strategy** that takes a parameter that tells it when to activate (visit [the custom activation strategy reference documentation](../reference/custom-activation-strategies.md#definition) for full details on definitions):
|
|
|
|
1. Give the strategy a name. We'll use `enableAfter`.
|
|
2. Give the strategy a required string parameter where the user can enter the time at which the feature should activate. Be sure to describe the format that the user must adhere to.
|
|
3. Save the strategy
|
|
|
|
[**Apply the strategy** to the feature toggle](../how-to/how-to-use-custom-strategies.md#step-2) you want to schedule.
|
|
|
|
|
|
|
|
|
|
### Step 2: Implement the custom activation strategy in your clients
|
|
|
|
In each of the client SDKs that will interact with your feature, implement the strategy ([the implementation how-to guide](../how-to/how-to-use-custom-strategies.md#step-3) has steps for all SDK types).
|