docs: [FUN-449] Add what is it for doc#507
Conversation
| ## What should I use it for? | ||
|
|
||
| `dev-server` is intended as a replacement for creating certain kinds of environments in the LD app itself that are not part of a flag's release path e.g. Staging, UAT, QA, Production. The most common examples of this are local development environments and ephemeral CI environments. | ||
|
|
||
| ## What should I not use this for? | ||
|
|
||
| You should refrain from using `dev-server` for any release path critical environments, as well as environments where complex targeting logic is required. Currently, `dev-server` only supports serving a single variation and supports no targeting logic. |
There was a problem hiding this comment.
I feel like this is saying the same thing twice i.e. "don't use this for anything besides local dev and ephemeral CI environments"
While writing, I kept dreaming up weird use cases for this but I think we want to steer folks away from that kind of thing
There was a problem hiding this comment.
Yeah. I think that there are a few points we want to make here.
- don't ever use the dev server for a prod workload because it might not work
- the dev server is for local dev & CI environments
- because it's for environments with a single user, it's simpler and has fewer features
- no targeting
- the dev server should still guide you to shipping your code safely and minimize surprises as you get to prod
- so you can't create flags, you have to pull them from a real environment and iterate from there
Probably also need a sentence to describe what this doc is, I think it's less of how to use the dev server, but more of like "what is it supposed to do and why".
There was a problem hiding this comment.
@mike-zorn Okay made some pretty significant edits
tvarney13
changed the title
internal/dev_server/manifesto.md
Outdated
|
|
||
| We implemented it this way in order to solve a problem common both internally and amongst our userbase where an environment would get created per developer on a project as well as per CI build. As you could expect, this becomes exponentially harder to maintain as the number of environments scales both technically and from a process perspective - something has to clear out those environments after all! | ||
|
|
||
| Another intentional design decision was the choice not to allow the creation of local-only flags. A running `dev-server` can only pull from a real environment. From there, you can override the served value for your local environment. |
There was a problem hiding this comment.
Rewrite this without mentioning local-only flags. That's a feature we've discussed internally, but isn't something a reader of this doc will know about. I think you want to frame it as "flags must first exist in the source environment" or similar.
mike-zorn
left a comment
mike-zorn
left a comment
There was a problem hiding this comment.
Some minor notes, but looks good otherwise!
Co-authored-by: Mike Zorn <mike@launchdarkly.com>
Co-authored-by: Mike Zorn <mike@launchdarkly.com>
2 participants
This PR adds the what is it for doc and makes a minor grammar correction in the main README.