The Art of Ember Deployment
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 22 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/34741 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
EmberConf 20156 / 22
6
8
9
10
14
15
16
17
18
20
21
00:00
Rhombus <Mathematik>EDV-BeratungSoftwareInternetworkingBrowserLaufzeitfehlerMosaicing <Bildverarbeitung>VersionsverwaltungServerProgrammierparadigmaFiletransferprotokollElektronische PublikationProzess <Informatik>PunktExogene VariableE-MailSkriptspracheWeb-SeiteSchnittmengeHydrostatikCDN-NetzwerkDokumentenserverClientMobiles InternetDatenstrukturMomentenproblemElektronischer FingerabdruckBrowserEndliche ModelltheorieMultiplikationsoperatorLaufzeitfehlerRechter WinkelTeilbarkeitSoftwareMagnetbandlaufwerkEDV-BeratungInternetworkingServerPunktSpieltheorieWechselsprungLastWeb SiteSpezielle unitäre GruppeWurm <Informatik>InstantiierungInteraktives FernsehenAdditionSelbstrepräsentationAggregatzustandExogene VariableSchnittmengeFramework <Informatik>Automatische IndexierungInformationsspeicherungFünfDatei-ServerQuick-SortFrequenzAutomatische HandlungsplanungProzess <Informatik>VersionsverwaltungSkriptspracheBenutzerbeteiligungTwitter <Softwareplattform>MathematikWeb-SeiteCD-ROMProgrammierungDickeEinfache GenauigkeitElektronischer ProgrammführerClientTaskFehlermeldungApp <Programm>Dienst <Informatik>CASE <Informatik>DatenflussGrenzschichtablösungLie-GruppeNummernsystemDokumentenserverZahlenbereichProgrammierparadigmaHydrostatikOrdnung <Mathematik>MereologieData MiningAppletHybridrechnerProdukt <Mathematik>Selbst organisierendes SystemElektronische PublikationSchedulingFiletransferprotokollObjekt <Kategorie>Ganze FunktionDistributionenraumPhysikalischer EffektHIP <Kommunikationsprotokoll>EinsMagnetbandkassetteCDN-NetzwerkSoftwareindustrieWeb-ApplikationComputeranimation
08:08
ÄhnlichkeitsgeometrieMobiles InternetHausdorff-DimensionBetafunktionServerVersionsverwaltungKontrollstrukturPunktBootenURLAppletKonfigurationsraumSkriptspracheCross-site scriptingStrategisches SpielWeb-SeiteFaktorenanalyseZeitbereichBeschreibungskomplexitätHydrostatikProzess <Informatik>CodeSpezialrechnerDienst <Informatik>GasströmungImplementierungGamecontrollerDynamic HTMLVolumenvisualisierungIndexberechnungToken-RingFahne <Mathematik>Notepad-ComputerSoftwaretestTypentheorieClientVersionsverwaltungProgrammierparadigmaInformationsspeicherungBrowserGamecontrollerApp <Programm>KonfigurationsraumSoftwaretestFahne <Mathematik>Produkt <Mathematik>Humanoider RoboterDynamisches SystemComputerspielFaserbündelOrdnung <Mathematik>URLBootstrap-AggregationBereichsschätzungService providerFront-End <Software>AbfrageSoftwareentwicklerRepository <Informatik>ZeichenketteMereologieCachingServerProzess <Informatik>Analytische MengeEinbettung <Mathematik>Inhalt <Mathematik>BitEntscheidungstheorieRoutingInformationGeradeSelbstrepräsentationGebäude <Mathematik>MultiplikationsoperatorHydrostatikDifferenteStrömungsrichtungMini-DiscLesen <Datenverarbeitung>ProgrammierumgebungMathematikMeta-TagLoginImplementierungWeb-SeiteDateiverwaltungStapeldateiMultiplikationFitnessfunktionGüte der AnpassungMixed RealityCASE <Informatik>CodeKomplex <Algebra>Socket-SchnittstelleBenutzerbeteiligungStrategisches SpielDomain <Netzwerk>Reelle ZahlGruppenoperationSoundverarbeitungEDV-BeratungBildgebendes VerfahrenParametersystemDatenfeldCDN-NetzwerkUmwandlungsenthalpieAdditionPunktRadikal <Mathematik>p-BlockGewicht <Ausgleichsrechnung>GravitationToken-RingVererbungshierarchieFramework <Informatik>Metrisches SystemCoprozessorRechter WinkelFlächeninhaltArithmetisches MittelMinimumAppletOrtsoperatorComputeranimation
16:16
Open SourceArchitektur <Informatik>Kontrast <Statistik>Gebäude <Mathematik>VideokonferenzDokumentenserverMigration <Informatik>SoftwareentwicklerGruppenkeimURLMailing-ListeHook <Programmierung>ImplementierungEin-AusgabePlug inSensitivitätsanalyseMultiplikationsoperatorProgrammierumgebungVariableTabelleService providerElektronische PublikationMehrrechnersystemApp <Programm>Open SourceProzess <Informatik>TypentheorieRechenschieberFront-End <Software>GruppenoperationProjektive EbeneGebäude <Mathematik>CLIServerDebuggingSystemaufrufMigration <Informatik>Güte der AnpassungImpulsMailing-ListeZusammenhängender GraphZurücksetzung <Transaktion>DifferenteComputerspielGemeinsamer SpeicherClientMusterspracheKonfigurationsraumGleitendes MittelVirtuelle MaschineVersionsverwaltungHilfesystemMAPAdditionDienst <Informatik>SoftwarewartungTwitter <Softwareplattform>SoftwareentwicklerFunktionalComputerarchitekturSpeicherabzugGeradeSummierbarkeitSkriptspracheStabArithmetisches MittelFilter <Stochastik>Automatische IndexierungLesen <Datenverarbeitung>Endliche ModelltheorieInformationsspeicherungRepository <Informatik>Tablet PCRechter WinkelSchnitt <Mathematik>TelekommunikationDomain <Netzwerk>MathematikDatenstrukturComputeranimation
24:25
Chatten <Kommunikation>BetafunktionSoftwaretestKonfiguration <Informatik>TemplateServerNotepad-ComputerSpezialrechnerBootenCross-site scriptingWeb-SeiteGasströmungGesetz <Physik>Kappa-KoeffizientWeb-SeiteServerProjektive EbeneBootenBitKonfigurationsraumProdukt <Mathematik>StellenringSchnittmengeEntscheidungstheorieSystemaufrufUmsetzung <Informatik>Konfiguration <Informatik>VersionsverwaltungOpen SourceSoftwaretestStrömungsrichtungInformationApp <Programm>Klassische PhysikVolumenvisualisierungEin-AusgabeIdentifizierbarkeitReelle ZahlKreisbogenProzess <Informatik>ZahlenbereichProxy ServerFormation <Mathematik>ProgrammierparadigmaDienst <Informatik>BetafunktionFitnessfunktionAdditionRechenschieberMaschinenschreibenCASE <Informatik>Rechter WinkelDatenfeldSkriptspracheXMLComputeranimation
29:04
Rhombus <Mathematik>VideokonferenzEreignishorizontDienst <Informatik>Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:16
Hey, EmberConf. It is good to be here.
00:21
So, let's see what we got going on here. The art of Ember app deployment. My name is Luke Melia. For those of you who I don't know, I live in Manhattan with my wife and two daughters. I write a lot of Ruby and JavaScript, some Objective-C, and when I'm not doing dad stuff or coding, I love to play beach volleyball. I'm the organizer of Ember.js NYC.
00:41
You might have seen some footage earlier in the day. Please come and join our community. We love to have speakers from out of town, so don't hesitate to reach out and schedule something. I run a fun kind of hybrid business where we have a product as well as do Ember consulting. If we can be helpful in any of those sides, let me know. Let's jump into it.
01:01
So, how we deliver software has evolved over time. I would say this is kind of a fair way to say that it started. And it evolved cassette tapes. This is really where I got started playing games on old Atari. Spent a lot of time with these guys.
01:23
And then if you looked in your gift bag today when you checked in, you probably had one of these guys in there. Actually looked a lot like those. And then finally came our beloved internet. And with that came the browser, which has become the most ubiquitous
01:42
app run time in the world. And it didn't start off kind of that way, but once it got going, it became pretty amazing. And so, delivering software for most of us became how do we deliver via the web? And in the beginning was just static HTML
02:00
sent from a fairly low powered server to the browser. Eventually that became dynamic HTML sent from some more powerful servers to the browser. And then came the rise of the server side app frameworks. Again delivering representations, HTML representations of that app state with each request to the browser.
02:22
And finally we came to today with EmberConf where we're delivering an HTML and JavaScript payload and then interacting with an API but really having the entire run time in the browser. And we may take what I just said for granted, but of course William Gibson said it best
02:42
that the future's already here, but it's not evenly distributed. For as many of us as are here in this room, there are many more people out in the industry who have yet to arrive at this kind of browser app paradigm. And for many of us here in the room, we're still holding on to some of our deployment techniques from the server app days
03:03
even though we've moved to this new paradigm. And that's what I want to talk about today. Cause after all we no longer use CD-ROM duplicators to deploy software. This is kind of a funny picture and the reason I included it even though it's a little blurry is that in my very first software company which kind of started around the dawn of the web,
03:22
this was, getting one of these was a game changer for us. I mean it changed our lives. But we also no longer deploy FTP files individually. Anybody recognize this program up here? Fetch, awesome. Somebody at least as old as I am.
03:40
So what is the web server, the server web app deployment approach? Simplified, it's copying all the files to the servers, restart the server processes. Pretty simple. For bonus points, you can do that copy file step more elegantly. Get push, your Twitter, BitTorrent, Docker containers if you're hip.
04:02
And you're probably gonna wanna do a rolling restart to avoid downtime. So the question is, is the server app deployment approach right for Ember apps? And you can probably guess by the fact that I'm up here talking to you that my answer to that is no. And so let's look at why.
04:21
Let's start with the real basic flow here. So browser makes an initial request for your Ember app. Requests index.html from your server. Your server comes back with an HTML response. And that response contains within it a script tag that points to a fingerprinted JavaScript file.
04:41
So in this case, app-abc123.js. So the browser parses that page a short time later and makes the request for that JavaScript. Comes back to the server, server says, yep, got it, here you go. Ember app boots, all's well. But during deployments, this doesn't necessarily go so smoothly.
05:02
Because there's a moment in time during a rolling deployment where that request for your HTML comes in to the server, gets back a reference to app-abc123. The request is made, and right at that moment before the request is made, your deployment infrastructure has flipped over traffic
05:21
to the new server. And so the new server comes up and in that new deployment, you now have a new fingerprinted JavaScript package, app-def456. And when it gets the request for app-123, you get 404 not found. User gets a hiccup or your QA team, they refresh the page and they're like,
05:41
oh, everything's fine, we'll just ignore that. But obviously not a great experience. And so the lesson in here is to keep static assets working during a rolling restart, if you're using this traditional approach, somehow you've got to keep both the old and the new versions of these assets around for at least a few minutes during the deployment. One way to do this, which many of us probably do,
06:02
is deploy these assets to a CDN and just don't remove the old ones for a while or maybe never, considering storage costs these days. So another aspect to think about is how users interact with our apps in this browser-app paradigm. Because today it's not uncommon for a user
06:22
to be on your site for five, 10, 15 minutes in this one kind of page load, if you will. And so what happens during this when you're doing a deployment? Well, app-boots gets its HTML and JavaScript, user starts doing their thing, requests some JSON from the server, and then around that point in time you decide, hey, I've got some nifty new feature I'm going to deploy,
06:43
you deploy some new JavaScript and an API change to go with it, and of course this user who's on this yellow timeline up here doesn't have the new JavaScript, right, because they didn't refresh the page. And so when they next try to make a request to that API, assuming that you have some sort of breaking change there,
07:02
they're going to get some sort of error. And so the lesson here is that whether we think about it this way or not, we have multiple versions of our Ember app in use at once. You have the new version that new users are getting, and you have the previous version that users who have been on the site for a few minutes are using. And so we somehow need our API to remain backwards compatible
07:23
for at least the length of a user session. And so what I'm going to submit to you based on what we just looked at is that the idea of versioning your Ember app and your server API app together as a single version number with a single release process is a lie.
07:40
And we can embrace this fact, choose honesty and give our Ember app a separate repository, a separate versioning scheme, and a separate release process. And we can learn some lessons here from the way we think about the native app ecosystem here. It's kind of taken for granted that you're going to have multiple versions of a native app out in the wild talking to your API.
08:04
And what you need to do is to keep your API working for those older clients for some period of time. You're probably going to decide to end of life them at some point, but you certainly don't want to do that kind of each release that you go from the app to the app store. And you would never consider, for example, trying to time the release of your API change
08:21
with when your app gets approved by Apple or gets through the Android submission process, right? That would be pretty silly. So we can learn from these native apps and see that this requirement buys a certain amount of freedom and a bunch of decoupling. So, for example, you might have multiple apps and apps for talking to a single API.
08:41
You might have beta builds that are out being tested running against your production API. And we can learn and embrace these things. We can and should do the same approach for our Ember apps, assuming that we are versioning and deploying these things independently. But there is a big workflow difference between native apps and Ember apps, and that's how apps are launched
09:02
and how they're updated. And the key difference here is that instead of an app store and the OS being responsible for updating and launching, what's responsible here is HTML. HTML you can think of as the bootstrapping engine for your Ember app. And this probably seems pretty obvious,
09:21
but when you follow through the implications to what does it mean for your deployment, it turns out there's some pretty serious implications. So what do we need to think about for these HTML pages? HTML pages that are bootstrapping our apps need to point to fingerprinted JavaScript and CSS, but they can't be fingerprinted themselves, right? They need to be at a stable URL.
09:41
They have a certain amount of order significance, so you wouldn't want to load your, say your app bundle before your vendor bundle, and if you're using a bundle and strategy like that. And they're also a really good place to provide kind of environment-specific configuration to your Ember app that you don't necessarily want to bake into your JavaScript.
10:03
In addition, if you can serve up this HTML on the same domain as your API, you get to sidestep all of the course complexity that comes along with having separate domains for those. Finally, caching should be minimal to none so that when you do want to deploy a new version, you're delivering it to new users ASAP.
10:24
So the conclusion here is that HTML should be managed and deployed as part of your static asset build, so that's really part of your Ember app repo and build process, but somehow it should be deployed to your API server, your app server. And ideally, and importantly, updates should not require
10:41
redeploying the server code, and it shouldn't require restarting server processes. And back when we were first building Ember apps, we were deploying our API and our Ember apps together and making a small JavaScript change or even a CSS change meant a five to 10 minute deploy process for what really amounted to static assets, which is kind of insane.
11:03
So here's a kind of a sketch of the idea. We're deploying our, on the bottom here, we're deploying our JavaScript, CSS, and images, our static assets to a static asset server, serving those out to the browser, and then on the top, we've got our API server deploying, serving up API requests, any kind of non-Ember dynamic pages,
11:21
as well as the HTML for a JavaScript app. And so the question is how do we get our HTML from our Ember dev or CI environment onto that API server? So one possibility is we could simply copy it up to the file system. But in a lot of modern deployment environments, disk is ephemeral, so that's not really a great approach.
11:43
We could deploy to S3 and have our API server kind of read that HTML out of S3 and serve it up. And that's viable, but S3 reads can be pretty slow, and we certainly want this page to be fast, and like we said, to have a very small amount of caching in a mix so we can deploy quickly.
12:04
So what's a good kind of low latency, persistent place to put this? So we already had Redis in our environment, and that turns out to be a pretty good fit. It's not the only fit, but for us, it was a good one. So for example, as an example of how this looks
12:22
as a full environment, this is YAP's implementation with the Rails backend. We've got our HTML being deployed into Redis, our Rails server reading that HTML out of Redis and serving it up, our static assets go to S3 with CloudFront sitting in front as a CDN, and this process turns out to work really well,
12:42
and not only does it solve the problems that we looked at earlier, but it also opens up a huge world of emerging possibilities. So what are some of those? Well, one of the things that we realized really quickly that was possible here is that we could preview before activating. So when we deploy a new build, so a new batch of HTML
13:03
pointing to these static assets, into our server environment, we don't necessarily have to start serving up that immediately to our users. Instead, we can kind of keep it there and serve it up only given a particular query string. So for example, a release query param identifying a particular release that we wanna preview.
13:22
So here, a developer can look at their new code running in the production environment, talking to their production API server before any user sees it. And so the level of confidence that you have when you actually decide to flip that switch is pretty substantial. You're pretty confident that the world is not gonna blow up at that point,
13:40
and certainly when we talk about deployment, we like to take those steps with confidence. So we can also do something really interesting, which is because we have this HTML passing from Redis through our API server or app server to the browser, we can take advantage of that moment and do a little HTML rewriting if we wanted to. Now, why would we wanna do this?
14:01
Well, here's an example. This is an example of Rails controller, obviously works in any kind of backend. On line three, we're grabbing the HTML, and on line four, what we're doing is we're serializing the JSON representation of the current user, and then we're sticking that into a meta tag that comes down with the HTML.
14:22
And what that means for our app is that as it's booting up, it doesn't need to kind of wait and do an AJAX request for information about the current user before it can make some initial decisions about routing. Do I show a login screen or do I route immediately to the content that the user's looking for? And this is just a nice kind of boost
14:42
to that initial experience. And there's a bunch of other use cases where doing a tiny bit of rewriting here can be really powerful. Adding CSRF tokens perhaps, including dynamic analytics params for things like Google Analytics, CUSmetrics, et cetera, as well as embedding dynamic configuration
15:00
to control things like feature flags. That might simply be setting a global that you're consulting to determine whether a flag's enabled or disabled. Closely related to this is the ability to easily do A-B testing. And there's two styles. There's the one using the kind of feature flag style I just described, where you can bucket users
15:20
into an A or a B, turn a feature on or off, depending. The other one we used when we did a kind of full-fledged redesign of our Ember app, and we said, man, it would be nice to A-B test this before we cut over, because there's some dramatic differences. Well, so what if we deploy into two different Redis buckets, so have two kind of current
15:41
HTML paradigms, bucket users into an A-B test using our A-B framework, and then serve one up in a one-to-one group, one to the other. So by the time we actually did fully cut over, we felt really confident that our redesign was indeed an improvement. And finally, I don't love this paradigm as a UI,
16:02
but sometimes it's appropriate. You can use the fact that your server's being notified when a new version of your app is deployed to communicate via web sockets or whatever your push infrastructure is down to your browser to say, hey, there's a new version available. You should refresh now to take advantage of it.
16:21
So all this stuff, what I just described to you is some ideas that I've been talking about for about a year now, kind of in public first at RailsConf about 11 months ago. And since then, a bunch of people have stepped up and run with a lot of these ideas and created open source implementations around them. So I wanted to take a look with you at some of those open source implementations today.
16:45
Now, there's a bunch up here. I'm not gonna go into depth into all of them, but the first thing that I did to start to filter these out was to say, look, we want to be developing apps in Ember CLI, and it makes a ton of sense to be building our deployment tooling
17:00
on top of what Ember CLI already brings to the table. So let's filter this down to just the Ember CLI-based apps. Now, out of these, there were three that really embraced this kind of assets HTML distinction that we talked about earlier, and those three were Ember Deploy, Front End Builds, and Ember CLI Deploy.
17:22
And so I started doing some research and kind of looking at the implementation of each of these and it turns out that Ember Deploy and Ember CLI Deploy share the same kind of idea of having a core plus plugins architecture. And so, for example, if you remember the slide where I talked about deploying to Redis, you may not have Redis in your environment
17:40
and you certainly wouldn't want to put it in just for this. Maybe you have another low latency store, Mongo or Cassandra or even Postgres or MySQL will do the job fine for this. So turns out that both Aaron Chambers and Michael Klein who developed these two projects came to that same conclusion,
18:00
like this should be really, should be pluggable. And it turns out that Front End Builds started life off as a fork of Ember Deploy. And Front End Builds is an ambitious project that has both the client side deployment infrastructure as well as a full kind of Rails engine implementation on the back end for implementing the server side piece of this.
18:23
Ember CLI Deploy has the best name in my opinion, right? Kind of makes sense, that's what it is, that's what you would expect it to be named. And so the Ember Deploy has the biggest ecosystem out of these and it has about four well put together
18:42
plugins to do different types of deployments. Deploying your S3, your HTML file to S3 instead of to Redis, folks, a gentleman from Microsoft contributed an Azure component and so some good momentum around that.
19:00
And so what we did just last week is we pulled together a conference call. We were able to pull it together in about 24 hours thanks to Twitter's new group DM functionality. And on that call we decided to merge these three projects.
19:25
So instead of three awesome projects, each with one or two maintainers, we now have one awesome project with a team of now six people because in addition to Michael Klein, Sam Selikoff, Ryan Toronto and Aaron Chambers who were the maintainers of the projects I just described,
19:43
somehow this is open source, luck would have it. Dan Schultz has jumped in and been an enormous help. I don't even know how he found out that we were doing this stuff. So the team is tremendous and we're really excited about moving forward and we've moved the project from Michael's domain,
20:00
Michael's GitHub user underneath the Ember CLI umbrella thanks to help from Steph. And so we're really excited about making this a well polished, kind of well oiled machine that's going to be kind of the one stop shop for getting deployments set up for Ember apps. And this experience to me is what
20:21
paving the cow paths is all about. It's going from an idea to a few different implementations where we're experimenting with concepts as far as how best to approach it to now kind of coalescing under one kind of Ember approach to the problem. So where are we going from here? The roadmap for the next release is 0.4.0.
20:43
It's relatively a small step. It's making sure that the ecosystem that had grown up around Ember deploy gets moved over successfully to the new name and the new infrastructure and this is pretty straightforward. We want to provide migration instructions for users of the old Ember CLI deploy.
21:02
We're also deprecating JSON based configuration in favor of a JavaScript file so that you can easily consume environment variables for sensitive credentials and so forth. Timing for this is we're hoping to have this released by the end of this week. The roadmap for, awesome.
21:24
The roadmap for 0.5.0 we're really excited about and we're looking for input on this too so you can visit the repo and look at the deployment pipeline issue and chime in. We're looking to move to what we call kind of a pipeline hooks and plugins architecture.
21:40
And it's taking the plugin approach that currently was evolving around Ember deploy and moving it to be modeled really a lot after the Ember add-on approach. And these plugins indeed will be Ember add-ons themselves. They'll get to leverage all the Ember CLI infrastructure that already exists there. We're gonna be adding a post deploy hook
22:00
so that we can easily communicate to Slack or your IRC channel with each deploy. Some nice details, who did the deploy, what time it happened, et cetera, et cetera. And we're looking to provide some great documentation for plugin developers so that this ecosystem can flourish and we'll be providing a lot of support to the people who are looking to add plugins here.
22:22
And finally, Ember CLI front-end builds, which as I mentioned is one of the most ambitious kind of takes on this, is going to become a plugin for Ember CLI deploy. And so that's gonna really help us exercise our API early to make sure that we're arriving at the right ideas. And the basic architecture I kind of alluded to just now,
22:41
Ember CLI deploy plugins will be Ember CLI add-ons with an additional keyword. They'll be auto-discovered, auto-wired up. You'll obviously need to provide some of your own configuration to be able to successfully talk to these, the backend services involved in your deployment. The goal is that you be able to deploy from either your development environment or from your CI environment.
23:01
So there'll be both some nice interactive tools to work within the command line as well as kind of silent headless tools. And the plugin kind of hooks that these plugins can implement are listed here. Will deploy, build, update assets, update index, activate and did deploy.
23:20
As well as list, which lets you look at your most recent deployments and choose to activate a particular one, roll back to a particular one. So the basic usage pattern will look like this. You will have configured one or more deployment targets, be able to say, Ember deploy staging. That will deploy your assets and your HTML
23:40
to the configured staging deploy target based on the plugins that you've got in. You'll activate the release and notify your group chat. Made a mistake, you can use Ember deploy rollback staging. Rollback to the most recently activated version, also send a notification.
24:02
Want to consider what you should be releasing? Ember deploy list is going to give you a list of recently deployed things for that target. It's also, hopefully for most plugins, going to be able to give you a preview URL like I described earlier. So as a developer, you can grab that, take a look and have one kind of sanity check
24:21
before you decide what version of your Ember app to activate. To actually perform the activation, you'll pass this identifier to Ember deploy activate. And that usage, everything I just described, is not something, some of it exists today in 0.3.0 and will exist in 0.4.0.
24:40
A lot of it is going to be changing somewhat for 0.5.0. So again, looking for input. Those of you who have implemented deploy solutions yourselves, and I know everybody in this room who has an app in production has done that, talk to us about what you would love to see. Beyond 0.5.0, we would like to support deployment
25:02
to named buckets to support the kind of A-B test and beta testing things we've talked about. I'm sure that you've used apps where they allow the end user to kind of toggle between classic and beta, right? So that you can get people starting to experience a new version without necessarily putting them at risk because it doesn't have all the features
25:21
that your current version does. We would like to be able to deploy that, support that scenario pretty cleanly. And then beyond, also beyond 0.5.0, I've talked to some folks where deploying the HTML is not a great fit for them. It makes more sense for them to let their servers continue
25:41
to kind of render the overall HTML, but instead we want to be able to deploy configuration information. So what are the JavaScript assets? What are the CSS assets? What are the configuration options that I'm taking kind of from my static build and then letting me and the server merge them with the configuration options that my server is driving to be able to produce this page.
26:02
Cool, somebody likes that one. And let's see, we just talked about this one. Did I miss one? No, that's the same slide, c'est la vie. So in addition, as I said, your use cases, your ideas, come talk to us.
26:22
To me, this experience over the last year and then in the last week has been really emblematic of what I love about this community. When we got on the conference call last Tuesday, we had five people on the call that most of whom didn't know each other,
26:42
hadn't had a ton of conversations together. Because we have a common mindset from what we've learned by watching the Ember project evolve, we have a common set of tools that we've become good at using from Ember CLI to GitHub to Slack to IRC. We basically were able to make some decisions together
27:01
that this merge was the right move and be productive as a team in literally a matter of minutes. It was a pretty astonishing thing and really kind of this paradigm, which I know a lot of you have experienced in open source already, is unparalleled in the history of humanity. So without getting too high fluting on it,
27:24
it's pretty awesome stuff. So one last idea that I wanted to just throw out as stuff that we can talk about later, how does this work with fast boot? And so I don't have all the answers to this. I've thought about it not too long, but one possibility is that in this scenario
27:42
is that your fast boot server could sit in front of your API server. It could be reading HTML from that API server, proxying API calls back, and caching your JavaScript locally. And so there certainly is a simpler scenario
28:02
for a fast boot server, but if you want to take advantage of all the possibilities that I described earlier, we may want to consider having a relationship between our fast boot server and our API server that's a little bit more robust. But so anyway, this idea is something that I would really love to talk about at the party or later today with folks, so be thinking about it.
28:21
And with that, this is attributed to Steve Jobs, I don't know if it's true, but real artist chip, real artist deploy, and thank you to everybody who's kind of helped make this particular journey possible. It's a small story and kind of the overall arc
28:40
of the Ember story, but it's an exciting one and one that I feel really lucky to be a part of. So keep in touch, join the fun if you're interested in this stuff, and if not, just get ready to take advantage of a nice new convention for the community. Thanks.