Git-style version control
Version history
All of your flags are versioned together in the single Git-style version history of your project.
Commits
Whenever you save changes in the Hypertune UI, a new commit is created on the main branch of your project.
Since all your flags are versioned together, you can change many flags in one go, in a single, atomic commit. This is particularly useful when flags interact, as you can avoid changing them one-by-one, risking bad combinations of flag values.
You can view historical commits in the commit selector in the navigation bar. You can see who created them, at what time, and instantly roll back to them.
Diffs
Before you save changes in the Hypertune UI, you can review them in the Diff view. This enables you to avoid unintended changes.
When you select a historical commit from the commit selector in the navigation bar, the Diff view shows the changes made in that commit. This enables you to see which flags changed and when.
Fun technical details: The visual diffs of your logic changes are cleaner, smaller and more powerful than you get with code diffs, as the diffing algorithm operates on the structure of your logic tree. For example, if you extract logic, like a list of user IDs, to a variable, we only highlight usages of the new variable in the diff, not the content of the variable, since the content hasn't changed — it has only been moved to a new part of your logic tree.
Branches
You can see a branch dropdown in the navigation bar. By default, it's set to your main branch, so any changes you save will create new commits on your main branch. By default, SDKs initialize from the most recent commit or the "tip" of your main branch.
You can create a new branch from the dropdown in the navigation bar. The new branch will be selected and any changes you save will create new commits on this branch, so they will be isolated from the main branch.
To configure the SDK to initialize from the tip of this branch instead, you can set branchName in your createSource options.
This enables you to test and preview flag changes locally before merging them into your main branch with a pull request. You can even set the branchName option dynamically, e.g. via a URL parameter, to preview flag changes in your production app. This is useful to preview changes to more complex app configuration like in-app copy.
This is cleaner than using shared "environments" to test flag changes. Shared environments often include other developer's flag changes, which may interact with your changes and pollute your test. Shared environments can also "drift" from the main "production" environment over time. This prevents you from isolating and testing your specific changes.
Schema migrations
If your branch has schema changes, you can also set the HYPERTUNE_BRANCH_NAME environment variable and run npx hypertune to regenerate your client against your branch's schema.
This enables you to easily refactor your project's schema with the following migration steps:
Create a branch
Make schema changes
Regenerate your client against the branch
Configure the SDK to initialize from the branch in production
Merge your branch into main with a pull request
Reconfigure the SDK to initialize from the main branch
Pull requests
You can create a pull request to merge a branch into your main branch in the "Pull requests" view.
You will see a diff of the changes made in the branch that will be merged into the main branch.
If changes have been made on main since the branch was created, you will see an option to "squash and rebase". This will take the changes you've made on your branch and apply them on top of main, in a new "squashed" commit on your branch. This new squashed commit will have the tip of main as its parent.
You will then see an option to "merge" the branch. This will create a new commit on main with the changes in your branch. You can then delete the branch.
Team roles
You can assign roles to members of your team in the Team view, and set a default role for new team members in the Settings view.
The table below shows the permissions of each role:
Safely onboarding nontechnical team members
You can assign nontechnical stakeholders like product managers, marketers, content writers, etc, the Contributor role while they learn to use Hypertune.
When a Contributor makes changes, a pull request is automatically created with a branch containing their changes. They can share a link to the pull request with an engineer who can review and merge it for them.
Once a Contributor can confidently make changes themselves, they can be made an Editor or Admin so they can operate independently, without requiring reviews from engineering, enabling the whole organization to move faster.
Last updated