So, it's 9.02 and the room that nobody can find is full. Welcome to FOSDEM. My name is Kusbert. I'm one of those weirdos who's been coming to this event for 20 years, which means I actually have never been in this side of the building because they only started using it this year. What I do in the daily basis, I help organizations to leverage open source to deploy software faster, to actually achieve their business goals faster. Somewhere about 10 years ago, we figured out a name for that. We called it DevOps, since then people started abusing that word for a lot of things.  So, if you want more of this fun stuff, this is actually the only pitch I'm gonna do. Monday, Tuesday, Wednesday, we have this other small event in Ghent, which is Config Management Camp. It's basically the same as FOSDEM, only focusing infrastructure. And you're all welcome. We're sold out, but we don't check tickets. We basically do crowd control. So, just show up if you care about this stuff. For those who have seen this slide before, they might have noticed this new thingy here. DeliveryConf had its first edition last week in Seattle. It was awesome. And the ID currently is that we might run one in Europe next year. So, given that you folks are interested in continuous delivery and stuff, you might want to show up. I don't have much time, but I want to focus on what is this DevOps thing? To me, it's not the automation part. It is mostly the culture part. Damon and John have been talking about culture automation measurement and sharing. And there's a couple of things. There's no such thing as a DevOps engineer. If you're a DevOps engineer, your organization basically does not understand DevOps. If you think you can get certified in DevOps, you've been scammed. That's not what DevOps is about. It's also not the same continuous delivery. I think you need to do something like DevOps in order to achieve continuous delivery, but you could definitely do something completely different and have a healthy culture and still achieve your business value. But if we talk about continuous delivery and what basically is the topic of this talk, it's this. It's the ID that we can constantly deploy software, stable, reproducible, fastly, and we typically achieve that through collaboration between all of the people involved. And that smells a lot like DevOps. So, how do we get there? Well, I could pull a just humble trick here and ask, who's doing continuous delivery? Raise your hand if you're doing continuous delivery.  Okay, the hands that drop, they are not doing continuous delivery, because they're not even doing continuous integration. They're doing continuous disintegration. And you need to do continuous integration before you can achieve continuous delivery or continuous deployment. And also, there's nothing wrong with maybe having that manual step in there, if everything else is automated. So, what is this thing about? What are we talking about? Today, I want to talk to you about how to get there and how I'm not together, and I'm going to talk both about a couple of use cases, stories I've had, experiences I had with larger and smaller organizations, but also a bit of deeper dive into how to do this technically. So, what is the actual goal we want to achieve? This is part of the release notes of Deployinator, which is a tool Etsy wrote 10 years ago, and we're still not there yet, but this is basically the goal we want to achieve. We want to have the ability to deploy code quickly and safely. And a lot of people have tried to achieve that, and a lot of people have succeeded, but many more are failing. And I think partly that is because they haven't involved the operations people first. They've basically been trying to do this as something which is a developer-only story, and I don't get this, because if you look at the operational part, for years, we've been telling developers like, you're not going to push this to production, you're not going to deploy this life, you're not going to do all these things manually. You're going to have testing in place, we're going to have automation in place, and we're going to force you to go through a pipeline and automate everything. But on the same time, we've tolerated that. Ops, folks, we're like, I fixed it, or let's do this manually, or let's change stuff there, or reconfigure a network switch, or add a firewall rule, and we've been tolerating people to just do that manually. Who's still doing that? Why? The people who have worked with me know that I don't tolerate that, and I haven't tolerated that for the past decade. And it's hard, and if you look at the history of where this DevOps movement comes from, if you look at the European part, we were mostly senior Ops folks, people who had been, I mean, I've been coming to FusDom for 10 years, I did an open source before that, and we started DevOps Days 10 years ago, so we were doing more than 10 years of open source stuff, some of us 15 and more. And we were starting out from an operational point where we were seeing bad quality artifacts from developers. Teams, we were having a lot of pain with stability, with scalability, and we were like, nah, this is not how it works. And on the same side, we had the American people, we were like, yeah, but we need faster deployments, and the developers were pushing this, and somewhere in the middle we met. There's also the difference in culture between the American startups where there's Vulture Capital, which basically pushes companies to go fast and burn, whereas the Europeans are more looking at we have a sustainable business. We're going to be around in 10 years and be supporting customers. So the combination of breaking things fast, but still being resilient and knowing how to run things, that is to me why a lot of people have been tolerating Ops to do things manually, as opposed to really doing infrastructure as code, really doing automation. And I have some stories, some cases, which basically back that feeling that you need to start with the operations part first. They're not as scientifically measured as Nicole Forzun's state of the DevOps survey, where she actually has good metrics, but I've seen this throughout the journey with different organizations, and I wrote down like three of them. And I hope that's not somebody on call, it's 9 a.m. on a Sunday morning, I must be painful. I'm actually looking in a room to see if there's people from the customers in the audience. I saw somebody outside, but he's not getting in, so that's good. So yeah, let me start with a couple of those cases. And the first one is a situation where I walked into an organization and they were in complete chaos. They had about 300 nodes. They had no clue on how they built them. They had no clue how they deployed them. They had Jenkins hiding somewhere under a developer's desk. Who still has that? Not that many people. That's good. The operations people were mostly fighting fires. There was zero standardization and every artifact that was being deployed had different naming conventions, was deployed on different locations. It was, well, hell as we know it. And their tipping point was the moment when they had a really, really huge failure. And their senior management realized if we have this failure again, it's game over. So they sought help. And what we started doing there was the first thing we needed to figure out is how do you build your software? How do you make sure that your software is reproducible? And how do you actually achieve being able to build your build environments again? So we started teaching those people. We were already using purpose and infrastructure as code tool. And we started teaching those people how do you build your own CI stack reproducible so that if it breaks, you can still rebuild it and you can guarantee that the next time you spin something up, it's going to be similar or extremely similar to what you built before. And we taught those folks like testing. How do you test your things? What they were doing before was they had 300 nodes but had no development platforms. They were just hacking Puppet's code in production and Puppet applied and it broke. Oh, so the idea there was we start with building the infrastructure there in a development environment and then teaching them that you can promote things to a new environment when things work. So we split out the configuration out of the code. We started to teach them how to use the pipelines they were actually building for the developers and slowly you saw the developers starting to actually contribute code to the Puppet's code base. They were writing tests, they were writing their own modules and we saw that because they were now using the same tools, the bridge between those people was being closed. The gap was closed and the bridge was made, sorry. So we went from a zillion different GDKs to one GDK and one GBOS version. We called this project initially Project Dolly because we wanted to be able to clone the difference environments, not as in a physical image clone, but like we wanted to have the same environment for everybody and we tried to shoot for like 90% reproducibility because that was the initial goal.  And like I mentioned, eventually we had Java developers, they were contributing back to the RSpec code base to actually having tests on infrastructure code so they were much more sure that what was being delivered was actually what they wanted. So we started with telling ops folks Automate and they learned the same tools as developers and eventually collaboration improved, progress improved and they were happy, they had much less downtime, much less issues and much better collaboration. The second case I went in was completely different. They were already doing CI, they claimed.  They had some things under their hood, hiding under their desks. But the people that they called operations, they had like, yeah, but we cannot deploy this. We don't know where it is coming from. But those developers said that we have good test coverage and we have everything in place. But they still had no way into stable deployments. They could not automate their deployment. It was painful. It took me about 18 months in that organization to finally find somebody who I would consider an ops person. Who I would actually say, hey, if you're looking for a new job, I hire you. And all the other people in that room were basically people who were, they were called ops, but they couldn't figure out the difference between a root password or a username. It was that bad. It was mostly when we eventually found people senior enough to do operations work, it were the Brands, if you've read the Phoenix project. It were the people who were firefighting, harding knowledge and they were not being able to move forward. So what we did there is we found a couple of them and we moved them out of their office, out of their day-to-day job. We actually moved them to a different city. And there we started teaching them agile. We started, they were longing to do infrastructure as code for years, but they weren't allowed to. So we started them in their own group where they couldn't be disturbed by other people. The side effect was that the other people that were trying to get their resources were finally learning how to fix things themselves. And they started to build a pipeline. They started to do CI-CD on their own code base, their own tooling. And they started to think about, hey, what is our way to build something that ends up to production? And even discussions like what is production if the ops teams deliver production is that production for them or is that production for the developers? Those kind of discussions started happening. And after those first successes, we slowly started moving those people back to their teams. So they could take the practices they had learned and they could actually help their own teams back in adopting them. But that was like 18 months after we started working with them. So over a period of about six months, we ended up having like the really old-school greybeard people. The people were just doing AI acts and said, I'm going to go retire in six years and I'm not going to learn anything new. And we converted those people to actually being agile eventually. Those were people who now were running in the organization and saying, hey, you should do this canmenting because for operations it might be better than scrum. And those were the people who were actually writing code tests. Test for the code. So it took them much longer time to have teams arrive at continuous delivery because they didn't get the ops folks involved first. It took them more than a year longer. But once they were there, things started moving. So you can guess what the third case is, right? An organization that still refuses to involve the operations people. They claim to do DevOps. They claim to have been doing it for two years. And they have a DevOps team in the middle which is dictating tooling. Tooling they never use. Tooling they don't know. So the developers are basically complaining about, well, yeah, we have this tool set here, but we cannot use it because it doesn't fit our needs at all. They're broken. They don't deliver what they should deliver. And basically what they achieved is that everybody is working around the ecosystem that has been built and still doing things manually because the tool set they're given is completely broken. They're still hiring DevOps engineers and the average DevOps engineer who has a clue accepted the fact that the job title was wrong but he might be able to help stays for about two months and then leaves. Their senior IT management has left twice over the past three years. And they have a team where basically there's only junior in-house analysts that stay and all the crowd is external people and by the end of the year, by October, November, they're out of the budget so they don't write any code in the last quarter because they don't have any developers anymore. So they're going to fix this by adopting the cloud which means they have some cube deployed somewhere and they're moving their Oracle databases in there and they're wondering why things don't work. Oh yes, you still need to fill in a four-page word document in order to be able to deploy something and they still haven't involved the ops folks. Actually it's worse when I was working with them I wasn't allowed to talk to the ops folks. So if I look back at these journeys and those are just snapshots, the only thing I can conclude is the earlier you have those ops people involved the better your CI CD story is going to be. It's going to have a much higher rate of success and it's going to be much smoother. And if you think about it, there is a reason because people who run ops need to be able to support what the other people do and in order to be able to support these things they need to understand what they do and if you've never done this before how can you do this? If you've never driven a car are you really going to tell people how to drive a car and help them fix the car?  And you need those people involved so you can unblock delivery, you can unblock provisioning, you can make sure that everything you want is built in.  Shouting that you're doing CI CD is not going to solve that. So the culture hack I have for this is well, if you teach your ops folks to set up CI CD for your CI CD infrastructure first they're going to understand how this works and they're going to be able to coach and teach your developers into doing exactly the same thing. And while you do that you give them a common set of tools, a common set of terminology, a common set of it's broken, let's fix it together. So how do we do this? Well, if you look at all the organizations you see that in the CI ecosystem there is tool for version control, deployment tooling, build tooling, you need artifact repository, you need code coverage, you need test tools, you need a lot more than is listed here. And if you talk to the average ops person in a legacy organization how many of these tools do you think he's been using? Two. Two, zero, all of them then it's not a legacy organization. Then it's probably an organization that already moved further but you'd be happy if they use version control. Testing, hmm. And I had a friend who tweeted last week even that he was working with an organization and their version control was file names on Dropbox. And it is 2020.  And that's already the first challenge to overcome. We need to have people who understand how these tools work because they have been using them. So a lot of people still argue against doing CI because of these reasons. They don't know what the tools are about. They don't know how they work. And they're like, yeah, but this is costing time and we don't have tests anyhow so why wouldn't we spend time on this? And the biggest ones is we don't have budget for this. We don't have the money for this. Now that's because the money is hiding somewhere and you're spending it anyhow but you're hiding and spending it in firefighting rather than building something resilient. Or there's a different budget. The budget that the development teams need to do quality insurance and to do all of these things are not theirs. So it's a really painful thing. And then there's a fireman forget projects, obviously. So a lot of teams say, yeah, we do continuous delivery because they don't want to spend time in building multiple platforms. For those in the back who cannot read it, it says everybody has a testing environment so people are just lucky enough to have another platform that's not called production. So in order to get there, we need to do automation. We need to do infrastructure as code and we need to look at what we built and we need to write code. And what me code does not mean I'm going to write shell script and convert them to YAML. I want to basically define the state of an infrastructure and I need multiple components to this. I need tools that do orchestration. I need tools that do actual desired state configuration. So you're typically looking at modeling your infrastructure, writing code books or manifests or whatever you like to call them these days and have different environments for your infrastructure. So you can also promote the artifacts you deliver and ship them to different stages. And then you eventually end up with a working service which is the application code, the infrastructure code, and security and monitoring and everything is built in. This is a traditional one. There are parts with this, but lots of ops folks still need to be taught on how to do version control. Actually, lots of developers still need to be taught on how to do version control.  Those are the people who are not doing continuous integration. Who has different tools to do dependency management? Who understands how to do dependency management? One person understands how to do dependency management. Two people. The thing is there is a huge variety of tools out there. And it's so simple if you understand how it works. So who knows what's on the screen? What's on the right side? On the right side we have something that looks like a librarian file where there's basically a module defined with a git repository and a reference. And the Ruby ecosystem has some things like that. The Puppet ecosystem has some things like that. Every single language invents their own dependency manager. What's the thing on the left side? It's exactly the same. And I hear somebody who actually saw what it is, but it's exactly the same. It's a list of a module with a reference to something in git. These are git sub-modules. They do exactly the same as the thing on the right. With one big difference. This is going to work for every single language out there. This, you're going to have 35 different languages doing 35 different things. And each time an ops person needs to help a tool, it's going to be like, oh wait, there's a different variant of how I'm doing things.  And having those discussions, operations people between developers and realizing, well, this is the same pattern, but we're just using different tools. If you have that discussion, you can help each other understand it. You could use the same pattern and use this for different languages. Or you could understand like, oh, that's what you're doing. That's what you're trying to achieve. But in a lot of cases, people don't understand the goal of the tools they're using because they've never had to, unless you understand good sub-modules, obviously. So people have never done this before. People have seen a zillion branches in the ecosystem and they've never understood. And when you think about it, the branching makes it more difficult. So anti-patterns started happening. I had a really good discussion at the livery conf with the folks from Puppet Lab. About eight, nine years ago, they figured out their release management tool to do deployments on a Puppet Master was, well, we have this tool card, RTEN-K, and you're gonna have a branch for your development environment, a branch for your acceptance environment, and a branch for your production environment. And I remember being in the room with Jess Humble when they introduced that and we were like, I'm gonna teach the operations people how to do it the wrong way. But their whole ecosystem was built on, you use RTEN-K and deployments of your code base are gonna be fine, it's gonna be smooth. Only last week I was talking to the people who were now rethinking their new continuous delivery tool for the Puppet Code. And I was like, don't use the tools that already exist. Don't build your own tool. But they started to realize that maybe RTEN-K was not the best choice. Maybe there's other tools around. They could do exactly the same. So if you look at a typical infrastructure pipeline, what is in there? Configuration, why would there be configuration in a pipeline? And how are you gonna test completely different parameters for a stack? Configuration is to me actually the only thing which is not in a pipeline because it's close to non-testable. You can test the syntax, you can test whether the structure of the configuration is correct, but you're testing the code that needs to apply the configuration, you can never test the sizing exactly and the IP addresses exactly because if you can, for example, have the exact same IP stack and you're testing everything, then it's actually breaking your production because now you have duplicate IPs. So configuration is one of the most difficult ones. No. The thing that's in your pipeline is what I was trying to achieve. It is literally the same as what should be an application pipeline. You should check out your code. You should do some syntax checking, some style checking, do code coverage, do tests if depending on the language you use you need to build it, you need to build it, you need to do more tests on the artifact. You need to package it, you need to upload it to a repository and then you need to deploy it and that's literally the same as you need to do in every other language. Hopefully there's more and more testing, but yeah. And every artifact is like that.  And you want to have patterns where you basically have development, sorry, development, acceptance, production or whatever values. You want to pull things from the internet, you want to have local mirrors for every single artifact. So, upload to a repository, test.  It's like your smoke test with the applications. And your monitoring is crucial.  You check your monitoring and it should stay healthy.  And all of this is automated because that's what infrastructure as code brings you. Those are the side effects. So, you promote to the next environment when your monitoring has decided that things have not been broken and you increase testing. This is what we do for applications, right? This is what we've been doing for applications for years. And then you go to the next target. And the next target. And the more of these environments you need to build the more you end up with how do I do this? The way we do this still and we're still really happy with this because we have a large JenkinsJobDSL code base where we do pipeline as code for our infrastructure as code. We basically have one large C job that pulls in a bunch of config files for all the projects we have and it generates our pipelines on demand based on a config file. But we have a bunch of libraries that we reuse for every single pattern. A checkout job is a checkout job because if it's Java code or if it's PHP code or if it's puppet code or Terraform code, I don't care. It is a checkout job. Everything we deploy is an RPM. Whether it's puppet code whether it's Java code or Python code, they're all the same. And the patterns I build in there like all the metadata I want to know where it's coming from, which build it was all of that information is the same. It's the same library. So what we created is a library used by both the developers and the ops folks to build their whole CICD infrastructure. And they have a shared language, a common language that works for everything. There's a mix of pipeline DSL and job DSL in Jenkins that works. But it's the same for everybody. And that's the strength. It's not one team using one thing and then the other team going like, oh, I cannot help you, I don't know and we even come to the point where we can in parallel test multiple versions of our code base because we spin them up in containers and we have different versions of our PHP stack but also of our puppet code base and their test. And we don't look at the next version because we don't care yet if it's going to break. But if it doesn't break, we know that we can upgrade. And then people come, yeah, but we're in the cloud. I don't see the difference.  You might be talking to a different API. You might not be talking to the OpenStack API but to EC2. And if you need to configure VPNs, you're going to need to configure VPCs on the other side. You're going to have monitoring security in there. So all of those patterns which you've been doing, whether you have a Terraform pipeline or a Puppet pipeline, doesn't matter. It's the ID. You have to have the same tool base. You have to have the same ecosystem. But we're using containers. There's nothing different. You need to test this even stronger. We need to figure out better ways how to deploy this these days because Docker pull YOLO and we still have to ask all of these questions again because people who have been just doing Docker on their laptop, they're container naive. They haven't figured out that this is the gap they need to cross. So there is a huge challenge for us out there because we're an open source conference and I'm still struggling, maybe you don't, on how to do CI CD on my whole Qube ecosystem. I want to be able to spin up Qube stacks automatically out of the box, hands off from source code. Not the Qube source code, but some infrastructure codes. It's easy if you do it in a public light. Anybody got a solution for me? Way too early on a Sunday morning or nobody actually has a solution. So how do we do this? How do we do this in a container ecosystem? That is the challenge that I have for you folks. What I still see is people having 30,000 lines of bash calling Qube cuddle or calling Helm. That's not how we want to work. That's basically going back 10 years and not having tests because how do we test this? So infrastructure as code to me is the first thing you need to do if you want to achieve container delivery and if you want to have full control over the whole stack, it just got harder if you add containers to that. But it still is something that you need to spend time on because you want to be able to understand the same patterns and the same tooling that the developers that are building applications on top of it need to understand. And I hope the three cases kind of prove that. So it's time for the rest of us then. Questions? Can you prevent organizational gravity from taking over? Okay, so the question was in case two it seems to be an organizational problem. How do you solve the problem that if you move the people back in the team that they just get absorbed by the organization again? That's right. Well, it always is an organizational problem. It always is a culture problem. And the way you solve that is by having C-level buy-in. We pulled those people out and the only way we could pull them out was because C-level was actually pushing this and agreeing on this. So when they came back to their teams they were enabled and they were blocked from doing their old work again but they were supposed to help the people and help their teams. And because they had been on for close to three months, a bit more even, there were people who actually filled in the gaps of the problems they were solving before.  They were still for the highly critical things that were still being consulted and were still being asked to help but it wasn't their daily job anymore because they were gone for three months so some other people had taken over a couple of things. Other questions in the back? So the question is that if he understands correctly how to use Git sub-modules for dependency management. The answer is yes. The main reason to that is because all the other tools around basically try to reinvent exactly the same thing. The second reason to that is because if you do that you get exactly the same pattern that the developers will be using to do the same. I've seen a bunch of user interfaces built on top of these things which are all horrible. And what I've seen is once that people start doing this doesn't matter which language they use they start to care about where their source code is. They start to care about, oh I'm not pulling in random things from the internet that might be disappearing when somebody actually decides to unpublish a node module. No, they have the code locally, they can rebuild. So people start to understand what they're building and also they know that when they go back in time and check out another commit they will have close to reproducible builds. Combine that with being able to build your infrastructure and your CI infrastructure. The fact that they can do exactly the same means that at some point in time I can actually theoretically because I've never been able to spend the time on that go back and say I want to have the built ecosystem we had three months ago because I have the versions checked out and I have the repositories checked out and then I want to be able to build the software we built in. You have everything in place, it's not going to be trivial because typically you don't have enough resources and enough time, but in theory that's what you should be able to do. It works very nice with open source because you have the source and you keep a copy. This is an open source conference. Infrastructure deployment or the application deployment? Both, so the question is on this slide the container ecosystem is nowhere close to the level of automation reproducibility where I used VMs and if I want to talk about application deployment or the actual ecosystem and the answer is both. I'm still looking and I've been looking for close to four years for a fully reproducible automated way to deploy a full cube stack with everything in a picture. Most of the things that I see just pull random things over the internet totally not reproducible that's one part of the problem. The ones that do work are really cloud focused they only support AWS or whatever and not on premise deployment and then on the other side on the application level we have a bunch of package management tools that are OK-ish but configuration of the applications inside there's nothing. Helm is a package manager it's not a config management tool and that's the closest thing to reality. This image is there this image is there with this configuration and you can tweak not only in Helm but in Helm for different...  Sorry. Sorry. Sorry a lot.


