Environments within an App

[kingdonb]

It seems like a natural idea that I would use in my daily workflows to add Environments to an App

Things like, the branch name is deployed to an environment of a matching name

There should be some logic or a configurable way to schedule automatic promotion from one environment to another, in the base case you would have two environments: staging and production

Spawned from #41

[krancour]

It seems like a natural idea that I would use in my daily workflows to add Environments to an App

Seems useful.

Things like, the branch name is deployed to an environment of a matching name

Put some more thought into this before committing to that. If someone wanted / was willing to have a branch per environment, they could already do that today and connect each of those branches to a separate Workflow application and move things between environments simply by merging things into the right branches and having that trigger something in their favorite CI / automation solution.

i.e. You can do this today without implementing any new features. So if you're going to add a new feature, figure out what it allows you to do that you can't already do, because that's where the value is.

There should be some logic or a configurable way to schedule automatic promotion from one environment to another, in the base case you would have two environments: staging and production

As I've often said, this should be accomplished by your favorite automation solution. The automation shouldn't be part of Workflow.

[kingdonb]

If I want a new environment for every branch, and I'm going to be creating feature branches all the time, (and let's say I have no tests... so we're not even talking about CI) asking me to create every environment as an additional app/remote by hand is ... quite a bit more trouble than I want to go through. I'd like to be able to push a new branch and let my new environment be automatically created and provisioned right there, on-demand.

(How do you plan to clean them up after that... there are lots of questions)

This needs more thought, for sure, but once we're agreed on the formal concept of an environment, that an app can have more than one of them associated with it, we can open up to ideas like that.

This is an idea that can be independent of the pipelines functionality we've been discussing though.

[kingdonb]

I'm not sure how much code that feature is actually worth though. Creating a new app sure it's more than I want to do, but how much candy do you really need... let's say I decided that my new app environment must be provisioned manually, and I wind up with something that's functionally equivalent to deis create setting a different remote.

That's more organized maybe? It's clearer now that these deployments are related? There has to be more of an actual beneficial payoff for an actual code change supporting this to be worth it.

[krancour]

If I want a new environment for every branch, and I'm going to be creating feature branches all the time....

I misunderstood that you probably had in mind a fixed number of environments and you wanted to each aligned with a branch that hosts the source that is currently deployed in the corresponding environment.

It sounds like you want to dynamically create new environments for new branches. I'm going to sound like a broken record, but you can already do that using your favorite automation solution-- watch for new branches and script deis app:create ..., etc.

So the question remains of what does the notion of an environment buy you that you can't already do today?

For me, the answer has everything to do with #41. Absent the "pipeline" feature, I'm not sure this is needed.

[kingdonb]

Yes, both

I'm not sure I would use pipeline promotion with feature branches, but it would be superb to be able to configure Workflow with a git hook so that the deployment happens automatically.

I know you can already automate this stuff with the primitives + an additional solution, but even if it's already possible, the best known edition of the solution isn't documented anywhere, and the best implementation might require some code to be written, above and beyond simply documenting how you can already do this.

But as building some documentation of our own is one of Hephy's earliest and high priority goals, the first solution is likely to take the form of a blog post or some more formal documentation.