A web UI

[mehulkar]

One of my concerns is separating the task of deploying and developing. This breaks down into a couple things:

1. Making new builds available
2. Deploying new builds.

I'd like our deploy process to look like this:

1. Update source control (either tag a new release, or push new code, whatever)
2. Deploy team is notified of new build available (or polls for new builds)
   • This is unimportant, but Github webhook, or cron job on deploy servers are both trivial to implement)
3. Deploy team opens up web UI, sees available builds and clicks a button for the build they want to deploy (for whatever target, e.g. staging, prod, etc).

I can see this web UI as an addon/plugin based on @lukemelia's talk at EmberConf2015, but wanted to get thoughts on the use case.

[samselikoff]

Hey @mehulkar ! Good thoughts.

The web UI will probably be a server component. front_end_builds is an implementation of what you're describing that @ryanto and I have been working on. It has an admin interface that does exactly what you suggest:

You can preview builds, see which one is live, make new builds live etc. It's still early on but we're using it for a few of our apps. If you're using Rails for your backend and want to give it a shot, I'd suggest waiting until we convert the Ember CLI piece into a plugin under this new parent project, which will be happening soon.

[stefanpenner]

rad

[mehulkar]

@samselikoff nice! the front_end_builds gem looks pretty great, but I'd be concerned about coupling between the API and web clients. It looks like I might run into problems (with the code and with the process of deploying) if I have multiple web clients that depend on the same API.

One solution here is to deploy new Rails applications for each supported front end and a separate Rails server for the actual API. But this adds layers of complexity to a stack that is already too complex for a newb like me 😕.

I have some additional thoughts on the original issue also (that are probably out of the scope of this project):

When I opened this issue, I envisioned the admin server to be a feature of ember-cli-deploy. Something like ember deploy:adminserver --daemonize --port 5000.

But the more I think about it, I'd want that admin server to be platform agnostic so I can install and run without the Node.js dependency (through yum/apt-get/whatever). That sounds like an entirely new project to me, but if I went that route, I'd want it to run smoothly with this.

These are still kind of incomplete thoughts, but hopefully it gives you a better idea of the use case and we can triage this issue based on that.

[samselikoff]

Definitely, keep the ideas coming.

Coupling our deploy server to our API server is absolutely an intermediate solution. I think a node server for this makes a lot of sense, especially because FastBoot will require one as well.

I spoke to @trek a bit about this, I believe at Groupon each team has a separate node server for serving/deploys.

[samselikoff]

@mehulkar just an fyi that we've been talking about this, our current thinking suggests ember-cli-deploy may in fact want to provide enough structure to support a notion of a builds listing + activation process, regardless of how the backend is implemented. Obviously this would mean various backends would need to conform to a certain interface (ability to list builds, ability to activate), but this would allow us to do something nice like make a web ui.

[mehulkar]

That sounds awesome. We're sticking to shell script deploy right now served as static files through Nginx. I think when Fastboot lands and if we have the luxury of making use of it, a build in node server and admin UI would be nice. I think I'll end up building a completely separate admin UI that fits all our cases instead of a general one for the Ember app.

[samselikoff]

We're working on something similar which we hope to move to a node server as well. One the goals for ember-cli-deploy is to still be useful in these types of endeavors, so people aren't duplicating work needlessly.

I think a UI for ember-cli-deploy would still be nice for the onboarding experience.

[listepo]

+1

[duizendnegen]

Hi @samselikoff & @mehulkar - can I have an update on how you are currently treating this?
I talked to @achambers recently and he mentioned he was saving more in-depth info (git sha, author, commit messages, even a diff of features between certain deploys?) - to bring this forward we probably have to move a few plugins uploading index.html to augment the data added.