Michelle's Let's Move partnership with schools, businesses, local leaders has helped bring down childhood obesity rates for the first time in 30 years. One in every three American children is obese. In an effort to combat this epidemic, Boston has a program based off the First Lady's National Movement. The Department of Public Health has launched the Boston Healthy Child Care Initiative with hopes to promote a healthier lifestyle for kids. The goal is to work with childcare providers in Boston and train them on healthy eating and physical activity. In order to become certified, childcare facility managers must take a class with the Department of Public Health and allow observation of their facility to ensure that they comply with the BHCCI's eight best practice standards. These standards include providing water to kids on a regular basis, refusing to serve sugary drinks, serving fruits and vegetables, offering whole grains, supervising indoor and outdoor playtime, allowing limited television time, supporting and promoting breastfeeding to parents and incorporating a written policy that outlines these standards. I was the one who took the class with the Boston Health Commission and that was kind of how we were recognized was when they were teaching the class that I was like, time out, we already do all this. Jen is the director of the Franklin Square House Children's Center in Roxbury. Her facility is officially certified and she says that promoting a healthy lifestyle has always been one of their main focuses. You know, knowing all day that they're eating healthy and the parents don't have to worry about what they're getting, they know that every day there's going to be something nutritious in their diet definitely is a draw here. It's been one year since the Department of Public Health has started handing out certificates like these to daycare such as the Franklin Square House Children's Center and they are looking to hand out more certificates to daycares all across the city. I think this is the perfect place, perfect opportunity to make sure that the kids are eating healthy and that they're moving more since they are in a facility that's one place for most of their day. So if we can get the daycare providers to make sure that the kids are as healthy as they can be, I think it could help parents a lot too. 400 child care providers currently have a BHCCI certification. The Department of Public Health hopes to eventually have every daycare in Boston certified. Reporting for the Boston University News Service, I'm Katarina Lukatich.


