mirror of
https://github.com/Unleash/unleash.git
synced 2024-12-22 19:07:54 +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.
50 lines
4.3 KiB
Markdown
50 lines
4.3 KiB
Markdown
---
|
|
title: Technical Debt
|
|
---
|
|
|
|
At Unleash we care deeply about code quality. Technical debt creeps up over time and slowly builds to the point where it really starts to hurt. At that point it's too late. Feature toggles that have outlived their feature and are not cleaned up represent technical debt that you should remove from your code.
|
|
|
|
## Stale and potentially stale toggles
|
|
|
|
When a toggle is no longer useful, we say that it has become _stale_. A stale toggle is a toggle that has served its purpose and that you should remove from the code base. For a toggle to become stale, you have to explicitly mark it as such. You can mark a toggle as stale in the [technical debt dashboard](#the-technical-debt-dashboard).
|
|
|
|
Unleash also has a concept of _potentially_ stale toggles. These are toggles that have lived longer than what Unleash expects them to based on their [feature toggle type](../reference/feature-toggle-types.md). However, Unleash can't know for sure whether a toggle is actually stale or not, so it's up to you to make the decision on whether to mark it as stale or to keep it as an active toggle.
|
|
|
|
A toggle being (potentially) stale, does not affect how it performs in your application; it's only there to make it easier for you to manage your toggles.
|
|
|
|
## The technical debt dashboard
|
|
|
|
In order to assist with removing unused feature toggles, Unleash provides project health dashboards for each project. The health dashboard is listed as one of a project's tabs.
|
|
|
|
|
|
|
|
The dashboard includes a health report card, and a list of toggles that can be filtered on different parameters.
|
|
|
|
### Report card {#report-card}
|
|
|
|
|
|
|
|
The report card includes some statistics of your application. It lists the overall amount of your active toggles, the overall amount of stale toggles, and lastly, the toggles that Unleash believes should be stale. This calculation is performed on the basis of toggle types:
|
|
|
|
- **Release** - Used to enable trunk-based development for teams practicing Continuous Delivery. _Expected lifetime 40 days_
|
|
- **Experiment** - Used to perform multivariate or A/B testing. _Expected lifetime 40 days_
|
|
- **Operational** - Used to control operational aspects of the system's behavior. _Expected lifetime 7 days_
|
|
- **Kill switch** - Used to to gracefully degrade system functionality. _(permanent)_
|
|
- **Permission** - Used to change the features or product experience that certain users receive. _(permanent)_
|
|
|
|
If your toggle exceeds the expected lifetime of it's toggle type it will be marked as _potentially stale_.
|
|
|
|
One thing to note is that the report card and corresponding list are showing stats related to the currently selected project. If you have more than one project, you will be provided with a project selector in order to swap between the projects.
|
|
|
|
### Health rating
|
|
|
|
Unleash calculates a project's health rating based on the project's total number of active toggles and how many of those active toggles are stale or potentially stale. When you archive a toggle, it no longer counts towards your project's health rating.
|
|
|
|
The health rating updates once every hour, so there may be some lag if you have recently added, removed, or changed the status of a toggle.
|
|
|
|
### Toggle list {#toggle-list}
|
|
|
|
|
|
|
|
The toggle list gives an overview over all of your toggles and their status. In this list you can sort the toggles by their name, last seen, created, expired, status and report. This will allow you to quickly get an overview over which toggles may be worth deprecating and removing from the code.
|