 Hi everybody and welcome to part four of microservices on the open cloud. We're going to be focusing on directing deployments with DevOps. My name is Megan Kaustik, I'm a software engineer in the IBM cloud org and this is my teammate Michael Brewer and he's in the same org as me as well. So far today you've heard about designing microservices, how to deploy them, delivering applications using microservices and now we're going to kind of pull it all together and learning about how to direct your deployments with DevOps. So here's kind of a high level overview, you have your coding and your designing, that's what the developer does and then you have your build and your deployment along with your testing and this is kind of a cycle that goes through for each of your deployments in DevOps and Michael's going to go into more detail on this slide but this way we just kind of have something in mind to get started. So all through the day we've been talking about this 12 factor app and as far as DevOps is concerned three of the sections apply, the code base which is where you have the single code base, all your revisions are there and you make many deployments off of this code base. You also have your build release run which is where you have all your separate stages and the build and run stages are kept separate and then you have the dev prod parity and this is the idea that you want each of your development stages or environments to be as similar as possible that way by the time you get to production you kind of expect and know what's going to happen. So we're going to answer three questions today. What is DevOps? Why is it important? And what does DevOps look like? So let's get started. So what is DevOps? There's no one single definition for DevOps. If you look it up in the dictionary you're probably not going to find it but what it kind of is in general it's a methodology and it really encouraged collaboration and this is through your whole development process, your build, test and deploy and the idea is for it to be something that gets your products out rapidly and has a high emphasis on quality. So now we are going to switch over to get started on the first part of the demo. Let me exit out of here. All right. So put yourself in the shoes of a developer. You have your work station. This is X code where we have the blue pick app checked out in our get repository and currently if we take a look at the app itself, it looks all right up there. It looks like before in all the sessions they showed but if we click on a picture we see down here that the font has been changed to currently it's black and we've gotten new guidelines that we should probably change this color. So let's head back over to our code. So I'm going to change this color here to red. So let's replay this and take a look at how our change looks. Click on here. Doesn't that look just lovely? Nice red color with the blue. So I think that looks great and I'm going to check it in. So let me actually head over to my terminal. See that change? I'm going to add it, commit this. It's off the page one second and I'm going to push that to my repository. So that's been pushed. So we're going to head over to IBM Bluemix DevOps services. So here is kind of your landing dashboard of your project. So here is the blue pick OpenStack Summit demo which is where my repository is hosted. So here you kind of get an overview. You can see all the different code and you actually can edit the code itself in DevOps services. So here you can see, you can switch between files, make changes if we want here and this actually has a Git repository as well built into here. So if we take a look, we're going to see that, let me switch to the right branch, we're going to see that there's an incoming change and technically we'll see that our DevOps pipeline is already kicked off but I'm just going to merge that so I have the latest as well out here. And so that's pretty cool that you could do that as well here. And if we take a look at build and deploy, this is where our pipeline is. So this is our DevOps pipeline. It has kind of the traditional build test deploy. We have our dev stage, our staging stage and production. But let's take a look, went back too far, one second. So if we take a look though, we'll see that my latest commit changed the font to red built but we have an issue here. The unit tests have failed. So what we can do is click on the logs and see what's going on. Ah, no red text allowed. That's a problem. So if we go back to the pipeline, we'll see that the unit tests also since they failed it didn't continue on to deploy to dev because it's been three hours since it succeeded. So we need to fix this because this isn't good. So let's go back to Xcode and let's make it white. I think that will go better with our design. So let's have it come up, make sure everything looks good. Much better. All right. So let's get that checked in. So change the tag font back to white or change it now to white. And we'll push that up into our dev ops home, right? And let's take a look here, might have to refresh. And so that's automatically kicked off our building stage for dev. That's a feature that you can have as soon as any commits go in it automatically starts your pipeline. And let's just make sure that our unit tests pass and then we can continue onward. And you can see here that we kind of, you know, we've moved on to the testing stage, but we have, you know, for the other stages, different forms of testing. And this can kind of be, you know, built to fit the needs of your project. Oh, yay, our tests pass. So now it's going to start deploying into dev and continue onward. But we're going to head back to the presentation, let this do its thing, and we'll revisit it later in part two. All right. So I'm going to hand it over to Michael to take you through some of the details of dev ops. So for dev ops, there's several things about it that are important. But the first I'm going to show you is a comparison to how it would compare to, like, a traditional form of development. So in a traditional form, you have several different characteristics. The first one is that a manual configuration. So in this, it's going, you're going to go into the environment, you're going to manually set everything up. You're going to make sure that each time it's set up to your specifications. Next, another differentiating factor is a separate test cycle. This is where you will go through the development process, then at the end you're going to pass it off to the test team who's going to go over, they're going to test various different aspects of it that if they've been told to go over, then after that they'll go back and then be like, this is the debugging cycle. The next part is the infrequent deployment. The reason it's infrequent is because we're waiting for the development cycle to finish, the test cycle, the debugging cycle, then finally we're going to go and deploy it. Which goes on to the dedicated teams for each phase. You're going to have a development team, a test team, then the development team is going to come back and debug, then you might have a team that's dedicated to just deploying. Next then, as mentioned, we have the debugging cycle. It's after the test team's gone over it, they've spent how many weeks or days they've had to, they're going to pass it back to the development team, they're going to say, all right, well, we're going to fix as much of this as we can, and then we're still going to try to reach that particular deployment cycle. Then through all of this, because you're going to have potentially teams all around the world, you might have inconsistent environments. Say one team has Red Hat 6.5, one team has Red Hat 7, or someone's working with Ubuntu 12. So it might be slightly different around the world. Maybe a machine doesn't have quite as many cores, so if it had more cores, it might have actually messed up. Whereas that's not what we want. The next is it's rather difficult to scale doing this manual process because you have to go out there, you have to say, all right, we're going to install it on these machines. We're going to prepare these to make sure that when we want to deploy, it'll just be ready with what we've already cookie-cuttered to make happen. So now we're going to say why DevOps is important to this cycle. So the first thing about DevOps is important is the automated pipeline compared to that very slow, moving, very rigid cycle to cycle. This is going to be 100% automated all the way from end to end. So that entire development test debug deploy is going to be just completely one motion. It's going to, the entire pipeline is going to be pushed off with the commit, as you saw earlier, when Megan made the change to the code. She didn't have to pass it off to another team. It just goes straight through. The next one is the integrated test. So as you saw in the example above, so no one had to say, all right, this is ready for testing. It just takes it and it knows what tests it needs to run against the code. And so assuming you have full code coverage that the code that passes the tests will, when it gets to the deployment automatically, it'll be, you know, it's supposed to be good. The next is the continuous deployment. So every time you make a change and you push it into the repository, it's going to go ahead and just push it out. And if everything passes all the way to the end, it's just going to go straight into production. Next, we have a collaborative effort across all phases. So instead of having to do development, tests, debug, and then pass off to deploy, everyone's working on every aspect, as Manuel had mentioned earlier this morning. It's everyone's wanting to make sure that it passes all the way to the end because everyone's involved in creating the tests, everyone's involved in making sure that it debugs correctly and that it makes sure that it deploys to the correct environments. Next, and then the fixed bugs. So you're going to treat bugs kind of like features, which the kind of are, the reason you want to do that is because if you have like a feature to change the font of something or a bug to change the font of something, both of those are to change the code and push it back into production into this continuous pipeline. So we're going to treat them kind of the same. We're going to have the consistent environment. And the reason we have that is because we're not doing the setups of the machines. We're going to say our automation is going to run against this particular OS. It's going to have this many cores. And we're going to make sure that it's always, we're not going to have to change it because it's always just doing its own deployments. No one's going to go in there and be like, you know, I like working on this version of the OS instead. Next, it's highly scalable compared to the other method traditional where you're trying to be like, oh, we want to add this many more servers. Let's go and order them. This is just going to scale based off of containers or it could be virtual machines. It'll go ahead and take what it needs and just deploy using the automated process to as many other machines as it needs. And then next, a DevOps architecture. As mentioned, this is just one example architecture that could be others. But the first part of the DevOps architecture for one flow of the pipeline would be, first, you're going to design. You're going to organize your ideas. You're going to pass out tasks to various team members. You're going to plan features. You're going to divide those into microservices. You're going to set goals, being like, we're going to have this particular page or the website done in a week. And maybe we'll add more after that. The next one, build. So this is where you're going to set up the automation initially for your initial run through. You would set up your automation. But after that, the automation is going to install dependencies. It's going to compile the code. It's going to create any containers it needs or any OpenStack VMs it might need, et cetera. Test. This is next, an automated part of the process, as stated. So it's going to either, depending on which cycle or stage of the development you're in, so you might be in a development part where you're just worrying about one particular item or serve microservice. It might just run unit tests against it. It might not run the entire system suite. It just wants to check, does this one work? Or you might be deploying to production, in which case, it'd be running system tests, integration tests with other microservices, unit tests on the individual services. And finally, you're going to deploy. And this is where you're going to deploy, for example, if you have three different environments. Our example environments are development environment, staging environment, and production environment. So if you're deploying into a development environment, it's just to check the one thing you're developing on. If you're deploying into a staging environment, it's supposed to be, based off the 12 aspect app, it's supposed to have as close to production as it can be while still accepting that it can be broken, because you're still developing. And then finally, you have production, which is where the end user is using your product, and they're seeing what you've been developing, and it's past all of your automated tests and deployment. And as you can see, this would be just an automated pipeline once you've set it up the first time. And so you would design what you want, build, test, deploy, and then you would go back and be like, all right, now we're going to work on the next microservice, or maybe we want to split that microservice off into smaller ones and move on. So these are the three different types of environments we're talking about. You can have more. It's like another example of an environment you could have would be like a feature environment. Maybe you just want to work on one feature of one microservice, or you could have development. So development's going to be where you're doing bug fixes. It's going to have the individual services. It's not going to have to worry about the other services. You might have dummy data just to simulate the other services talking to this one. It's going to be broken constantly, because this is where you're actually developing. You're going to be like, oh, that code doesn't work. But we're going to try again and just do it over and over. Very continuous. And this mostly you're only going to test unit tests against it, because you've already tested the simulated data feeding into this microservice works. So you don't have to worry about that. Staging, it's where you're integrating all the other past development microservices together. It's going to be more stable. You're hoping that if it's reached this part, the unit tests have told it that each microservice works alone, so then the integration tests should just have to make sure that they're still talking to each other as expected. But it should be almost prod ready. And then finally, production. This is your final product. This is what your users are using. It's going to be stable. It's tested. It's going to have hopefully no downtime, because you've set up a high availability setup to where, while you're redeploying one microservice, another copy is still standing, and then you're not pointing at the one that you're redeploying. And this is going to have been tested at least twice, if not three times, through unit integration and system tests. So this is just an overview of what that could look like. So you notice at the top, you only have one light bulb. That was the design. So you're going to think about it. And then at this point, the developer is going to go in. They're going to make the code. It's going to be pushed into the automated pipeline, so then it's going to build the couple of changes they made. It's going to test those unit test changes. It'll deploy it to an environment and development where they can look at what they did with simulated data. Then it's going to go ahead and just keep going. So it's not going to wait for them to be like, all right, that's good. It's just going to go ahead and be like, well, it passed the tests. I'm just going to go ahead and deploy into staging. And if it gets passed integration tests and system tests, it's going to go all the way into production. So here's the screen that we saw earlier, just to give a reference back to that. So the yellow dot is that's where you're going to have design and development. And then you're going to push that into your code repository, such as Jazab, RTC, GitHub. And then it's going to be taken by the automated server. It's going to see that the code was changed. It's going to take it. It's going to push it into the unit tests or the integration tests, depending. Then it's going to come back and it's going to deploy it. And then it's going to go ahead and just keep circling. And that's how it's supposed to be. It's supposed to be like a moving wheel. And with that, we're going to go back to the demo and show you how that's going. Thank you, Michael. All right. So let's go take a look here. Oh, maybe stand in two clothes. OK. All right. So we can see here, we passed our dev stage. Staging looks good. And we are currently deploying to production. So we made it all the way through our pipeline. And I'm going to switch over to one thing, and then hopefully when we get back, that might be completed. So right now, what's up here is kind of a DevOps pipeline for a single microservice. But usually within your application, you're going to have multiple. And so each of those would need to have its own DevOps pipeline that eventually came together to production. And so there's also a tool called tool chains. And this is in the IBM Bluemix DevOps. And what you can do here is bring together each of your microservices and set up their pipelines. You can link your issues. This would kind of be like the design aspect to it. And you have each of your repositories linked. You set up their own pipeline, which will look similar to what we were looking at before. And then you can add in things like to monitor or to post to Slack when a commit or deployment occurs. So that's kind of a neat way to do it in a good visual. So I'm not sure if this is complete. But we can still go take a look. I know I believe in part two, they kind of showed the dashboard for the app itself. Oh, no. It's because it's still deploying. We might not be able to look at it until it's done. But it's at 86%. Yeah, so since the app is currently redeploying, we're not going to be able to look at it. But you already saw the screen. Well, some of you saw the screen earlier in part two. So let's head back to the presentation. So we're just going to go into summary now. So today, we answered those three questions we were talking about. So what DevOps is, it's really that collaborative development operations. You just go through. You have your build test deploy. And this is done very rapidly. And it really adds quality to your code because you're constantly testing. It's consistent. It's really important because it's so reliable, repeatable, and scalable. And also, we hope that you kind of could see how a DevOps pipeline, you know, you can make it work for your application, your team, and your goals. So now, if anyone has any questions, we can answer them. Or you can always find us after. All right, thank you, guys. I'm going to hand it over to Manuel to just do a little closing. All right, all right. And so if you guys want to try this out, this is available here at GitHub, the IBM Dash Swift, BluePick. This is like super fresh. This came out on Monday. On Monday, this version came out. They spent about a month updating it for Swift 3.0, which was released last month. So if you can try this. And we really like this app. Like we said, it covers everything. It covers everything about microservices, from your backing services to your main application services to your DevOps. And if you run it on Bluemix, you're able to run OpenWisk. And then you're also able to do the DevOps stuff that Megan and Michael did. We actually extended it. Daniel extended it a little bit with some extra dashboards. But that's the beauty of microservices that they don't have to know. They don't have to be tied into other stuff. The beauty is that if you want that something, the data's available. It's something that you can extend yourself. So thank you guys for putting up with us for a couple hours. And if you want, there's still some beer left. And thank you very much.