So good afternoon everybody and welcome to my session about manage and deploy your site with thrush Let us first begin where my my name is bastion. I work with amazing labs in Zurich You find me on Drupal org under Das Recht also on Twitter and on Facebook and everything Um, I'm also the dev ops chair the track chair So I organized all the talks you hear during this loop I come in the dev ops track and As job description, I'd like to point out.  We do it live operations. So there's no dev ops We do that so for this afternoon, I give you a Small introduction into drush deploy. Where are we today? Where do we want to go with thrush deploy? I will cover everything that you need to put the things together because it's not just drop a module in flip a switch and then get going and I will also cover Some parts on Drupal 8 how it does work what currently broken whatnot. So Um, where are we today? So currently a lot of people are using third-party frameworks like Capistrano or edifics. You probably know them. So who uses Capistrano by show of hands? Some who use something different Okay, good. So there are currently a lot of deployment strategies like we Deploy on one server then we are sync to all other servers and hope nothing breaks There are some who use custom bash scripts by which I usually relate to duck-take deployment because it could break in some points. It will not break. It's not the perfect way There are also Deployment strategy, which you probably know of from years ago, which was FTP upload Yes, that still exists. We still have customers which say yeah, we want to host an or server It's really fancy. It's fast and you get an FTP accounts like okay, that works. You can do it, but no And there's also just checking it out on the live servers do a good pull and pray that everything runs through Yeah, can you please close the door? so Some words about drush deploy the main maintainer is mark Sonabalm I don't know if he is here yet yell if you are Give a nice hand to that guy and back. He did a great work on this so The whole drush deploy is in heavily inspired by Capistrano and There hasn't been much movement since the whole drush deploy has finished because it Has any functionality we currently need so there is not a lot things we just need to add So it supports just git which is okay for what we use and it needs php 53 at least So there will be some changes for making it php 54 ready. That's also in the making currently So something else to deploy who knows about cluster SSH Who loves it? Okay, so I refer to that one sets the DevOps way to kill five servers with one keystroke because you run one Comment on several servers and you do it remove directory and you find out. Oh, that was the wrong directory And you successfully trashed your life environment doesn't happen Yeah, where do you want to go so The idea behind drush deploy is to use a tool we own all know by heart which is drush So we also want to do multi-server deployments So not any site is deployed on just one server for amazing labs We have around five web servers and not all sites are running on the same servers. So we don't want to deal with the burden to make everyone everyone everybody and Aware that yeah on which server are those clients deployed? We just want to do a drush deploy at life and it should know automatically what's done We also want to run tasks like updating DB's running custom scripts and doing monitoring things like automating everything that you could probably miss out We also want to remote cache All the git things so we want to have a speedy deployment without needing to check out a 150 megabyte git repository multiple times and trying something like that and We will also have the possibility to roll back a release So if something fails, we want to go back one step We use this sometimes when you try to enable HTTPS for example you do some changes and then something is missing and you see oh There is one side which on the customer side which behaves a little bit differently and we need to roll back now and You just can't roll back then with drush deploy. So as a small conclusions We try to sneak in a little bit more automation which leaves then less room for human error So look at your future deployment Guess like this We run drush deploy at life and hit enter and Actually, that's a pre-recorded yesterday because I didn't want to do it live now because when I need to fix a site During a talk with a packed room. I don't like it and it adds a little bit of stress so what do you see it first loads all the alias web servers then it starts to deploy and Then it checks out all get some modules. It does magic to the sub-modules and some seconds afterwards We have deployed Easy isn't it? We also have a nice little message on the hipchat which says hey I Deployed a site for a customer So that said I try to enable all team members to deploy To live There is no need for me to do to do a deployment because When I get sick no deployment is happening So everybody should be able and you should really strive to the way that you can enable all team members to deploy So that happened. I told two people from our sister company amazing metrics how to deploy with drush deploy they did it and Five minutes afterwards the CEO came to my desk and asks yeah, that's really nice And we like that you do that, but what if they break it? That old yeah, they can break it, but we can also fix it because we can roll back so You need to Calm down some people sometimes So now back to me should we put all parts together to see what's needed to do a drush deploy of course So we start with installing drush deploy we then cover a bit of the drush aliases. So actually who uses drush aliases Good very good So afterwards we will then cover the drush deploy configuration and we will do our first Deployment like running through what it would do So installing drush deploy is rather easy. We just run We just go to the drush directory, which is in your home directory You get clone the actual branch and you run a drush cc drush After running then a drush Command without any arguments you should see that there are now the drush deploy actions So that's quite easy Now we need to get the Drupal sites ready Which is a task when you have more than one side could be a little bit tedious in the end in the beginning so We need to do some standardization We need to clean up all our environments. You need to establish some standards for let's say configuration You need to have like a settings local that php as Drupal 8 does it you can also incorporate this in Drupal 7 I will have some code snippets afterwards You need to standardize your File path your web root path. So actually you need to have a Setup that every customer sites look almost the same. Why because it eases Your workload when you need to change something over all customers you host so what we do we have the settings php committed to to or get repository and In the end we just check if there is a settings local that php and if it's there We just load that when you load the site so That eases us a little bit that we just have the Site related settings in the settings local it gives you a better overview and all configurations you will have in Your standard setup are committed to the repository. So you don't need to change anything there What we also do we do We move the settings local that php to a directory, which is accessible from every server So you just change it once and you run a deployment and it's deployed on every server But we still copied the file to have like in every revision in every Deployment you do there is the settings that local that php Which is exactly from that revision that you know that you can go back and you have the old file again So that's nice, but we also need the aliases. So some of you know the aliases already aliases is a way to tell the rush How your environment looks like you can say that there is a web server one You can give a web route a remote user and the remote host so drush automatically knows by running a Comment at web one on which server it should connect You can also say web 2 is the same as web one, but the remote host is web 2.example.com Which is really easy So what does this enable us? We can run Drush at web one user login We'll take some time drush makes an SSH comment to the server it runs in ULI and it gets back to One-time user login URL to your shell. So that's nice You can also run a drush SQL sync from web one to your default default environment and you get back to data That's also something we you we use regularly because it eases the way you can move data around You don't need to dump it and copy the file you just SQL sync it and you need to know on which server but usually we use the web server one for Connecting to the my SQL server and getting the data back. So that's about aliases I will go a little bit deeper on aliases afterwards because We evolved the setup which we use for drush deploy a little bit over the last two months. So I will Have this somehow split in two parts is the part which I describe how to set up easily and How we do currently the deployment stuff? So drush deploy configuration there is drush deploy.drushrc.php Which has a lot of information in it how drush deploy knows what to do so first you need to know drush deploy needs to know where the deploy repository is so you just fill in your deployment repository and you say Which branch it should deploy I Personally strongly suggest that you adopt Somehow a git workflow We at Amazelabs use the git flow which has It started out that we just wanted to do it and then we try to incorporate drush deploy and say okay Now we need to do it. So what brings git flow to the table? It's one of many branching models. So I don't say it's the right branching model, but it works fine for us So we have a live and the dev branch the live branch Nobody ever commits directly into the live branch. So all Merges to the live branch are done by pull requests or manual merging There is also the way to To use future feature branches that you create a from life From life you create a branch which has the feature number you develop on it and you merge back to the life There's also hotfix branches, which I personally use quite often if I need to fix something fast So I go from life do the hotfix and get back to life. So that's what and one Important thing life is always deployable. There is nothing like oh, yeah We shouldn't deploy life because it will break some small things That's not gonna happen because if you have that you will not be able to automate it Because when you have a life branch, which you can put your hand down and say, okay We can deploy it at any given time You gain some confidence to just run drush deploy at life and it will run through and decide will not go down So that's something you need to do there's something else in the Deploy.rush or C.php the keep releases keep releases tells drush deploy how many release directories it should Keep so that's the steps you can go to roll back Like when you have ten you can go back ten steps in deployments If you have just one you can just go back one Actually, it's not cleaning up automatically So when you run the cleanup there is drush deploy cleanup it will remove everything. That's over that threshold so that's something also worth mentioning and If you use git sub-modules for having the modules you need to tell it get enable sub-modules to true that it knows That it needs to check out your sub-modules unless you will have Drupal site with that some of those the next thing is the file system structure, which is quite a bit different to what You usually do for deployment. So You can prepare your server by running drush deploy setup at web one and this will create you different directories It will create exactly that directory structure without the Public HTML the public HTML is what we use so we have For every website a user and a public HTML directory, which is either a folder or a sim link So pop it when it runs through and it sees oh, it's not there It creates a folder and if there is a sim link or already a folder. It does nothing. So in the current Directory that's a sim link to the latest release. So the current directory always links to a release folder and We have the releases which is a Folder which is created for every time you run drush deploy So you run drush deploy it starts to create one of those folders after it's done It will link to public HTML No, it will link the current directory to the release directory and then the deployment is done We also have a shared directory Which has a cached copy of your whole code? So it does get check out the git pull is all always done there and then From there we copy it over. I will cover that later and we have the public HTML which Always links to the current directory and the current directory always links to the latest release So you see that's a chain of sim links, which is probably not optimal, but it's currently the way we go So what exactly happens? When we run drush deploy at one it goes to every web server It updates your remote cache like the shared directory. I told you it initializes and updates the sub modules So you have always the same the right version in it So and it does it it does it in a harsh way. So it just Trashes everything. That's not as It's described in git. So you are sure that you have the right versions It creates a new release directory and copies over your code base to the release directory It then links the current directory to your current deploy code and Executes the tasks we define if something Goes wrong you can run a drush deploy rollback and you will get back to the web to the Lightest release so it will just switch The sim link as it does for copy strong for example So you now tell me yeah, that's nice, but what's about drush deploy at life? so For multi server deployments. There is alias lists who uses them Yeah, you of course you invented it somehow well drush enables you to tell drush There is an alias life and you can give it more Servers as we just defined them at web one of web two and drush then knows that It's a group of servers So you cannot do every command with it You could do a drush ULI and it will go to every server and give you a one-time login link for every server Which is pointless? But for deploying you can group the servers together so That's nice, but I told about standardization keeping the things together We covered that so If you don't know about a drush alias a thing Go to that URL read through be enlightened because there are a lot of things you can have parent Aliases which take the same data as the parent has There are a lot of things which are not widely used, but they are there since years so Let's cover automated aliases What we do currently is we Create the alias files on the fly so We have a file which stores how our servers are set up and that's a JSON file Which is really easy to see like it's even Open to the wild it's on our GitHub account so there is life is web server one web server to a web server three with the eyepiece and We try to build the server groups Automatically, so or Ali alias is five currently looks like this We have a site name which is the unique identifier to the sites and from there we can Find out how the site should look like and we also can override it in case of we want to override something If some site is currently just deployed on one server Which has changed a JSON file for one customer which then overrides the standard configuration You ask about the time to implement this it was about one evening We did it last year at Ruppelkamp proc the whole team sat together for one evening We went through all customer sites and moved to rush deploy in one evening. It was around I guess 40 clients 50 clients, so You can do that quite fast deployment tasks You can run deployment tasks before or after moving to a new version and You can also say if you want to do it on one or all servers So a drush cc all you just want to run it on all servers because you will have quite a lot of time Wasted when you run it on five servers and it does the same Also Something that's important to say don't link settings files copy them We first linked the settings files all the time and then found out that it's probably not the best idea Okay, we came across that idea at 2 o'clock in the morning So linking the settings file was perfect But when you try to roll back and you did a change to your settings file you cannot roll back because it's a link So don't do that copy settings files um What are we doing with deployment tasks? We update and link Settings local files because we can we will copy it with any revision and link it inside their revision So every deployment will be linked, but we have it copied. So it's also version We will link the sites default files because we have it Centrally stored on one of our NFS servers We will run a drush up to be just on one server We will have run a drush cc all also on one server and in the end We notify New Relic about the deployment which then goes back to hipchat and informs the team that the deployment happened That said having New Relic integrated with hipchat is a really cool thing because every everyone is Kept in the loop what's happening because any anyone from the team knows that a deployment happens So if you see a deployment coming in and New Relic no Patriot duty afterwards calling you that there is something wrong with the site You know who to tell and you know who to set on fire afterwards. So that's easy But We talked about it and said, okay, we want to just have one aliases file we sat down one weekend of work and It's currently not all rolled out yet But we changed the way how we deal with the settings file At the aliases file, excuse me so we have just one file which has the site identifier in it and We have a set of JSON files files which define how life the life server environment should look how For example a staging environment should look like and we can define per customer How it should be it griff it gives you complete flexibility, but it adds also a lot of complexity So you need to think through it quite a lot until you get there and you know what to do If you're interested in it and if you're interested in seeing it come to me afterwards I can show you it's currently not completely rolled out because we are dealing with some problems with over writing environments because we started to have for some If you have like a feature release we have feature Servers which like a dev server which just has this feature on it and people can like brush deploy this feature So it's not perfect yet. Let's talk about mything things. So Currently we also have the thing that we just want to update code. We don't want to run an update B We don't want to run something else. So There is a way to overwrite the deployment tasks But if you automate it in the way we did it It's not that easy to just say I don't want to do it. So my idea is that we have Somehow an identifier on the deployment tasks to say I don't want to do this set of deployment tasks Currently there are mandatory tasks, but I want to do something like I want to do just the linking tasks Or that you have groups something like that Also something if you work the way we do it and you have a new user a completely new created user And you do the drush deploy the first time it will Fail because trying to connect to github Forces you to type yes and enter and because drush deploy is automated. It will fail. There is a patch I wrote which is not very nice. It just Runs the command and does it but it's not working for every so for everyone. So I want to do it a little bit more generically There are also breaking things. So thrush changed in the recent weeks So the discovery of thrush RC files changed which leaves you behind with you run drush deploy and get a lot of errors And it is not working. So that's something I'm working currently on to make this work again because it's I don't know the exact issue queue number, but thrush Changed because through Paul changed a little bit. They want to discover the files Which are for drush just in sites drush and not in sites default. So That also gates give gave us some headaches through Palate changed, but less than beginning of the year. So Drush deploy should work fine with through Palate now because we have the The configuration files which are on life and imported are not in the files in the files anymore They are in the database. So that Was a bit easier. There is also one bug about perl locale warnings They can ruin your day or break the deployment. So the deployment just stopped.  My colleagues can run it sometimes and it's just because Some error passing isn't done the right way and drush deploy isn't expecting it and you are not expecting it either So, yeah, and who uses a PC? okay thrush deploy is not nice to a PC because Every time you change the sim link APCC is oh, there is new code and starts to keep that in memory. So you end up in having your APC Having old code, which is not used anymore in memory That sucks.  We did some deployments and then suddenly things got worse Like you had problems that sites got slow You had sites that just on one server we had 500 errors and something like that and after seeing that we found out that we should probably clear APC from time to time Yeah, no, I want to go bigger It should actually Yeah Thank you for pointing this out. Yeah, as you told APC should find out that oh my god. I might Share memories real running full, but on that version we are running There is some weird bug that if you hit like five megabytes of free space It just starts going haywire and not cleaning itself out. It should but it doesn't. Oh, yeah Keep that in mind Yeah, the thing is on our servers. We are bound to Ubuntu long-term service so we can't just Exchange things so we're working on that too Drupal 8 There's a configuration management initiative and as I told you Beginning of the year there were two directories storing all your configuration So you had either the live configuration Which is the configuration you currently use and you had the staging configuration if you change something to roll it out They found out that the idea of having that is a good idea, but somehow it wasn't practical because You needed to copy files over and you couldn't version it because if someone Works on the same view and commits it the chase and add a jammel file got somehow corrupted and your site broke so The live configuration is now in database which eases the deployment a little bit The dealing with configuration files is also a little bit different, but as I told you in the talk when you Incorporated the local file. You're safe Head is also moving quite fast not as beginning of this year. It gets stable. It's more stable and doesn't break that much it should be a Drush deploy should work with through Palate. I did test it yesterday evening and it worked on our site So you should be fine Yeah That's it Some take-home messages Um We started the drush deploy adventure around one year ago You don't need to do anything Automate in automation at once you can do little steps go with the aliases file first then Clean up the settings clean up your environments go to drush deploy afterwards You don't need to do anything at once because if you try to do this, it's a little bit too much Automatic alias files are awesome because you change You move aside to another server. You just change In a JSON file. Okay, it's now in server 2 and you don't need to tell anyone Because they run just drush deploy and they drush deploy knows that it's there You also need to clean up your environments. That's something I do regularly or I try to do it regularly because Things mess up sometimes you just deploy a patch somewhere and you do something and drush deploy really forces you to do At least in the life environments nice work that you don't deploy something just on life So because on the next deployment when somebody does the right process you just trash their changes Standardization saves time. That's I can't leave that without saying something. It's just the way it is and Deployments are fun when you run them with drush deploy because anybody can do it in the company. So, yeah If you want to download the slides, you can go to s.nurdy.ch slash drush deploy Amsterdam and Yeah That's it. I'll be here for a quick Q&A if you have some questions Can you probably pass the mic Somehow because it's all recorded and it's easier when people have it there. Can you specify? extra commands to execute per target So just executing comments on one target When you when you deploy to a staging environment, I want to execute extra commands like enable the mill reroute module, etc Currently not that's also something you could try to do or Is something we also want to do that? Model enabling disabling Thanks Probably he can answer the question a little bit better. Yeah, so and then that's a very Very common Like sort of feature request that ended up in the queue for drush deploy and yes, like there could be a lot of Drupal Specific tasks that you could add to it to do things like that But you can still do all of it by just Creating an after task like a creating a task like he showed and then run it or set it to run before or after the deploy But that would run for every deployment if He asked specifically about like if I have a stage alias, and I just deploy in stage. He just wants to run It for the stage right so and and it's common I mean I used to do some couple strata all the time where you have even you have your things that you're going to run on every deploy But not every deploy needs the same tasks like say like rebuilding No access permissions. You definitely don't want to run that but sometimes you need to do it once I don't think there's anything wrong with just make putting that in your file Maybe committed it running it and then taking it out because then you're documenting I needed that for this deploy and I don't need it anymore. Yeah, that's also a way About the questions No, yeah, I can rephrase it. Yes and no so he was asking if the Path to the files directory needs to be set consistently. Yes, but it's a per site consistently Yeah, because every every site has a different configuration So you can have it on every on every site a little bit set a little bit different. That's a good question No, unless you do a drush SQL dump before so What we are doing when we we have two types of deployments currently one is When we can agree with the customer that they will have a staging server created two hours before and they have a content freeze So we can just prepare everything on the staging and then move to databases And if something is not all right, they will spot it on the staging and Rolling back if you have a lot of user-generated content that will create some pain for you. So No, not yet But you could run a task to dump the database and then for the rollback unit just to keep it in There's one related thing about that Because you showed the you can put tasks before and after that's actually very much related to rollback And so any task that's before if it fails that automatically triggers a rollback So in the case where you deploy It's already live things are happening and you need to rollback then you're you're in pain but if you if you have a bunch of tasks that are running in the database and they're all in before hooks as long as you in the At the start of it say dump the database first any of those can fail and then you can still restore that And then flip back So the the tooling is there for it. You just have to set that up yourself depending on how you need it done Yeah, that's right He was asking about if we wanted to do stage deployment and using features Yes, we thought about that We are using it for some sites that we run we use features but It heavily depends on the site sometimes if you just needs to push out some code or some CSS changes It's easier to just do it that way We also have something where our developers are working on which is kind of like features But it's for it's easier to just code things and do the changes in in up DB hook So we partially use that yes Does that answer your question? Contestation right No, so Everything that needs to run stage so we have one customer which has like publishing of yearly results So we prepare everything on a staging environment and then Copy it over to have a consistent state of everything. So we don't use it yet Yes That's not Related to to drush deploy in Because rushy play just does the code site the SQL sync is done still manually currently, but you could also do it I guess there is a way to exclude tables from a sink Yeah, SQL sync is not part of the game. So you can you don't need to SQL sync That's not mandatory you can script it, but it's not mandatory Other questions Not okay, um, please rate my talk I'm happy to have some feedback and if there are questions or you want to see something just Come here Thank you


