 Thanks. I'm Aaron. I'm going to talk about Ember Seal I deploy, but I guess first a couple of facts about me, who the hell am I? I don't know most of you guys, so I've been a developer for about 13 years, mainly JavaScript and Ruby. In prior life, Java and then Lotus Notes, but I try not to tell too many people about that. Don't hold it against me. I've been doing Ember since about May 2013. I met Jamie at Ember Hackday way back when I just first read about Ember. It sounded pretty cool. It seems like a lifetime ago now. I'm nearly married and as is customary for my talks, you get a NOAA update. Father of this little fella, NOAA, is awesome. You can't code yet, but I'm working on it. Basically, I wanted to talk about Ember Seal I deploy. This is just an Ember Seal I add-on that I've just been working on. It's inspired by Luke Melia's talk they did at Ember Conf this year called Lightning Fast Deployments of Your Rails Back to JavaScript Apps. Has anyone seen this presentation? A couple of people, not many. If you haven't, then I'd totally recommend checking it out. There's a link there. I'll have it on the end of the slides as well. You can grab it later on anyway. Just out of interest before I go on, who here has an Ember App in production? Just out of interest, about half, a bit more than half. How many of those are backed by Rails? They use Heroku and deploy it the way we always do. How many people use an Ember Seal I or AppKit? Cool. How do you guys go about deploying those apps just out of interest? Is it a manual to push it up, a bit of a shell script? Do you have a shot using Robert Jackson's add-on? Cool. I guess for me one of the things that I wasn't really clear on is a good way to deploy, but when I watched this presentation it really made things clear. I'm not strictly talking about Rails here. I don't care about Rails and talk about Ember Seal I, but I'm using the principles that Luke's talked about here in Ember Seal I. I guess basically deploying to Heroku is cool. Serving from Rails, it's cool, but it can be slow, which is something that's a bit of a pain. One of the things I find important. We've been doing it for a long time and I think we can do better. Basically the idea of Luke's presentation is something along the lines of this. Currently this is my sketch, graphic design skills, so please bear with me. Traditionally we have Rails app and it will give us a bunch of HTML when we hit it here, which will point to some assets, JavaScripts and CSS and images that are also hosted from the Rails server. Computer requests them from Rails and we have our server-side web app. If you're thinking more about speed and caching and stuff, you might bring your assets out to something like S3. Again, we'll hit the Rails server. That will service our starting HTML, which will then point to our assets in S3. That's pretty standard for how we do web apps with Heroku. If you're using Ember Seal I currently and maybe you're using the build pack that is described on the Ember Seal I.com website, it basically fires up an Nginx web server in Heroku. When you push to Heroku, the whole compile process builds your Ember app and then deploys it for you. Much the same as the original Rails thing here. I guess we've got the web server giving you HTML and serving the assets. What Luke goes to talk about is what if we push it a bit further. Now that we're using JavaScript-based apps, they're just static assets. We've got an index HTML file to bootstrap the app, which then calls for a JavaScript file and a CSS file, a few other things. What happens if we put our assets on S3 like this? Instead of having web server get a file off the file system, what if we put the index file into a Redis database into an in-memory store? We just had a small Express app, in my case Express. In Luke's case it was Rails. It could be a Sinatra app or anything that just pulls the index HTML from Redis and serves it back to you. Now when we hit our app, our Express app just goes and gets the content because in the Ember Seal app the index HTML is only tiny. It just bootstraps the app. This is the app here. It can point to the assets on S3. Is there anyone with me so far? Yes? What we do is we put the HTML in S3 and what's the advantage of doing the Express app? We'll hopefully get there. And it's not the only way. As I said, this was inspired by Luke's talk. I've started implementing that and the idea is you can put it wherever you like. Let's push this a step further. Hopefully we'll start to answer your question a little bit. So what happens if we now push a branch and we start to store our HTML in Redis with a key based on the branch name? So here we'll store the current version of the HTML and here for my feature branch we'll store a different version which points to different assets because I've made some changes in my branch. What this allows us to do is we can put a query parameter on to the end of our production URL here and our Express app will serve a different index HTML file based on that query parameter. So I'll explain more about this and I'll show you a demo of what the actual add-on does. But what this allows us to do is it allows us to start deploying branches to an environment, maybe in production, that aren't accessible when you just access it normally, need to pass a query parameter in, which is really cool because cutting over is literally just telling the Express server now to point to this index file instead of this one here. Does this make sense so far? So why? So I guess some of the neat reasons I think this is cool. It's fast deployment. So Heroku takes time to compile everything, to build everything, build the slug. All we really doing is smashing a few files together. Chucking them in S3, chucking them in Redis, which is super quick to do. Deployment becomes super fast. Does anyone here do continuous deployment? And I mean every commit you make goes to production. Yeah, this makes that kind of easy as well. Especially if you think maybe you don't want to go continuous, continuous, maybe you want to make something available every week, but you can still have your code in production running. It can be tested by or accessed by your other dev team. Maybe your stakeholders want to look at it. All they need to do is put a query parameter on to the end of the URL and they get served the new version of the index HTML, which then points to the new version of the assets. Seamless cut over. Because your app's now deployed to production, it's just a matter of telling Express, change the current live one to be this other version of index HTML. And you can start to deploy your branches. I don't know if people use branching much in the dev workflow. But I use it all the time. I deploy everything to local branches and use pull request to bring stuff in. So I figure why shouldn't my branches run my whole test suite as well? Why do I need to wait for it to get in the master to know that it passes all the tests? So this way, as I push a branch up, it can get deployed as far up as I like, have all my screenshot testing, smoke testing, integration testing, whatever I like run against it. So I guess there's the how. So this is where my add on comes in. So has anyone written add ons or used ember seal add ons? Cool. It's freaking amazing. I love it. It's awesome. So basically, for those that don't know, it's just an MPM package that you can build, which you install like you normally would MPM install. And as you fire up your ember seal I app, it automatically boots that that package, whether you're injecting new components into your app. In this case, it's adding commands to the CLI. It's really powerful. So to use this again, yep, MPM install ember CLI deploy. Boom done. And at the moment, this is early days. So I'm just working on this just just by myself, as I get time, having weddings and babies and stuff leaves you with less time than I used to have than I used to. So there's more to come. But at the moment, we've got command to deploy your assets. So this will literally is push your assets test three deploy index pushes it to Redis at the moment. And then the activate is what you use to switch to a particular version to make that one the current live version. So hopefully I can show you all that in real time. First, can everyone see that? Okay. Shall I make it bigger? Silence is always good. So this is literally a brand new ember CLI app. The only difference is I have just added a config file. So we'll need that in a second for ember CLI deploy. So the first thing, actually, let's just have a look at it. Shall we? So this is what you get your bare bones out of the box ember CLI app. Cool. So first thing I'm going to do is install ember CLI spell it right. So that's done. So if I type ember help now, what you see at the bottom here is available commands from ember CLI deploy. So I've injected a bunch of commands that you can run from the CLI into ember CLI. So every time it runs, when it builds, when it serves, when it runs help, whatever it hooks into that add on. So as you can see, we've got ignore that because it's not implemented, activate deploy assets and deploy index. So there's a couple of things that we need. This relies on config file. So basically inside a deploy directory inside your config directory, you need to drop a file with the environment that you want to deploy to. In this case, we'll just say development. It just needs to export a few things. Mainly, the credentials for where your assets are going to go in this case, s three. And credentials for where your index HTML is going to go. In this case, it's Redis. So we'll leave that there for now. So seeing I have a bucket set up here on s three. There's nothing in there at the moment. So in the London demo. So we also need to build a app. What you'll also need to do in your broccoli file is add this fingerprint prepend. So what this is going to do is prepend the location where your assets are going to live in the index file, any images you have. Because we're going to be storing them on s three, which is different from where the index HTML is coming from, we need to just prepend that with the bucket. So I'll show you what that actually does in a sec. So if we just want to build our app now, and the build environment production. So now we have our disk directory with our assets. You can see our index HTML is pointing to a style sheet at the prepended location on s three, which is where it's going to end up. And that'll be the same for any references to images in your CSS. So now we built a project. So imagine this can be happening as part of Circle CI or something like that. This is not, I'm not seeing this as a manual thing to do, but you can do it like that. We've got our credentials for s three. So we can just deploy our assets. There they are there. We can obviously put cloud front in that in front of that, we can catch the crap out of it and just keep dumping assets in there. It's just a bucket. I don't care about cleaning up at this point. We can just put any versions of any assets in there we like and our index files will point to the right ones. Next, we want to deploy our index HTML file to a Redis instance. Now I don't actually have one currently. But there is a little cool thing. I think this is pretty cool. It's a little Express server that I've created. Has anyone seen the deploy buttons in Heroku before? Yeah, this is really cool. You can now add this. If you have an app.json, this is kind of a side note. If you have an app.json, which basically explains what your Heroku instance should look like, what add-ons it has, what environment variables, chuck one of these bad boys on there. And straight away I'm into the screen to create a new instance of this app for myself, which is pretty cool. That's a default GitHub name there. So this is all work in progress. But let's just create one called London Ember Server for instance. So you can see I'm provisioning New Relic paper trail, but the main one is Redis to go. So this is where our Redis store is going to be. It doesn't have to be, but it makes it easy for this at the moment. So if any of you guys wanted to use Ember Sela to deploy, all you need to do is click on that button. You create your own instance of this guy and you've got your Redis server ready to go and you've got your Express server that will serve your index HTML. So let's just crank one of those out. Am I going too quick or too slow? Cool. So that now exists. You can view it. There's actually nothing there at the moment because there's nothing there. And so what we just need to do now, we need to go back to our config. We just need to put in the credentials for that app. So config London server. Did I not call it that? London Ember server. And here's a Redis to go URL. So we'll just take Redis to go. So we have this password, which I'm going to check. Right. Cool. Thanks. That would cause me endless grief. Green eye. Redis to go. God, what to do there? Oh, geez. What is going on? There we go. Green eye. Redis to go. And we have 11938. Cool. So obviously, just need to do this once. This is our configuration for our Redis server. So we now want to deploy our index. Redis to go.com. Did I do that wrong? Awesome. It worked the 10 times I tried it. It's always the way, isn't it? Redis. Green. No. Shouldn't be. That's about the right number. No. No. In case it's in firewalls. There's some Wi-Fi coming up with this if you want to jump onto it. Yeah, I've had that problem. Okay. So Jamie's iPhone should appear at some point. Okay, come on. There we go. Jamie's iPhone. That's a pass with it. Okay. Frisbee. Come on, baby. And we're away. Cool. Awesome. So we've just pushed our index HTML file to Redis. I'm just going to activate that and I'll explain what that all means after. But essentially what we can see, what is it for password? Is it D? That is not working at all. Is that the right host? Oh, did I not do that? Oh, sorry. Yeah, you're right. Yeah, man. It works every time. Oh, Jesus Christ. Yeah, yeah, yeah. Is it minus P? Yeah. Can I get the keys? North request. This brilliant port password. Okay, let's try that again. Connected there. All right, fair enough. Yeah, I'm going to deploy index. Into where? Where about sorry, man? What do you mean number CLI? Oh, sorry, gotcha. Gotcha. Yep. Cool. No. That's right. Well, that's really cool. I'll put my original change in. All right, so let's make a change. So it actually uses the current git hash as the key. So we'll just commit that guy. So we want to build our app to play our assets, play index, hopefully activate our index. So this is just telling the express server that this is the current one. No, it's not going to work. What that would have done was marked that index as being the live one. So when I went to this URL, that's what I that's what I was seeing my app. And so the idea being that when I make some changes to my app, I could then deploy those and it will deploy it with a key of the current git hash, which is obviously different because I've made changes and I've committed this. And I would access it by putting key equals 12345 whatever my whatever my git hash was. So the express server will look for that query program. If it finds one, it then goes to read us and ask me for that version of the index HTML and serves that back to me. So this is I think this is really cool in terms of you can you can put this into staging or even production like environments if you really want. And you can access your your new features before actually making them live. Then the ember activate command will literally just say activate this is hash and make this the active one. So when I come to the root URL, that's what I get served. Sorry, I couldn't show you the actual demo. Okay, yeah, yeah, I got nothing. I don't know what's going on there. I literally tested that like every day for the last five days and it's worked every time. But wouldn't you know? Hope I was able to get across the intent there. So I guess what's next? Basically, this was sort of a first iteration, it's hard coded to read us hard coded as three, the stuff I'm doing now and I just finished it the other night. I haven't pushed it in yet is I want to pull the the the code for the data stores out to adapters. So I've actually created a Redis adapter which is another ember seal I add on. So there's no logic bound to any type of store or anything like that in ember seal I deploy itself. So if you want to deploy to Redis for your index HTML file, all you do is install this other ember add on and ember seal I deploy will actually inspect the list of add-ons that are installed and find that adapter and use it so you can easily create your own adapters for any data store you like. If you don't want to use Redis, you can use whatever you like. And ember seal I will automatically pull them in as long as they sort of meet the contract and the interface like the index HTML adapter needs to have an upload method and a set current method. As long as you do that, then you're good to go. And it's literally a matter of just npm installing that adapter and ember seal I deploy or do the rest. More commands. So I'm going to wrap all the deploy assets index and activate or deploy assets and index into sort of a deploy command because that kind of makes more sense I guess. I also want to sort of add versioning so you can see the last list of versions you can roll back any number of versions kind of like your migrations in Rails I guess. And in the versioning also because it's based on the git hash I can check out your your your git history and we can maybe put the git commit next to that so you can kind of get the context of what that actual version is. Also want to be out of version by branch names and not only the git hash which is hard to remember but also you can pass in the branch name as the key because if you're constantly pushing to a branch then it's a lot easier to remember that. And anything else that that you need really. I'm just sort of adding I've actually had quite a few people putting pull requests in and stuff and that's how these things become awesome by people using them. So if you want to have a crack at it and want to suggest anything by all means if you want to put a pull request in that would be awesome. So questions. Why do you need to do it? Yeah, but yeah, I don't mind it hasn't been a yeah, you're right like we could do that. Yeah, but if on the list of what's kind of important at the moment that's not really I don't mind it's a bucket that's what it's for store a whole bunch of stuff in there. That's cool. Yeah. Well, you could do that you could write an adapter to do exactly that. And that's the whole point of the adapters I guess. I don't know I guess. Yeah, it's an in memory store. I guess you're starting to do file file system sort of stuff renaming files maybe to see which one's current or moving around directory structures this is literally a key and a value. And there's no reason why HTML file has to be a file on a file system why not be just a piece of data in a memory store. Other than that, I don't know. That's kind of how Luke sort of suggested it. So that's the first path I went down to just kind of feel out the idea see how it feels and it works pretty good. I mean, I've got no problems with it. So yeah, if you wanted to put in something else, you can write an adapter easy enough for that now. Yeah, no, yeah. Yeah. Also, I guess, sorry, Leon. With Redis what I also do is I yeah, I store it there against the key but I also store a list of the current of the previous X amount of versions so you can roll back a list and all that sort of stuff. And when you start thinking of that, that's just another entry into Redis with a key and a list, which I can just pop in new hashes into so I can easily inspect that see what the last 10 versions were which I'm just starting on that S3 becomes a bit more of a pain. So I guess that's that's a benefit. Yeah. Yeah, could be. Sounds good to me. Yeah. Yeah. I hadn't really thought down that path. So but yeah, it sounds like yeah, you do. Yeah. Yeah, that's right. Yeah. Anyone else? Yeah. Jamie not where we work currently, but that's the plan. And I'm sort of using it as my own stuff as I'm kind of writing it. But if we get time, we will be using it. But I've actually had a couple of people raised pull requests and issues that are using in production, which is kind of cool. But that is a plan in the very near future. Huh? No, no, it doesn't matter. Anyone else got any questions? No. Cool. All right. So some of the links. That's embassy a lot of ploy can MPM install it. This was the express server if you wanted to use it. Fork it, change it, whatever. And that's just a small link to Luke merely as presentation. And I've been married. So thanks for listening.