 Welcome everybody. Thanks for coming. I'll try to make this quite light-hearted presentations into the day, you know into the two days. I'm sure you're all pretty much like, well, just want to get through it. So Failing a star with your host Alex or leaks, you know, isn't the vegetable or you've got problems with water coming out of pipes. So I'm from Wepscope in Auckland, New Zealand. We're sort of small Drupal shop, but we like to do things a bit differently Down under we're down under here, but even further down under in New Zealand, you know, we're even further behind the curve So we're quite, you know quite proud of the fact that we do automated testing and we have a continuous integration setup Because a lot of the shops down there don't have that and don't do that sort of thing I've been developing with Drupal for about four years and been a developer in general for about five reasonably self-taught so I'm not super confident about my abilities and I Suffered from a bit of imposter syndrome. Does anyone know what imposter syndrome is? All right, cool Okay, so if I wasn't here, I'd rather be at um, I think it's horn cologne's talk And if I couldn't be there, I'd rather be at the MIT Bitcoin expo. So it's happening right now So just to start this off See I is a pretty big topic and it differs a lot from project to project So I just want to say that this is not a talk about behavior-driven development or accepting acceptance testing we do use acceptance testing at the heart of our CI implementation and It's not really so much about why we've chosen certain software and things like that It's more about really practical about how how we've actually done it So yeah, a bit of AMA after the presentation, but they probably won't be very much time because it's a big topic so Just like to thank basically these people because you know You never get to where you are without anyone in this world and it's important to reflect and look back on those people So Shane's to be given my first job at Jiminy Dave would second that code of web and I now work for web scope Michael Kadinko is a developer at web scope and he put most of this stuff together So most of this kudos goes to him and I'd like to thank Bevan Rudge and Auckland Drupal meet-up group who helped polish this presentation a little bit so Tell you a little story about you know experience that probably most of the developers here can relate to I Was thrown into a project, you know on a on a Friday And I had to fix up this, you know web form that was for entering a competition And that was going to be launched at 12 o'clock the next day I didn't really know too much about this, but it was quite a complex thing. It sort of had auto-saving and Ajax involved Basically, I had sort of done what I thought was doing and I was doing it right and I got to the afternoon And I sort of boss came along, you know, how's it going? You know, it's going it's going really well It's going sweet So I thought and so I gave him a link to this form and he went went in and started testing it and he comes back and he's like This isn't working quite right and I'm like, oh really it's strange because you know, I just wrote that code this morning It was working sweet And it turns out, you know, I'd introduced a bug later on that it you know caused this feature I've written it earlier to break and Subsequently, I then had to spend quite a lot of time going back over and fixing up quite a lot of my code because I'd written it based on The fact that this was working I You know, I think I had some issues with jQuery and I had to change the version and that stuff stopped quite a lot of other things but Anyway, I got it done, you know with a couple of hours to spare by the next day and all was well But you know the general theme there was that if I had have had a way to identify that bug earlier You know like within an hour after it was introduced and I could have quickly gone back and fix that and Bugs and programming it Inevitable, you know, say the first quote here if debugging is the process of removing bugs and program must be the process of Creating them or putting them in So software is written by humans and therefore it has bugs, you know, and I don't think there's anyone out there Who's writing any software without bugs unless it's a one-liner So if you could spend the time and find and fix all the bugs in your projects Then you can't complete the project in your lifetime Even the biggest software projects in the world that have been out on the web and a crucial to security and things like that Have bugs and they're not discovered for years and years and years I think the average is about five years for some security bugs that have been well Sorry, I read an article that was talking about some bugs and curl and things like that And some of these bugs that existed out in the wild for five years before that been found that was the average time So even the biggest projects have bugs so they're inevitable when we just need to catch them And if we can catch them, I think we can save ourselves a lot of time and a lot of hassle Okay, so just a little bit about you guys Who has his virtual box or VMware or some sort of session, okay, cool. It's about 95% of you Okay, so who's tied that up with vagrants cool About 85% maybe a bit less Okay, and so who has used the provisioning tool like shift puppet or Ansible Okay, that's about right. Maybe about 45 senior And who's tied in a testing framework acceptance testing like be had or Co-deception I Think my numbers are a bit off here now The bit ambitious on that one I've seen some of the earlier talks and I tweaked these numbers a little bit. It was quite ambitious It seemed to be quite a onto it crowd around here And has anyone used sort of a see I tool like Jenkins or Travis or Hudson? Ah, cool. That's a few more than have done testing. So that's great. I'm accepting testing at least and It's a moving on to The very highly the highest level part of this talk. So what is see I so I feel like me you want to know about something go straight to Wikipedia Continuous integration is the practice and software engineering of merging all developer working copies with a shared mainline several times a day And so to break that down in my words Basically means you can take all of your working code and you can merge it together into a production form Essentially at any time that you want In Wikipedia, they say you could do this several times a day But they're kind of just hitting at the point that you should be able to do it anytime that you want And at web scope because you know every see I implementation is different We're getting a bit more specific and into what this example is about And our Drupal specific example. It means that we take all the code. That's ready Merge it into production form which involves using the real data So it's got latest code base and we get the database and the files from the live website and pull them in with the latest code and Then we build a new version of the website and we run a set of acceptance tests over that version of the website I think I want to mention Michael got to talk earlier, which was really great on continuous deployment And that was the much the solution that's a much further down the line than what I'm going to introduce today So this is much more lightweight than that and hopefully it's practical and lightweight enough that you can take something from it and use it And start to implement it So just really quickly. This is a bit of a why but it's a really high level So benefits of running see I you're gonna find those bugs real quick You can test at volume. No, if you if you're just running your test locally You're probably using to wait for them to finish and that's causing you, you know That's costing time and you don't want to do that if you can Dispatch that off to a built server then you can do it as many times as you want You can do it over and over and over again You can do it many more times and you could possibly ever do it on your local machine And probably the most important thing about see I and about automated testing is that you Feel empowered when you're writing the code instead of feeling scared that you're going to break something So I'm sure many of you have had a situation where you come on to a project that's been developed either by someone else or maybe even by you but a long time ago and You're not really sure about even what what this website is supposed to be doing Let alone what you know if it's broken or not when it when it does break so if you do have Acceptance testing and and the acceptance testing isn't really necessarily part of see I you can do acceptance testing without see I But see I is kind of pointless without the testing component whether that's functional testing or acceptance testing This example only covers acceptance testing because that's what we do it with scope But yeah, if you if you have acceptance tests in place They can tell you a lot about the functionality of the website and what it's expected to do and of course they're there So you can run them and if they fail you know that you've broken something I Mean there's a whole nother discussion about test coverage and how many of the how much of the functionality is covered, but there's a lot of things in this talk that can get really complicated really quickly and You know can be debated. So we're just going to skip over most of that And another really positive aspect of it is that you can relax as a developer You can feel a lot less worried about what you're doing It's better for your health and that goes through to you know your bosses your managers and your clients as well Everyone can feel a bit more relaxed if they know that you've got a nice see I process in place okay, so Here's my wonderful graphic about our see I process with scope so It's made up of quite a few different systems and They can be complex, but we use them in a very simple way and I'm certain that your average developer can understand Every part of the system So don't be afraid at all if you You know if you think I know this is going to be too much for me And just put your hand up if you have any questions, of course So step one of this see I process that we have is pretty standard We've got a developer who's obviously pretty smart He's been working away He's been writing some code and he's written some really nice code and he's written some tests for it And he knows the tests are passing and so now he's not having a much deserved to rest there As we all we all deserve after we've written some written some good code and then he pushes it up to the repository So this part you're probably all pretty familiar with as well You know you write code branch feature branches and dev get flow or whatever and you push it through to the central repository so in our case we use bit bucket for that and The central repository is then monitored by the Jenkins continuous integration tool so Jenkins is it's a bit complicated. I guess but Jenkins is going and checking the bit bucket repository Repositories to see if there's been any changes since it last saw them and I think it does this periodically but You can also set up a webhook from bit bucket to just say to Jenkins Hey, something's changed and you can pick up on those changes much faster and and have a build Build running, you know sooner rather than 10 minutes later or 20 minutes later. It can run straight away And so what Jenkins does is when he does notice a change in the repository as he basically just executes an SSH or SSH's into the bolt server and executes a script and That then monitors that script or Jenkins then monitors that script and sees all the output from it And at the end the script exits with you know a zero or some other exit code a zero indicating a pass and another exit code indicating a failure and Then Jenkins does some cool reporting things and you can get it to do whatever you want in our example We receive an email about the build and we also have an integration with our chat system Alright Yeah, that's right Okay, so the tests are all in the repository as well they're committed when you commit the code And now set up here and I'll show you that That's right, yeah, I will talk a little bit about that yeah So All right, I think step one everyone's gonna understand this does anyone not understand I know this is really bad thing to do but raise your hand if you if you don't know about Writing code and pushing it to a central repository You know, okay, so I'm sure everyone knew that so that's sweet Okay, step two Post commit hook so like I said this isn't really necessary because Jenkins does the Jenkins plugin for bit bucket and get Does monitor the bit bucket repository and after some time will detect that a change has been made and start a new build But the webhook from bit bucket just lets Jenkins know that something's changed right now and just take a look and see if it's time To start a new build Yeah, what's that? Start some CI if you have insinets, okay, so I Think I'm in full-screen mode here Or can I just bring it My editor. Oh sweet Okay, so Here I have a simple test Sorry, not a simple test. I have a I have an acceptance test from code section. Oh, you can't see it So it goes I thought that was on screen and if there's anyone familiar with code section at all All right, a couple you a little bit code shipments kind of like a testing framework for PHP and it can do functional testing and it can do unit testing and it's a bit of a wrapper around Selenium basically for the unit for the acceptance testing side of things. So it's kind of uses a skirkin format And we won't I won't get into the merits of why it's good but it really works for us and I do recommend it as a great testing framework and We use only PHP Yeah, code sections PHP based testing framework only so all right, so here I am Inside a web route so I'm sure you'll recognize something like that that's a Drupal web route and Our code section tests all live within this test folder And that's where I am at the moment. So This is the normal structure of the code section directory when you have it on the server And this is the high level part and the main things here are the code section YAML file is your configuration file and If you want to look at that real quick pretty simple I'll just say that this tests directory is available on github for you to download afterwards So you can download that stick it into a Drupal site and you'll need to configure You only really need to configure the URL that it's pointing to so that's just your local development URL and then You might have to create the logs directory and make sure that it's writable But there will be there isn't a read me there on on that now But I will make a read me up on the github repo for that You don't have a separate That's right, that's right, so we use phantom.js which is like a fully fledged sort of hitless browser It does CSS it does JavaScript. It does everything that that we need it to do. It's quite powerful. I highly recommend that as well Yes, and I make screenshots Okay, so I'm gonna run a test now and I'm gonna run this test that you can see here So this is a basic Conception test hello world you can this this these lines don't do anything they just Output for humans and then this is a really simple test. I'm on page slash I'm on the home page and I can see the element and that's a CSS selector Okay, so I'll run this test and It's as simple as this so one acceptance test is run This is some of the human stuff that you see I'm gonna check the site is loading as an anonymous user I'm on the home page and I see the element skip link and you can see that test is passed Another little thing here is resizing the window. That's just a Function that's called beforehand Using the before syntax in the in the function comments That just resizes the window to something appropriate So you can use co-exception if you want to test mobiles size it down to a small window and test to see if This will this all that elements visible in that particular view Okay, so now what I'll do is I'll start an actual CI build process so I Have some files that I stuck in the commit. They're not really relevant and I was when I so what I'm going to do is I'm just going to commit these files And I'm going to push them and So hopefully you all understand from the graphic earlier that we push the files up Bitbucket hook is saying to Jenkins. Hey There's something going on here and maybe right now Jenkins is Logging into bitbucket to see what is happening and if there's some some builds that need to be run And it should find that there are some builds that need to be run and it should start running those builds Okay, so we'll just we'll go back to that in a bit. Hopefully it will work I'm not really sure about the internet setup. So after you've done With Jenkins what he does is he checks bitbucket and after he's checked bitbucket He runs this simple command. So it's just the SSH command that is SSH is into our build server And it runs the site build.sh script and it passes in some parameters So it passes in the branch name the build number and the site name And I'll show you that now I don't know. Sorry. My slides is coming to the other screen here, but all I can see that so This is the the main back end of Jenkins and these are the products that we have set up at the moment and On here, you've got some Sunshine and clouds and decaying of builds have been passing or failing information about successes and failures and I'll go into the conflict. Oh, I don't want to do that As I'll go into the configuration for this again, this is all quite simple stuff I don't think there's anything that's going to be confusing in here for you guys You know, I'm not you know, I'm not the smartest developer in the world and I can understand it. So And so some of the things in here, we don't use all of this configuration I'm just going to tell you about what I know about Project name description that stuff's pretty self-explanatory. I don't know about this card old builds But you can imagine I'm not sure why it's ticked either, but I can you can imagine that's to go through and delete old builds that you're not using anymore This is pretty important your public key. So you need to put that on your build server so that Jenkins can go in and actually execute those SSH commands We have the slack plugin for Jenkins for a slack chat. Did anyone use slack chat? Cool Yeah, I'm sure you can get um, you know flow dock or hip chat integrations and everything as well So put on the channel that we're posting to and the situations that we need to be notified So build start we just get everything here. I don't think we actually Have things like a boarded builds and not built builds and unstable builds Those are more complex functionality that we we don't use yet. What's on identify with? So source code management, this is where the bit bucket stuff happens We have a bit bucket plugin for Jenkins This stuff's all pretty easy to set up and I I'm gonna provide code samples for all of this stuff But the Jenkins service I can't because this is a hosted service that we use at cloud bees So it's hopefully this will be enough to give you an idea of how to set that up And you just install the the bit bucket plugin I believe and get if you wanted that github. So yeah, we put in the repository URL Do for south and then some credentials so that Jenkins can log into bit bucket and check to see if there's any changes that have been made And then we tell it which branch to look at so we're looking at sprint one branch in this case I'm built triggers but when a change is pushed a bit bucket. So any trigger we've got and Here's the script that you saw on the last slide. So that's the command that Jenkins is going to run given That this has been the branch that has been changed on this repository So yeah, just there's really only two bits of information here. Just the repo on the branch you're putting in The site name is another bit of information and there's a Configuration file on the build server which has a lot more information about that particular site and I again that code is all available as well I've actually put the link to the slideshow and the links to the code examples up on the Drupal South We page for this talk. So if you want that just go there and you can see it all So down the bottom here, you've got the post build actions simple email notification here and Slack notifications, which you saw was configured up top okay, so now we're going to see if Jenkins is actually been running a build and That's this cloud B service is a little bit like kind of unreliable it automatically picking up the builds It does it about 85 to 90 percent of the time and then other times. It just I don't know what it's doing so last failures Four minutes 22 seconds ago. I think that that sounds like our build. So if I click on this board and go through to the console output I can see what Jenkins saw when I ran the build on the server and Looks like there's an authentication problem not only have I not had it before I've never had it Okay, that's a bit done, but that's okay. Anyway, we can still move on without that essentially what it does here is it goes through and We'll move on to the next slide, which is going to help explain that so All right So this is the script that is called by Jenkins on the build server to trigger the build and run the whole build and then return and exit code To Jenkins which is determining the parcel the fail of the build so at the top here We can see that we've got some parameters coming in that we've that we passed to the script But of an echo some information and then we change into this directory where there's a bunch of files and directories that are expected And then we run An Ansible script to do a whole bunch of stuff. So I'm not going to get into Ansible here I said to say that it's really awesome and It's basically like a bash script big long bash script if you want to have a simple idea of what it is in your head So it's it's doing a bunch of stuff there and what it's doing is it's you know It's taking the latest code from bit bucket. It's taking the database from live. It's taking the files from live It's marrying it all together and it's creating a whole new a new website a new virtual host and everything like that Yeah, so once it's done all that we change into the newly created directory so we can see we're passing in those arguments into this Directory name and changing into that directory and then we're changing straight into the test directory Some of the stuff's comment I'll talk about that if there's time and then what we do down the bottom is this is where the Magic happens we run the co-exception command to run all of the acceptance tests that are on that website So just goes through finds all the tests and just runs them all one after another and if any one of them fails It's going to return an exit code is greater than zero and the build will be considered a failure We don't have a setup yet where we get information about how many of the tests have passed or failed Which is unfortunate because that granularity would you know obviously help and be beneficial That's probably the next step for us actually We do have a code coverage tool, but I'm not going to talk about that at the moment So I've actually just remembered I should I should have some builds from earlier that I But I tried out and that should still be here. So this is one of the you know the benefits of all of this So these are the old books that I've kind of been running up into up in preparation for this And this should be the same build that I was running that failed basically So yeah, this is some stuff that happens before all of this tar stuff That's all the answer both script running. So Some of the stuff should make pretty much make sense if you were automating the setup of a new site So we're pulling code creating settings files HT access creating databases Downloading the databases we host with Pantheon and they have some nice drush tools to go on and grab the latest copy of the database and the files for us unpacking renaming file permissions Registry rebuild if you've moved module folders around maybe you've moved it from a contract folder into a patched folder Or you've just organized your modules. You need to rebuild the registry. Otherwise, you're going to have a really bad time and Other things like Updb features revert all flush all cases There's all things that you kind of need to have implemented to make sure that your builds your site builds gonna make it through To the ends no matter what changes that you've made And then so down here Simple output very there's that code exception output that you'll be familiar with from here very similar and Down the bottom there. You can see that the finish was a failure All right, so the test that failed here was hello world's test Which is interesting because I thought that it would have been this one that failed but anyway, we'll get back to where the magic happens Is it anyone that's sort of confused about any of the parts of this process at all So we have our own build server for running all of our CI stuff Basically, yeah, and it's probably more expensive to do that as well demand So we have we have pantheon which is our hosting and then we have Jenkins Which is this hosted service that we pay for and then we have our board server. Oh, yeah, so yeah get our repository It's the future No, no That's right, so we just sort of just set up a new configuration with basically the same parameters for that And so back to your question earlier about, you know having different branches You can set up Jenkins and as you saw in the example we put the branch in there that we want to build I think there's a bug with the Jenkins plugin for Bitbucket and it doesn't pass through the branch So we can't just build every branch that comes through otherwise we could set that up But it's not too much of a loss. Usually we just want to build something specific anyway Yeah Yeah, we don't do that sort of traditional software sort of base continuous integration We've got a bunch of people working and working and we just need to want to build like a couple of times per day We do build on every commit and I Mean is it useful? Well, it's it's not really detrimental. It doesn't really matter if there's a new build for every commit and Yeah, I guess in that case it is useful You might see a failure earlier But if you're just doing like a bunch of small features and it's you're doing like five features over the course of an hour You might just put those all into one commit and do one push rather than Push push push push and then you'll get five builds which to be honest It doesn't even matter like it doesn't really matter Okay, so yeah, there is a bit of a nicer interface I suppose you could say but it's not it's not a software application. So to speak it's just slack chat and so we get notifications via email and by a slack chat and of course you can set Jenkins up with all sort of sorts of integrations to send the data what you want and Another another part of the feedback cycle is that you know, it's building a whole website So we actually have that website and we can then log into that website and we can see first-hand what has happened with that build a great benefit that Another great benefit is that is that we can sort of pass that off to a client if a client wants to see You know with you know, where's the later set of work at we just send them a link to this build server and away they go. Oh Oh Well, so I'll see if I can find that So I'm gonna get confused by this double desktop thing and I'm not really sure Where all of those tabs are gone down here. All right, so Here's slack chat over here, and this is the failing with style channel that I've set up and So you can see that This is a bit bucket bot. We've got that set up to talk into slack chat as well So it's saying That there's a new commit and this is the commit message failed build and this is who's done it and then down here Jenkins bot coming in and telling us that it started a build with these changes by this person and then The build failed after one minute and 22 seconds of running That's pretty short build sometimes if you get a lot of tests and a lot of functionality The book can last quite a bit longer It's quite hard to speak that process up with acceptance testing because it's going, you know As a human would throw all the pages and clicking on these things so it's subject to load times and things like that Whereas for functional testing you can maybe do some tricks to really speed up the running of your tests So Some were in here, and this isn't the friendliest way, but there's a URL to the actual Build and in the meantime, I'll see if I can sneak in here and I'll see if I can So here's a bit of a more complex test. Hello contact form. I'm on the slash contact page I see contact web scope Fill in a couple of fields click submit merchants field is required If I run that test here You can see that this is failing. Okay, so This is the actual website that it was just at my local site And if we go to the contact form and see that the name email and the message field isn't required So if you fill these out and click submit you will like be able to submit this form But one of the requirements here is that you know the message field is Filled out. This is a really simple example. It's probably not a test that you would ever write on this It was absolutely critical that this form had a required field So if I come in here, and I check this and then I run this again Sweet. Okay, so it's passed as you expect and so if we come into Co-exception here, that's right. I'll PHP storm. So we can go into The log folder and we can see a bunch of screenshots. That's pretty cool So if a test fails This is local stuff and it is of this information is also available on the build server But when it build or we're in a test fails, you can get a screenshot of why that failure would be So in this case it failed because it was expecting to see the message is required field and instead The form has been submitted successfully They're pretty much all like that I think But I can show you a better example of that if there's time Yeah, hopefully you guys can see how that's quite beneficial to be doing the automated testing and then also having the build Available to send off to the client or you know to your manager if they want to go and do some manual testing and stuff like that They don't really have to bother you even like my my bosses are you know quite They're not super technically savvy But they they know about this and they know how to go into Jenkins and they can find the latest build and they can Just go and check it themselves without even asking see We also have this little script to Basically read from the test folder a file and generate this output of all the tests. So there'll be an entry here for each test There's only a couple here that Pass so there's nothing and then if it does fail it has a read failure message and It pulls through the screenshot So yeah, that's um It's pretty cool, and I'll just show you actually I'll just get on with it So if it opens out anything so do it yourself these links are all on the Drupal south page for this talk so you can go on and get links to them Um I'll just explain them really quickly. I've sort of talked about that co-exceptions example directory So that's the slash tests directory that you'll put in your Drupal root And then So ansible local setup this This repo is A set the setup that we use every day all of the developers at the web scope use this setup So it's a Vagrant and ansible setup and it's going to provision a virtual machine on your computer and it's going to provision you know apache php Mysql and it's going to provision code section and You know a bunch of other stuff as well that that we use so you might want to take some stuff out But the key thing is it does have code section in there So you shouldn't really have to do much setup if you if you're using this virtual box Um, the build server so the build server that all these tests are run on We configure the whole thing through an ansible script You know, we don't go and log in and change things and change things everything that's changed on the bolt server has changed through ansible And then the ansible scripts are rerun to configure the bolt server again You know that way if we needed another bolt server, we just bring it up and we just run the ansible script and Then we have another bolt server. So if you want to do that, you just need to take that script I think we host on rack space for our bolt server Not that that really matters And then the site build Ansible script and then the whole setup really so this is a script that lives on the build server And is run locally on the server to create the new copies of the website So that's this that's the directory and the associated files that is triggered by Jenkins to do basically all of the magic Yeah, okay, so that's kind of the end of it and I'm A little bit early, but I'm sure that there's maybe a lot of questions and I've got a lot of other stuff I can keep showing you guys if you want. I mean ansible is really awesome. So Okay, I can talk about that all day um some of this just Yeah, so there's some resources at the end of this slide a little bit You know about alternatives to ansible puppet chef salt. Um ansible is a lot Simpler than these alternatives if you're just doing sort of day-to-day DevOps works work on like medium size large size sites. It's not really Sort of your enterprise level solution but it's so much easier to understand I Spent a lot of time trying to get to no puppet and I kind of got there But in the end I felt like it wasn't really worth it for my situation But ansible you can almost understand straight away. So I highly recommend using ansible for your configuration management and with cloudbees and Jenkins There are some other hosted services for that I think We use cloudbees There's like Jenkins hosting and there's bitnami and there's a bunch of other ci hosting things that are kind of actually moved to step on from this and they Sort of provide Jenkins integrated with the actual build server as well And a lot of people are doing that a lot of different ways And there's all these are all online services you might use instead of Jenkins and they maybe even better Maybe there's something that we'll look to move to in the future as well Um, and yeah, like I said, they incorporate everything and they can run Builds in parallel and run all your tests in parallel and things as well. So there's a lot of cool stuff happening in that Um ci space, right? So I might walk through This is the site build script that sets up a new website on the build server so there's a Bit of a read me there about how to set that up on the server Of course, if you if you have any trouble with that feel free to you know come into Issue queue post an issue if you're going to fix something make a pull request, please And so here's the site build script. I don't really talk about that very much because I've already seen it Pretty simple stuff This little thing down here this code section command that was commented out tapes the tests and puts them into an xml file And then that xml file Is used to generate this output that you see here So that's kind of cool. If you want if you want that function, I just comment that out To the guts of it and the playbooks folder In the build folder build directory folder This is the configuration for an individual site. So Whenever you start development on a new site, you need to Pull this repo you need to copy this example file change some parameters and then push it back up to the build server so as we saw With dinkins he only passes like a little bit of information through and one of those One of those things is the site name. So that's there's a lot of configuration already on the build server Which is going to be triggered by that particular parameter Okay, so This and this will this part will change a little bit for your setup. So we have a thing a uid here for our pantheon environment and You would have to change the script a little bit to work with whatever hosting environment You were working with to be able to get somehow get those database and files folders down but essentially we sort of Configure it put in we get her repository. We put in the uid Some parameters about where the site will be built. You shouldn't have to change any of those things The only things that you you really would have to modify is Just change the script to get those that database and those files And so you would modify those those settings. This is the settings file for the ansible playbooks that runs so playbooks the sort of the word term for an ansible script and We might as well start to go over that real quick. Um, well, there's one minute left. Is there any questions? I think Probably gone over most of it. Okay, so we Yeah, yeah, so we use um You're not going to be very satisfied with this answer but We use this guy here He goes in there and he does something to remove them. I think he I think there is a script to run I'm not sure how complete that that destroy script is But he knows how to go in and manually remove those builds There is a site destroy script in the root of this repo But like I said, I destroy all sites site destroy. I'm not sure if this is what he actually uses To destroy it. So use that at your own risk Um, no, no, we don't pantheon. Yeah, I mean Pantheon's on a rack space our boot servers on rack space They probably have like a gigabyte link or more so I it maybe takes, you know, a couple of minutes. It's never noticeable That's right. Um, pantheon has a drush Set of commands called terminus and they allow you to sort of log on and grab it in a in a friendly way But otherwise you could just use as is will be a perfect setup for that No matter where you are, you can just get it sql dump of the database and the files, you know It's totally usable. Yeah Ah, yeah, so time all right Okay, everyone needs to head over to the auditorium now for the closing ceremony There's no break between now and then so head over there