Here are the toys. I promise thanks a million Louis for contributing to our toy drive glad to help clean out the closets The kids will really appreciate my pleasure. Say, I don't think we can use this one. The edges are too sharp Better not take this one either look that point Let's squeeze Troy That little part can be swallowed. Hmm too loud could hurt little ears Oh, is this lead paint? I don't know Sorry, Louie. You can't be too careful with toys Next time make sure they're all safe before you buy them for further information Write or phone toll free the US Consumer Product Safety Commission look at the new toy. I just invented what's that? Well, it's a combination tool set an electric hedgehog kids will love it. It's educational Uncle Louie. You couldn't make a worse toy has sharp points and edges And glass and plastic they can breathe. It's too dangerous for kids got to be careful about toys Well, how about a toy marshmallow that sings better? For further information write or phone toll free the US Consumer Product Safety Commission Marge like you said I stopped to pick some toys up for prizes at the school fair all perfectly safe. No sharp edges Nothing for the little ones to swallow isn't this cute no lead paint nothing to catch fingers in How did that get in there? Enough to scare a poor child half to death horrible For further information write or phone toll free the US Consumer Product Safety Commission


Let's send a link to a website. Follow along with these quick steps. Welcome back to Burn to Learn. Step one, locating the website link. If you would like to share a website link, you will need to navigate to the actual webpage that you would like to share with others. Once the page has loaded, look for the address bar in your internet browser, normally located at the top of your screen here. For a Windows computer, you can simply press Ctrl plus L to be taken to the address bar or Command plus L on a Mac computer. Step two, copy the link. Using your mouse, select the address of the webpage by clicking and holding your left mouse button while dragging it across the entire address like this. Alternatively, a keyboard shortcut to select the entire address is done by clicking anywhere on the address bar and pressing Ctrl plus A for Windows computers or Command plus A for Mac. A blue highlight will appear around the words that have been selected. Make sure it includes the entire address. Now right-click and a small menu will appear. Select copy from the list here. Again, you can use a keyboard shortcut once you have selected the address link. Press Ctrl plus C for Windows or Command plus C if you're using a Mac. Well done! The link has been copied to your clipboard and is ready to be shared. If you're not already subscribed, make sure to like this video and subscribe for more straightforward tech tutorials. Step three, sending the link. Now you can open your email, message and application or the program which you would like to use to send the link. To demonstrate, we are going to use Facebook Messenger. Once you have opened the chat of your chosen contact, right-click anywhere inside the area where you write your message. Inside the menu that appears, select paste. Again, you can use a keyboard shortcut to paste the address link. Press Ctrl plus V for Windows or Command plus V if you're using a Mac. The link will appear in the message box and can now be sent. Once your contact has received the link, they should be able to click on it to be automatically taken to the webpage you have just shared with them. For other easy to follow video tutorials, make sure to like and subscribe to our channel and show your support by getting your stylish Burn to Learn t-shirt in the description below. If you want to learn something that we have not made a video tutorial on, leave us a comment about that below. This has been Rod from Burn to Learn. Thanks for watching.


