 have some of cool features to enable us to do so. So we'll be doing a lot of demos tonight because we just have like 30, 40 minutes, really hope. So OK, what we want to aim tonight is first, of course, we want to get our applications up and running in AWS, accessible from the rest of the world. And of course, we want to have some kind of configuration injections or what we say as environment variables injection using code build. Because yeah, I want to do as much as work inside AWS because in terms of speed, so we don't bust a lot of work into another third party solutions. And I use code deploy for deployment to AWS. So it will eliminate a lot of headaches here. And if we still have enough time, probably we have we will demos a little bit about the automatic rollback. So if somehow our deployment have failures or our code deploy have a cool mechanism named automatic rollbacks, very cool. And also the last, as a bonus, we're playing a little bit with AWS Lambda to send notifications about our deployment status. Is it successful or not? Keep us updated, right? OK. So this is what we possibly do with deployment in AWS. Yeah, we have a repository in GitHub. And it's very, very simple and straightforward. I'm pretty sure you guys have familiar with this pipeline. We have a git. First we clone the latest version of our software. And then we inject some configurations and firmware for everything and decide if this code should be deployed to the which environment is it development or staging or production or so. And we do some tests. If passed, then we perform the deployment. And each stage will be a trigger AWS Lambda to do something. We ask them to do like send notification to Slack, which is very important. So we always update what's happening in the background and we can also trigger something for the third party applications, like for example, if you are using Sentry. So Sentry have a feature of the name Release. So we can actually send notification to Sentry if, hey, I've released a new version. So please mark something in your application. And one of the most important thing is we want to keep all of our deployment and build activities always recorded in our database. So we have these records, every deployment, every pipeline run, every build, every deployment, everything who run the deployment, how the result and how much time it takes. We want to record everything so we can analyze it. So it's all now in Yoji, we are on the journey into these complex things. However, I don't think that tonight we can demo all of this. So we try to do a lot of simple things. Like I mentioned earlier that we will first we clone the latest version of our source code base and do some configuration injections. If everything is OK, then do the code deploy, do the deployment, do the easy to instances. And if we have some enough time, we will trigger some endless link of options to us like notifications. Hopefully we can do all of this. So first, this is tools for you to have a little bit of experience with code pipeline. Sorry, yeah, code pipeline. OK, good. Code deploy. Ah, perfect. All right. Code pipeline is actually not rocket science tools. Code pipeline is actually a wrapper. So it do nothing but link all the solutions. For example, we have a code build to build applications to get the artifact. And we pass some of the job to the third party solutions like Jenkins and everything. And finally, we do deployment and everything. So this code pipeline wrap it up. So this is some of what you can get from code pipeline. I want to work you through one by one with this. I'm sure this is not a very fancy thing. You guys are familiar with it. And this is what it visualized. So actually, the main point is on every stage, code pipeline has output which is stored in Amazon S3 storage bucket. Then basically, the output from the stage will become the input from the next stage. So the output from the first stage which is source could be called by any stage. So it's not sequential. It's not always sequential process. But the output from this could be called by all the stages as long as it's inside the same pipeline process. OK. As it's called deploy, it's very cool tools. So the deployment, we can always monitor what's happening now. And the most of the cool features of this tools is it can be, it supports blue-green deployments. It's very cool. So let's say we have 10 or 12 or 100 instances. So it supports completely zero time in every deployment. So if we are emphasizing the CI, CD, like a DevOps spirit that we have to continuous deployment, continuous deployment, I can imagine that we have, for example, four development states. For example, we have two or three servers there. So we perform three or four or seven times of deployment per day. So imagine if our system will be done. We experience downtime for a couple of seconds, just a couple of seconds on every downtime. For every deployment, it would be a lot of downtime per day. So we don't want that. The deploy came to rescue. All right. That's it for my presentation, because now time for demo. Now, first of all, of course, we need to make sure that this is my personal account. I've prepared one instance for this demo purpose. All right. So I start the instance. One thing in NWS is some part of this process that we have to wait. There's some process of deferred we have to wait a couple of minutes, like spawn new instance or do deployment process and everything, some kind of not. We have to wait. Anyway, if you have a question, just along the way, raise your hand or make some noise or attract my attention, it's OK. While we're waiting, I guess sometimes it can be so frustrating. All right. OK, let's try to do as I said, if this is running. Let's do it in a 2.2. Make the font be there. Sorry? Onmaker font being there. All right. Sorry, sorry. Yep, yep, yep. Let me try. Ah. Big enough. OK. Cool. All right. OK, we are hooked. So we, whoosh, it's OK. Let it be, oh no. All right. All right, seems our instance is ready. The most important thing when we prepare in this instance is this, if we want to use code deploy, we have to make sure that our instance have enough permission to do that. So a specific permission will be just this instance have to have enough permission to pull data from S3. That's it. S3 packet, no other permissions needed. All right. Our instance is fine. Then let's see our code base. All right. OK. OK. So we're using this. I've prepared some very, very simple applications. So oops. So this kind of Hello World application, so just for demo purposes, cannot expect too much. OK. This is to return the JSONs with message. Hello World, let's test it first. OK. Test, test, all right. What is it? So let me check. Let me try in my local host. Is it working fine? OK, cool. So this is too small. Sorry. Beep, beep, beep, beep, beep. Now, OK, this is what we add. What our simple application will do? What is it? OK. OK. Cool. OK, thank you, Baidu. So this is what we want to deploy this application. It's very simple. This JSON file to print Hello World. All right. So let's test. OK, never mind. All right. So it's already on my public repository here. That's it, OK. Oh, cell phone. OK, sorry, sorry. All right. That's all right, it's better. OK, test, test, are you hearing me now? Can you hear me? No problem? Yeah, I'm hearing you. All right. You can switch off. How to switch this off? OK, it's OK, fine. All right. Let's yell a little bit. All right, this is my public repository. So actually, this is all. Oh, so, oops, how to make it bigger. Beep, beep, beep, beep, beep, beep. All right. OK, so it's on my public repository. So what we are going to do is every time we merge or push something in the master, then we want to our pipeline somehow trigger and do the deployment in the end of the pipeline, right? So this is the spirits of the continuous deployment. So without any manual activities involved, right? For doing that, of course, first, we will need our deployer. We call code deploy. Let's prepare our code deploy. Oops, see. Applications are probably I'll just delete this and start it over again. What, how to delete this? The name application and it's here. All right. All right. So previously, I've spawned an instance. Let's see. In the tag, we have two tags. The one that we have to put more attention is to deployment group. This is, we can actually edit and put everything there, right? So we have a deployment group. Tag with the value is development. For example, this is our development environment. And let's get back to code deploy. Get started. Install. Skip all through, right? OK, application will be Alex here, demo. It's on on-premise, easy to our on-premises. We have two options there. There's a AWS Lambda, which we are going to use today. And deployment group. OK. So this is the difference between the application name and deployment group name was the application name is actually the code base. So this is what were our code source and everything. And the deployment group name could be our environment. Like, for example, development staging, production, and everything. So this is actually all the informant came from the same code base, right? So for example, let's see. Deployment group name Alex here, death, right? OK, this is another cool part is in place deployment. It means we deploy the application into our predefined easy to instance. So there is no any easy to spawn or creations or things. So actually, it's deployed to the existing easy to. While blue-green deployment is the first step what code deploy we do is just they will copy the entire infrastructure into the new one. So the current running infrastructure we'll access, we'll handle traffic is to be and all the deployment happened in this new informant. So after everything is OK, after this, we make sure that this is OK. Run well, there is no error, of course, and everything. Then the code deploy will switch the traffic from the old to the new. And after wait for a while, if we make sure that everything is OK, then the old infrastructure will be teared down. This is very cool. It's completely zero town time, all right? So this is how we choose to which easy to instances we want to deploy our applications. So this is our text. Actually, if you remember, we want to deploy to all the instances easy to instances with the tag name of the tag. The key is development group, and the value is development. So this code deploy will search into our entire easy to instances with the we have this tag, right? OK, hope so. So it detects there is one active instances. It's very cool. This is our instances. This is our instance. And this is only if we activate a load balancing, which we don't have it. And this is just a strategy. So for example, we have two or three instances there. Actually, code deploy offers by default, there are three methods like, oh, we want to deploy all at once, like three of our instances, all deployed at once, with consequences with the town time, because we do all the same time, all half. If we have four, there's two switch off and deployment. So this is not zero town time. Or one by one. This will take more time. Because imagine if we have 10 or 20 instances they have, they will deploy one by one. Because we just have one instances, there is no much difference. All right. Oh, this is code deploy, right? OK, that's a great one. OK, cool. We have now a code deploy active. And how to trigger the deployment? Actually, this code deploy could be pull the data from either S3 bucket or GitHub. But unfortunately, tonight we don't have enough time to demo it one by one. So let's just go to the code pipeline and put this code deploy inside that, right? OK. All right. Oh, no pipeline. Let's get started. Let's create it straight away. Elixir pipeline, right? Source will be GitHub. OK, so I want to connect to my GitHub account. Elixir demo, right? It's auto-detects, very cool. OK, OK. So we want to, after we change this push or merge into my master branch, it will trigger this pipeline, right? So use MAU to check where the code is changed. Build, no build at a time. This is the moment of truth, OK. Diplom provider, we choose AWS code deploy, right? I believe SMM is auto-detect. So our deployment group, OK, cool. Oops, right? Rule name, it actually, if we just create a rule, it will automatically create the rule who needed by this code pipeline, right? Next step, we'll take a look a little bit. OK, seems good. OK, that's great. That's just great. All right, actually, this is OK. So how to trigger this pipeline? Actually, there are two ways for now. First is, like we said earlier, we push something or we put something or merge something into our master branch. Or the second is just to push this release change button. But enough because here, we just pull for source change through. After we create this pipeline, so it's automatically triggered somehow. This is very cool. So let's wait, actually, right? OK, actually, this is auto-naming. So actually, we can eventually change this stage name later. OK, now it looks like our deployment. OK, this deployment will fail because, OK, will fail because for code deploy to be deployed to all the easy-to-instances, we need some code. First, we need this app. Too small, OK. We have to put this script in our root directory of our applications. So code deploy will know the sequence how what you should do in our target easy-to-instances. So first, let's just put this file into our root directory. New file, right? Save, up, right? And for install, we will use this script install. So this is a very simple way to get Elixir dependency and do all necessary installments. Let's just put in the proper, what is it? Install, all right? And based on these scripts, we need to start. OK, this is how we start our Elixir applications. Instead of we type it manually, I've prepared it. All right. I know we probably have several ways to install two-start applications, but let's use this way. What is it? .knit is at the moment, save, install, upspec, good, script, good, all right, script install start. OK, cool. Seems that we have all of the knit. OK, let's see if it's failed. Now, we have all the knit. Let's do good, .knit.m, code deploy, great, all right, come on. OK, let's see if this automatically trigger our pipeline and successfully deploy it, it's coming, it's coming, please, OK, not yet, oh, not yet. Come on. Come on. Any questions? While we're waiting, maybe take a couple of seconds now. How do you guys deploy your application to AWS? Using this kind of solutions or so? No, no productions, usage? And where is the confirmation? OK, OK, meanwhile, it's automatic trigger. Oh, thank god. OK, code formation is actually designed for another purpose, like a proficient, solve the entire, our infrastructure in AWS. So it's not, I don't know if we can, actually, we can integrate between this pipeline and code formations. But yes, we have to check. But for my, I think it will be, it will take a little bit more times to prepare the entire new spawn, the new EC2 instances and do all deployment and make sure all things are OK. And I think you'll do all the applications. I don't know, but still, we have to check. This is for my assumptions. It will probably take a bit longer time. All right, yeah, OK. To the previous person. OK, OK. Good idea, sir. Yes, thank you very much. OK, so, OK. How often do you set up this code pipeline? How often? How often? You mean how often I update this pipeline? How often do you set up the pipeline? Actually, we set it once and we can do it forever. Oops, another failure. Why? We can check. All right, so, few logs. Cool. You have to remove this first. So, let's see your app. OK, that's, yeah. This is what I'm talking to you previously, that code pipeline and code deploy. Another cool thing is the logs are if failures happen, we can just know immediately. And actually, we know what happened, all right? So, we can just push retry. Let's check on the deployment part. OK, so it's in progress. The deployment, wow, it's all instances. OK, it's kind of succeed. All right, let's check. All right, it's kind of our deployment success. Let's see. OK, moment of truth. Let's see. It's there on our EC2 instances. OK, OK, actually, do not celebrate yet, but we want to test our theory if we change something in our code base and we push it to the master branch and it automatically triggers the pipeline. Otherwise, this will be useless, right? OK, so let's change something. It's somewhere around here and here. OK, so we can name, for example, oh, what is it? Let's say this Singapore, all right? OK, we add one key value in our JSON. And OK, oops, OK, push. Oh, all right, without any manual interventions, it must be automatically triggered the pipeline and deployment, hopefully. All right, let's get back to our pipeline. Takes a couple of seconds. OK, any other questions? Yes, please, sir. So what happens now is that I want to check whether during the deployment everything is compiled from the scratch that all the dependencies are get once again or whether it reduces the previous directories. So I'll ask you because, for example, in my case, if I delete the dependencies in the new directory and I want to deploy everything, it takes around 10 minutes, right? Because it means to fetch all the checks, all the dependencies in compile and compile the application. Why if I use the dependencies from the previous deployment to take around 10 minutes, I want to check how it works in this case? OK, thank you. It's perfect questions. Actually, for this kind of solutions, we do a lot of things again and over again. It's easy to instances. However, we can, OK. So basically, it used the previous dependency and all the file necessary. But of course, we can do something like mix clean or something. So if actually we try, we make a change on our code base, which involving this kind of dependency and everything, it will try to reinstall the dependency accordingly. So actually, by default, it will use the previous dependencies. Otherwise, we install things or we change things related to these dependencies. So let's take a couple of minutes. So please. Oh, it sucks it. OK, sucks it. Let's try. Let's see if it already changed. Oh, thank god. OK, that's actually it. So now, every time we make change and push it in master branch, it's automatically triggered the pipeline and do the necessary deployment. And I don't know, it's already 8 plus. We now finish. Actually, we can take the Q&A while I'm working and wait for another, right? Actually, one extra. How about you guys? You want to keep it going? Oh, is it waiting? OK, here. Actually, it's OK, it's OK. Let's not make him waiting. Actually, I have two more topics. One is how to inject the configurations by the code build. And the second will be the AWS Lambda to send notifications and do some other tasks. But unfortunately, our time is not sufficient. So I'm just sorry. But of course, we can have another discussion and a lot of conversation after this stage. And of course, you can find me in any other channel with andika.coordinator.com. You can, it's in Pasadonesa, I'm sorry. But in the bottom of this page, I have all of my identity. So ping me any time. I have my email. My email is andika. This is very simple. And anika.coordinator.com. So we can start cool discussions and conversation over there. And I think we have your LinkedIn profile. Super cool. Yes, LinkedIn will be fine. And thank you. Yeah, cool. Thank you very much. We just break break with you for five minutes. Really? All right. So we've got our speaker who's going to speak about.