 Thanks For those of you that don't know me already. I'm Aaron When I'm not building JavaScript and Ruby apps. I'm a father to this little fella Everyone that sees my choice gets a gets an update. That's Noah. He's pretty cool. He's got a little 18 months. He's got a little brother or sister coming in two months. So I think he's about to get a whole lot more hectic I think So I just want to give you guys a bit of an update on embassy light a ploy and where it's at So I talked about this. I don't know how long ago now over a year. I'd say In the early days, but since then a lot a lot's happened So I just wanted to sort of tell you where it's at what's going on Firstly, I guess is anyone does anyone not know what embassy light a ploy is not heard of it One person. That's two people. That's cool. That's good. Is anyone here using it in production Three people cool cool. Hopefully there'll be more in a few months So first I guess a little bit of history then about what it is back in 2014 I Kind of struggled to find a real definitive way to deploy and perhaps I was pretty used to being able to sort of get push on a Rails app and then Heroku would Would build everything and then spin it all up But in my head I just didn't really have a nice definitive way on how to how to deploy an ember app and I did quite a Bit of looking around and I'd sort of see all these different ways It seemed to me like a lot of people basically deploying stuff to production from there from the desktop our syncing stuff Just manually copying test 3 which didn't sort of feel right to me I Kind of wanted some sort of way to just type something in a command line and and have it deploy And so last year, I don't know if anyone knows Luke Melia say most you do He did a talk at rails comp and it was titled lightning fast deployment of your rails back JavaScript apps And he just sort of described how his company yapp labs deploy things They have a an ember app backed by rails and for those that haven't seen this I don't understand that concept Essentially what they do is they build their static files. They push the index html to redis And they have a server that pulls that out of redis and serves it and they push their assets to s3 And so obviously the index html file points to the s3 assets and boom where you go So that gives them a lot of power to be able to deploy super quick. It's just copying a couple files Along with other cool things like being able to sort of activate different versions show different versions in production by just adding Query parameters to the URL So this is just their strategy, but I saw this as like actually that makes a lot of sense to me I think we can sort of Automate that in a pretty nice way and so This was called lightning fast deployment. So this is kind of being coined in a way Referred to as the lightning approach sort of since then So I sort of just mucked around I had a few different iterations with grunt tasks and stuff But it ended up on a on an add-on for embassy a lot of embassy a lie called embassy a lot of ploy I had to sort of command lines where you could deploy the index to redis deploy the assets to s3 So enter 2015 And a few other people had done similar things. There was quite a few open source implementations of deployment stuff of this lightning approach And that was really cool. So we're all basically trying to suss out the the idea kind of Sure up some some conventions and understand what people want to do out Of out of those These are the ones that were a kind of embassy a lie based So we got embassy lie deploy front-end builds ember deploy and a couple others here the heroic could build pack some most people probably use that If you look at if you will it down a bit more these guys these three kind of embrace that lightning strategy of deploying to redis and s3 So Then it started to look a bit deeper into this and all of a sudden you can sort of see the embassy a lot of ploy and another one Court ember deploy, which is also an embassy a lot on By a guy called Michael Klein. They basically did exactly the same thing. They were using the same idea of a core Core add-on plus the ability to add plugins for different different deployment methods This front-end builds was essentially the same thing again except had a bit of a rails front-end So you could see visually on your screen you different deployments and activate different ones And that was actually a fork from ember sealer deploy So you kind of see where we're going here. We we had a few of us all trying to do similar thing in different projects Ember sealer deploy had kind of the best name based on the conventions on how we how we name add-ons at the moment. So and Ember deploy had the biggest ecosystem out of these things it had a bunch of different adapters So while you could deploy your index to read us there was someone wrote an adapter to deploy it to s3 instead So what happened was at the start of 2015 Luke Melia got in contact with us Maintainers of these three projects and kind of said I'm going to do a talk at ember comp it's called the art of ember deployment and I want to talk about kind of coming together as one and having the official deployment tool called ember sealer deploy What do you think so we basically within the space of 24 hours jumped on to a hangout International call across the world. I think Michael's in Austria somewhere these guys are in the States and I was in London And we basically agreed that we'd come together and we decided to merge things into ember sealer deploy So essentially we have one team one project and now one command to deploy them all This is where a hobbit jumps out, but my keynote skills aren't that good So we now have ember sealer deploy add-on which is underneath the ember sealer Organization to github and that's kind of the I guess official way to deploy apps So Currently we're on 1.4 x which is what most people that have used it know of ember sealer deploy And it is heavily heavily focused on that whole lightning approach Which is put your index in Redis put your assets in S3 But as a lot of people sort of told told us over the time that's not necessarily how everyone likes to deploy Doesn't work for them. They don't want to do it that way or they they have other ways They prefer or other ways they've already they're already doing so it was a little bit inflexible in that respect But it was cool because it it kind of it did its job It it proved out some concepts proved out some good workflows I know I've chatted to Brian a lot about his crazy deployment setup And it definitely doesn't fit for that so where Zeroed at 4.x was sort of very heavily focused on Redis and Amazon We started to see that we've got all these other options here people deployed a dib shot so Azure firebase GitHub pages fastly Anna Brian's crazy setup that I mentioned So So Which I love to talk to you about and now Brian after this at the bar. Yeah So this kind of brings us to zero dot five that oh, which is what I really wanted to talk to you about So we've re-architected it pretty much completely and with the view of being able to just deploy to anything you want So any deployment setup scenario you have you should easily be able to use that with the hope that Ember deploy is going to be much easier than any script you've already written and it's kind of a no-brainer That's the that's the that's the idea So what's a zero dot five dot zero so basically it's a deployment pipeline So before it was literally just a command that would do some stuff like build your project do some stuff to push your index to Redis Do some stuff to push your assets to S3 But we've brought in a pipeline which is kind of a little bit like backburner if anyone knows the back burner Micro library which kind of backs the ember run loop We've got a new plug-in architecture So it's really easy to to create your own plugins if they don't already exist to allow you to do things And I'll go through what that means and we're working a lot on documentation for this to make it easy for people using it and Easy for plug-in authors So as a refresher We'll use the example of the lightning approach to understand how the deployment pipeline works and In future talks it'd be really good to take other examples how you guys deploy stuff and show you how you might do it But for now we'll just take that lightning approach because hopefully we kind of understand the gist of it So essentially we have our Redis and Amazon services We have our CI server or our dev machine and we build our files Which essentially produced to a number of static assets One being the index HTML one being JavaScript CSS images all that sort of stuff And in this scenario we push them up to our respective services So the 0.5.0 pipeline basically looks like this It's it's got a number of hooks that are executed in sequential or what it started from configure to activate There's actually a few more, but this is kind of a general high-level idea So using 0.5.0 is as easy as just installing the plugins that you want to use So they're just dependencies that each plug-in is an ember CLI add-on So you can see there we've we've got ember CLI deploy and install plus ember CLI to deploy build Redis and s3 So they're all just plugins ember CLI add-ons And then in your config you pop it deploy js file Which literally just shows the config specifies config feature those plugins namespace by the Plug-in names. You can see the build Redis has the host and port s3 has the access key ID That's pretty much all you need to get going Run ember deploy production and essentially what happens is ember CLI loads up all its add-ons ember CLI deploy inspects those add-ons and finds out which ones are plugins and then goes ahead and registers the The hooks that they've implemented so ember CLI deploy build has implemented the configure in the build hook So it's registered those against those hooks there next up ember CLI deploy Redis has implemented the configure upload and activate hook so therefore it registers those guys and Finally ember CLI deploy s3 implements the configure hook and the upload hook So these guys are all configured and then it goes along and basically just executes the pipeline starting at the top all the way All the way through the configure pipe into the build and so on so forth So essentially what happens is we go through them all and you'll see this green green circle Being passed to each of the the plug-in hooks and it's getting bigger So this this represents what we're calling like the deployment context Which is essentially a JavaScript object that's passed to each of the hooks as they're executed So what this allows is plug-ins to add stuff to the context to allow other plug-ins further on in them in the pipeline to Access that data. So an example of that for instance is the build Plug-in puts a list of all the built files so that plug-ins down here can can see what files have been built There's all sorts of things. I know like Brian configures root 53 something or others He might have a plug-in that that does that and then there's some some dynamic name that was created from that He can pop that onto the context. That's then passed along and any other plug-ins running after it can access it So that's what this green green dot basically represents So the pipeline just goes through and executes each one of these hooks until we get to the end and Your thing is deployed. So this is a list of All the all the hooks that you can hook into It looks a bit unwieldy But they do make a lot of sense and for the people that are really familiar with ember the conventions are pretty similar You've got your will do something do something and then you did do something kind of hook. So The first one is configure this this is where you can so just make sure that all the configuration that your plug-in needs is present And so that any of the hooks running for that plug-in afterwards have everything they need to run Set up hook kind of just runs at the start of everything. You might open an SSH tunnel I know someone's written a plug-in to do that. So this is a good place to do that After that we have a will deploy hook Do anything you really like there. You can maybe notify slack to say I'm about to deploy There is a plug-in to send stuff to slack channels Next you have your your build hook. So they literally run in this order It goes configure set up will deploy and then it will run the will build hook for each of the plug-ins The build hook for each of the plug-ins and they did build hook So you can sort of confirm your environment here You can build will build the project files And then you can kind of complete and confirm that your build is all all finer ready to go in the will build hook Then we give you prepare hooks Now running that order as well. We'll prepare prepare and did prepare We use this one for kind of preparing some data about the deploy so the If you want to generate a unique route revision key for this particular deployment or maybe grab the Committer and the timestamp and the commit message and all that sort of stuff This is where you can prepare some metadata about the deploy these rotors hooks You can you can hook into it your own unless you can do whatever you like in them But these are just examples of some things you can do with them The upload hooks are sort of intended for the actual pushing of some files somewhere So you notice it's not specific to assets and index anymore Which is what the lightning approach was it was all about push your index to Redis assets to s3 But now it's just like upload something so you can have two or three different plug-ins That all upload different files to different services. They just got to implement the right hooks You do Yep, yep, so you do so I'll cover that in a little bit You the developer consuming embassy a lot of play So I'll go into that in just a sec Finally we have a concept of activating so this is kind of in a way specific to this lightning Method where you could push an index file to Redis, but not actually activate it So it's not really live yet, but then you can run a command later to actually activate and make it live So this is this is just some hooks to be able to do that sort of thing If you don't want to if you want kind of push it into the production environment Maybe access it by putting a query parameter on the end of the URL But then you want to activate it at some later stage to do basically a zero downtime Deploy you can do that Then we have a did deploy and a tear down hook where you can again notify slack that you've deployed something Things like that. So that's it's a big list But these are all the sort of things you can hook into along the way you can do one or many of them You don't you don't need to do them all that's for sure So a bit about what a plug-in looks like It is just an ember CLA add-on so ember add-on name of plug-in It's basically got three it needs three things it needs to be an add-on It needs to contain the ember CLA deploy plug-in keyword So ember CLA deploy when it runs it looks at all the add-ons that have been Loaded by ember CLA and looks for that keyword there and identifies that as a plug-in Has anyone created add-ons to are you familiar with the the layout of an add-on? some people essentially it's just It looks similar to a Project layout, but the main thing is it's got an index.js file. That's kind of the the hook-in So the only other requisite for a plug-in is that it implements a create deploy plug-in function And this needs to return an object which is essentially the hooks that you want to implement so you can see This plug-in here implements the configure hook and the upload hook It's pretty easy, so you can add one or many hooks that you want to implement there So the idea is you run ember deploy production Ember CLA deploy goes through all the add-ons finds the one that has the plug-in keyword Has that list and for each one of those guys it executes this create deploy plug-in takes the results and Then registers each of the hooks that you've implemented into the pipeline And then executes the pipeline the hooks in order boom. It's pretty basic really But it gives a lot of flexibility So we touched on the deployment context a little bit So this is literally just a JavaScript object so you can see when you implement a plug-in. Sorry a hook It receives one argument, which is this context object so any hook can can dive into this object and Look at any data that's been added to it by any hook that's run previously And then anything that's returned by a hook will be merged into the context so you can see the context is empty at this point It gets passed in the build and the build returns an object with a dist property And that's merged into the context so that'll then be passed through to every other hook that's run afterwards So this is really cool. It allows plugins to kind of talk to each other send some data along and Yeah Configuration is pretty pretty easy. Basically. You just need a file called deploy JS in your config right next to your environment JS looks exactly the same returns a function Actually, that's the environment not options just like your environment JS And this just needs to return an object that has Properties that are basically namespaced for the for the plugins you're going to use so embassy a lot of players 3 is installed So we have an s3 property there with all the config for s3 Redis you'd have a redis property so on so forth. It's pretty pretty easy Yeah, so it's exactly the same as your environment JS So this is actually as I said the environment thing so you can say if environment equals dev then Then s3 credentials of this or you can use Like environment variables so it loads them out of the box You can actually have a dot-m file for each environment in there and it will load them up by default as well This is a few different few different ways you can do it. Am I making sense so far? Going too quick too slow So what you can do so that's the basic use case and this we're gonna start looking at a few things that maybe more power users would Would do so essentially embassy a lot of play will run the plugins in alphabetical order Which is the way embassy a lie loads them from the node modules package But if you want to to change that order override it you can add a plugins array just at the top there Which then specifies what order you want to run them in? So that will specify the order, but it will also specify which plugins are run So you might have four other plugins installed, but they won't be run only s3 and redis will be run at that point So that's sort of just a little bit away. You can kind of customize it a bit more And override the order that they run You can also alias plug-in. So this is so in answer to your question Brian like you would you would specify? In the different plug-in what what files so like say at the s3 plug-in for instance has a file pattern property So you can specify what files you want to do this here allows you to to create multiple instances of the same plug-in So we want to create two instances of the s3 plug-in. We're aliasing it as foo assets and bar assets So you might have J s files you want to send to this bucket and Then css files you want to send to this bucket So we're going to use the s3 plug-in which pushes stuff to s3 But we're going to have configuration for the foo assets alias where the bucket is this one and then the configuration for the bar assets Instance which is going to push it this one. So it allows you to to be more flexible and do exactly as you asked there and The config doesn't actually just need to be static Data we actually you can pass a function into any of the configuration properties and it will be Executed at runtime and past the current deployment context. So For instance, if if I have a plug-in that runs that does set up Brian's root 53, whatever Or cloud front distribution and there's a particular name that it's being given I can pop that onto the context and then a plug-in later can run a function It can set a function for the config thing that will have that context passed into it So at runtime Whenever the the hook is actually run for that for that plug-in it can access that that property of the context So that's that's makes it a lot more flexible and gives you a lot of power to be able to Do things dynamically at runtime So currently these are the lists. Oh, I made that a bit too light. Anyway This is the current list of plugins that we've built for 0.5.0. They they actually exist We're using these in production a bunch of us already are so it's good to go and love to get your feedback If you're if you're into this sort of thing I won't go through them all but I guess we've got one to build things Got one to deploy to Redis s3 One to build a manifest so that we you don't need to push everything to s3 It'll actually check a manifest and only push the stuff that doesn't exist already G zipping So you can see the the plugins are really designed to be made to do one thing Really well and only one thing So you can make them quite small and then you can just plug and play so I only installed the gzip one today because I hadn't gotten around to it We needed to gzip and I literally just did an ember install Ember seal I deployed gzip and all of a sudden my deploy process was gzipping everything and pushing it up to s3 It was pretty cool. Actually, um, john had to merge the pr and he was pretty surprised at how easy it was And it worked as well So I guess these ones like this one's kind of cool. Um, I actually use this in production at the moment. We had Um, we're using the lightning approach, except instead of press Pushing index html to to retus web We want to be a bit more dynamic about that and we we're pushing the all the interesting stuff That's in index html as a json blob So that then our rail server pulls that down and can merge that into an erb template instead of the html already being Defined by the ember app. So, um, that's pretty handy that gives you more more space there to kind of template yourself All you've got is just the information and where the assets are the configuration and all that sort of stuff So these things are all available to use And documentation, um Is here at the moment. We haven't got a domain yet, but we're we're kind of giving that a good crack Um, and that'll that'll sort of really start to build up once we've done the the next few features So you can try it out today. It's um, it's just in beta at the moment. You need to chuck the version on the end Um, but you can you can install it Uh with 0.5.0 dash beta dot 1 um Love you to try it out and poor requests are always welcome contributions are always welcome advice bugs all that sort of stuff any suggestions Um, and if you got anything you want to talk about in regards to this or anything else, um, i'm going to be the bar tonight So Love to chat about it. Be awesome Does anyone have any questions Alex No used we we write our own, um So yeah, basically I think I don't know if it really fit fully, but we have written it so that the pipeline itself is not ember See a lot of place specific the idea is that we will pull it out into micro library If we can use backburner, that'd be even better But I don't know if it's a good if it's the right fit But yeah, it's um, we are we have written it so that we can pull it out which we'll do at some stage in the future Brian Yeah, so that's yeah, sure. Yeah. I mean, that's just another command. Um, we've got all the ability to do it It's really easy. It's just we've not done it. We're just really trying to do Basically parity with zero dot four to zero for starters and that's going to come That's definitely on the my list of things. I really want to do so Yeah, yeah, yeah, so basically anything that's returned from a plug-in, um, is promissified So if that rejects then we can we can easily hook into that and roll stuff back. So Yeah, we can definitely We're definitely planning on doing that and just having like an ember deploy rollback Revision number or just roll back how many steps or how many revisions or whatever I'd say it's all in the pipeline It's just we haven't done it yet. Yeah, it's coming So that's a whole other chat I guess like be really like it's a really interesting presentation alluded but I guess one a couple of good things that gives you it it allows you to push multiple versions Up and you can basically add a if you want you can add a query parameter to to the url And just show a particular version so you can actually deploy stuff to production And test it and run it without it being the live version, which is which is really powerful So ab testing sending stuff to like stakeholders so they can look at beforehand and you're actually deployed to production But it's not the live version And you know, it's it's it's quick It's it's pushing something to to a low latency data store and it's pushing a couple things to Redis You think like what they were doing before and what a lot of us probably were doing Maybe had everything bundled in rails make a css change You got to push it up to heroku. It builds for five minutes and then does whatever it needs to do So Those are just a couple of the benefits they sort of got from them. I guess Yeah For the what sorry Line Yeah, I mean it's there's there's nothing there's an azure plugin that someone's writing I think But that's the other stuff not yet, but feel free to to build them It's it's super easy to build a plugin now So we're we're currently building stuff that that we need so that we can actually test it and the other people kind of need and We've got our own slack channel that a lot of people are contributing to and a lot of people are actually writing their own plugins So there's not anything specifically for those things you mentioned But um by all means Send like create your own That's the whole point of it So yeah, and if you got any questions about it like we're more than happy to help on how to do that So um On the I don't know if you're on the london. Sorry the ember community slack channel But there's a an embassy a lot of ploy channel in that Um, and we're on that all the time So if you've got any questions about how to do it how to start whatever Just ping something in there and we'll we're more than happy to give you a hand Okay So we're using production every day we have been for Probably three or four months And so a bunch of other guys on the on the team and so a few other people that aren't even on the team So it's currently been like we're deploying to production. We can deploy multiple times a day Yeah, and we haven't had any problems like I was I was building Yeah, building this at the same time we wanted to use and stuff. So I've been sort of You know when it broke or didn't work for for us then I needed to fix it because we couldn't get to production Was that uh, yeah, so we we we're getting really close to my to getting past beta putting into um Like 0.5 to 0 just want to one of two other things we want to do Um But it's just about ready to go. Yeah, so it's pretty close Okay Yeah, so so the concept of the the environment you want to deploy to is known as a deploy target And then the environment what you refer to as environment is the same as what you would with embassy let it play So you might want to build in production mode and deploy to staging. So That's that's just past in the command line and and but deploy production and but deploy staging So that staging and production is the deploy target In your configuration In your configuration, yeah Yeah, so you would say if environment equals Staging then you'll yeah, like you put it in for the plugin You say what the environment is that you want to build with in the because like the build The build plugin has it done in configuration. So you tell it what environment you want to build with Anyone else jamey? Yeah, so you can you don't have to but it will be promissified anyway So if you return an object, we will wrap it in a promise. So it's all yeah, it's all done with promises No, they're sort of they're done it is a pipeline It's like a convey about basically chuck them all on and then they just pop off the end So you haven't really thought about asynchronously I don't know how that would work because a lot of the time this needs to happen before this But um, yeah, we haven't sort of really entertain that idea I miss Yep, so that's all in the it's in the command in your config I think it auto activates by default Can't remember but there's yeah, you can and you can also overwrite as well Which is always a problem because on 1.4. We were using the commit hash as the unique key And if you hadn't committed to git then the commit hash was the same It would crap out because you've already deployed that version, but you can easily overwrite now as well It doesn't actually use a commit hash anymore. But yeah, that's another thing That's all Well, it depends what you want to do So we have probably so we got the build s3 redis gzip manifest a bunch of them, but we've also got I forgot to mention We've got the concept of Packs so plug-in packs. So you basically just need to do one you do ember install I think it's called light the lightning pack or something And it installs all the add-ons that you need So the idea is we'll create these plug-in packs when we when we sort of see different deploy scenarios like In ember install bro and crates as a crazy deployment approach Boom done. So that's there is that one for the lightning approach right there for you. So it's all ready to go. So that's the idea Yeah, if that's it then if no one's got any more questions