Vova carefully holds one of your eyes open and begins to prod uncertainly the needle Okay, so who wants to recap of what's happened so far basically we went and we explored down south and we have an Amazing like a little side quest where you go and you find this you find this old lady who's She's getting friggin jumped by two guys, and they're like hey, where's the girl? And then I end up killing the guys that's what I did I killed the guys because they were attacking this woman and then after I killed them the lady was like actually I know where the girl is it was their sister, and it's like, uh, okay. Well now I killed two people I can explain let me tell you the girl so then I take you to the girl or she takes me to the girl She didn't meet me at the tea house as I'm going to the tea house I see a sheep I see that sheep, and I'm like hello sheep, and I go to pet the sheep and it says Like that's weird sheep don't sound like that So then I took my sword and I did divine smite and I slammed my sword right through the sheep's head And then what happened whenever I did that was it turns out this entire Beautiful forest was actually a swamp. It was an illusion, right? It was a trick. Wait, what? So whenever we get to the tea house.   He came back as a zombie not as a human. So what I do I gave her the wand I said here you go You own your zombie husband now and then she ran off with her zombie husband and her baby intact So I was pretty sick actually that was probably like I would say that's probably the best stretch of the game That we played so far was yesterday. That was super good. It was super like Yeah, it was like fascinating. You forgot the part where you killed the zombie husband as they were walking away Yeah, we'll leave that part out. That's fine. Okay, we're gonna we're gonna go back to town too Wasn't there something else here that I was gonna do the cow. Yeah. Yeah, moo moo moo They give the moon the moon. Yeah, we because we have something that lets us talk to animals Uh, hello there, mr.  I drew it or two. I suppose But the novelty remains fresh Did you come from el toro with others? I suppose I did Yes I had quite a life in el toro chewing card pulling cards Etc There's something strange about this ox. What is it?  That's what we're doing. We're pressing it.  Oh come on old chap. I'm a devil for gossip 10 I got this easy. I just rolled the 20. It's gonna happen to Okay We're gonna.  I'm rolling a 20 Here we go tell you this much I'm going to boulder's gate with or without the rest of these poor sons Now that's all I have to say besides and I really mean this Move wait what? M-o-o Timing Timing is so good. So what he's some kind of like a trojan horse apparently. I don't know. That's that's what I think he is Every time I tune in you're killing animals. What's the deal dude? I just I like killing random innocence and then reloading. Okay. What's wrong with me? Let's see. I guess we go straight into the under dark, right? Under dark time chat. What is this? This is like a weeder Why why did I put a weeder on the mat, dude?  What is balder's gate doing starboard? Okay, this is nothing like the starboard logo. Okay He's not a normal one. This one's obviously broken. This is like, you know, it turns three times Dude, this is the fabled penis f Under dark duergar boat Sail into the darkness Here we go chat we're going to the under dark Oh nothing, you're in the under dark now under darker under dark and darker Uh, where's gake and who are you? Well Intimidation In the name of the absolute you will let me pass Deception I'm afraid gake is dead or athletics pushed dirt I got this Oh didn't even need the bonus lazella proves Okay, I'm gonna make them wet good Oh, I don't have any more lightning damage though. Oh, yes Oh, I got one of them.  I play like a wild mage just blink in there and frost nova. Okay Yeah, that's a rat. I'm afraid gake is dead There's a five percent chance, dude critical fail, dude. I should have done a long rest, man Wait, oh my gosh. Do these guys have good loot? Or no The course there has good loot. Wait the one that I just knocked has good loot We're just gonna hit a long rest a nice long resty rest. I don't need to talk to anybody doing My friend, how do you fare? Is your research turned up anything for this parasite problem? My research turned up a rather brilliant technique that seems quite actionable It's not too deep Just behind the orbital socket. I could attempt an extraction I've a needle in my tunic after all Wait, what what are you doing? Uh, uh, dude. I I want to leave I want to leave How many times have you done this before I saw you I've dreamt of it a thousand times over Trust him. He's a world-renowned newspaper guy. Dude. This is not looking good Volo carefully holds one of your eyes open and begins to prod Uncertainly I was gonna leave but I just want to see the cutscene. Do you have the faintest idea what you're doing? Don't fidget. The needle must slip behind your eye not through it The needle finds the gap between eyeball and socket Volo frowns and begins to push Crunch your fists And shoots through your body as the needle snags on your optic nerve The needle seesaws back and forth plucking the nerve like a harp string Oh, father There's some obstacle in the way. I shall need a more robust implement That obstacle is my eye Oh, this was possible carefully withdraws the needle from your eye Then reaching into his bag He produces an ice Slowly brings the ice pick closer to your eye now Don't move Dude, hold on if I cancel at this point that you just are you like what happens? Holy red cold metal presses against the skin beneath your brow and then Tap tap stab Do you feel that? Huh, I think we have the blighter on the run I stick it out.  That wasn't planned. I don't want this. I just wanted to see the cutscene I can't seem to see through one of my eyes. Yes, quite Well, there is some mild trauma. I can't help but feel partly responsible No loading Take this a far superior relic to that old jelly you were trained to try it on for size And um, it was very nice to have met you I'm sure you'll sort out your little brain problem one way or another Far away from here. If you've a heart terribly. Sorry my friend. What? Conditions bleeding eye check both C invisibility. What no, no, what do you lose though?  Should I keep it? I wasn't really playing on keeping it. Okay, whatever. We'll keep it I'm not gonna push him. I'm afraid gake is dead. Oh, no. Do I not have guidance anymore?  Let's get you to shore.  He's got the gold on him Sergeant's arm is falling off with all the known slaves. She's been beating. Who's the whom grayman another slave for the dig I'm a true soul and you will treat me with respect. No, I was told to report to the sergeant.    There'll be hell to pay for the lot of you cult buggers Okay, so where do we got to go next see interestingly enough it says that there's This way for the quests, but do I even need to be here am I going the wrong way?  I don't give two shits Sounds like the shadow curse We must be getting closer to moonrise Perhaps we should seek out this near while we can near automato moonrise tower holds the answer to seek curse or not We can't turn back now. Stop in the dark. It is Well, look they'll they'll say let's do it. Let's do it The elvenator you're about to progress your adventure chat. Is it time? That's act two Wait, is this act two right here? This place is huge. Don't go yet. Okay Okay Touch another innocent and I'll take your head near you care for the weak true soul Most curious And you waste your time persecuting them that is true weakness You dare speak to me without due reverence That was your first and last mistake trim The car about his heart and serve it to the rothay If he indeed is a true soul Let the absolute save him. Good god My oath Let us see which prevails This true soul has betrayed us Let his blood prove your devotion We really set us set ourselves up for bad. Okay. We're gonna run a bless on you and you Okay disarming attack They have not attacked So if I disarm you Saved action surge Another disarm 99 chance to hit Dang it hit, but it got saved. Oh my gosh. He gets two double attacks Oh my gosh, dude. Lazell is overpowered now and I have another off-hand attack left Should I try and a we these two? Oh my gosh, that's a big a we dude.  He's gonna attack next. Oh my gosh genius idea I'm gonna put gale over here. So he's he's out of range Okay, I'm gonna put Lazell here to be in between these two people to have a chance at getting attacked by both of them Two reposts and then two attacks of opportunity Oh my gosh, dude.  I can run into this Cleave.   I missed on both Miss miss. I think she misses No Wait, what how did gale get pushed in the lava? How did he get pushed in the lava? Can I can I can I pull him out? um Wait, did he just wait gale is a what gale's gonna live wait on I just kind of missed Repose look at the big repose. Okay. Hold on on. He has nine health left passives turn off my great weapon master Come on.  I don't want to waste it Okay weak grip. What does that do? He has disadvantage on attack rolls and strength saving rolls Shield of screams Just don't shoot shadow horse Okay, I'm healing. I'm healing Nice. Okay, so I'm gonna save now. I've missed you sexy Wow, dude, that was an amazing fight Okay, lava valve You know that's what we're forging got the iron man. I was literally just gonna go to bed after this, man Level eight 300 health. Am I supposed to be here? I'm just running the lava to hit him Uh, did he just hit this thing and cause more lava to come out? I wonder if a lightning damage against this thing is just like, oh, okay. It took a zero damage for one 28 damage Eight, dude.  Are you romancing the most and why is it carlac? I'm romancing myself Take you Okay, we're gonna raise lazele And lazele will second win Dude, I feel like I'm owning like he's he's already half health Oh s-fan is incapacitated. He is lethargic for Oh because of haste consumed by the exhaustion of the aftermath of haste Nice Oh, no attack opportunity again.  Why'd you fall? He's the carry dude. He's the big damn. Okay Okay, drop the heal on s-fan. I'm thinking about how I can even do this Maybe maybe if I throw And I throw the torch at him. Okay Threat assessment prime target. Okay Now I jump to the center I am now have aggro of him. He always attacks last target. He's going to run through the lava and he's gonna get super heated again. Okay In turn gala's dunzo, but he's gonna get burned in the lava here.  That was so good, dude


