I'd like to go to production soon, and the worries I have are all around managing live code

[pbiggar]

A user says:

The editor is very easy to use and very quick to get a working application. I'd like to go to production soon, and the worries I have are all around managing live code. It seems too easy to accidentally change something that customers are using, and no good version control mechanism to roll back changes. I'd like to have something similar to git branches.

[xtopherbrandt]

I agree with the sentiment here, Dark needs some kind of change review / staging process and a version control system. But source code branches are not a natural fit here (IMHO). Every change is effectively a commit to master in Dark. So we really need a tagging mechanism that lets us go back to a marked point in the evolution of the code.

Branching is more naturally done at the feature level with patterns like Branch by Abstraction. Maybe there's a way to bring that pattern to life within Dark ?

[pbiggar]

Feel's like we'd get about 50% of this win by just providing a view of post commits, who authored them, and what datetime they were written (not easy but much much easier than the full thing).

[pbiggar]

Yeah, feature flags is the intended mechanism for everything like this.

[pbiggar]

Using separate urls is an option though many people will want to do the same thing without changing urls (hard to update clients in many cases). So yeah, same idea but different options on how to do it.

[jtwaleson]

The common way is to have separate domains (or paths) for each environment. Each environment has a certain level of "stability", so clients don't have to change them. E.g. all the latest versions should end up on /api/live/... or /api/production/....

[pbiggar]

Sure, that's a way to do it, but i think you can have the same benefits with just feature flags.

[sanderjson]

I tried using /api/v1/ and /api/v2 in the past but I think it caused some strange errors with functions?

I love the idea of feature flags. From my brief testing it felt like I was adding more complexity than it solved. My take away was to work with the namespace if the api is changing rapidly then try feature flags once the code hardens.