What does it say that Craig Bresla was at least willing to part ways with Chris Sale who I think most of us knew probably was gonna end up on the injured listing end this year and not be much of a contributor. Yeah I mean it says a couple of things it says one they're finally in business and that this off season has officially started for them which is something we've been waiting and waiting and waiting for. You deal sale you've created an opening in your rotation which already needed help so you're gonna have to fill that so I think we're gonna start to see more moves so that's good and the other thing is it does show how business is changing. Heimbloom had the opportunity per Rob Bradford at WEI to trade Chris Sale to the Rangers. He didn't do it. He couldn't pull the trigger. This was a problem. You have Bresla who comes in and says I am going to be decisive. I am gonna take action. I think this is proof of that and on top of it he got a potentially okay player for him in von Grissom a young second baseman with some power. He's a 320 hitter lifetime in the minor leagues home at his debut at Fenway. So you've got something for him as well. It wasn't just a straight dump so it's like all right we're just gonna need to see a lot more of this. Okay so the only thing when you're talking there that like a couple things caught my ear. One they finally entered the ring. Okay cool like welcome to the party everybody else has been in it since you know mid-November.  Yeah I mean there is no full throttle right now like G. Alito to me if he's the second or third best guy you get this winter then you can say it's a success. If it ends up that he's the biggest acquisition you make for your rotation then you are in serious trouble. I think the Red Sox look at him as a guy because he was he got Cy Young votes in 2021. Well he's not that far removed from being good. Last two years have been terrible. Second half of last year was abysmal but they look at under the hood I know we all hate this but they say you know what the fastball is still there the shape of his pitches is still there he just needs tinkering so they hope there's something there but big picture full throttle we have not seen that yet. I don't know that we will.