 Greetings, everyone. Are we ready to begin? Alright, so first question, show of hands, how many of you guys build websites for a living? Yes! Alright, quick show of hands, how many of you enjoy building websites for a living? Alright, quick show of hands, how many of you enjoy the beginning of the project where you get to do whatever you want more than the end of the project where you can't? Yes! That's what we're here to talk about, alright? So, I chose a cheeky title, Developer Swagger, because I feel like there's that feeling you get at the beginning of a project where you can sit down and in like two, three days, maybe a week, knock out 80% of what you kind of need and that feels very awesome, that like velocity is something that's pre-cognitively empowering. You just know that that's right and it's powerful and it's good and you're making a difference and then there's sort of like this, I don't know, depending on the project and so forth there's this sort of decay of speed that happens and more and more limitations and structures get imposed on you and part of that's a function of QA and part of that's a function of more stakeholders coming in and maybe there's a big team and yada, yada, yada, but the point is you have that beginning of every project and it usually just feels so good, especially if you're using Drupal and you know what you're doing and you're building stuff up and you're installing it and plugging it together and then you lose that at some point and I'm going to talk today about ways that we cannot lose that feeling things we can put in place that let us have that same confidence, that same velocity, that same speed, that same swagger all the way through our projects. I'm also, you know, the technical term for this is application life cycle management and I'll explain a little bit about what that means too. So, whom I, for those of you who I haven't met, hi my name is Josh, I'm Josh K, I'm Drupal.org I've been doing this for close to 10 years and I love it and I love this community and I'm really honored to be able to present. I'm so actually kind of terrified and nervous that so many of you came to see me. So, thanks for showing up. Professionally, this is my gig now. I do this thing called Pantheon. It's like a Drupal in the Cloud, all-in-one platform, build, launch, run, et cetera, et cetera, et cetera. If you want to get that pitch, go to the booth. I'm not going to talk about Pantheon except at one point where I'm using it to fake a demo that I couldn't set up last night and I'm going to talk about what the technologies are that we use to build this sort of thing and how you can use them yourself if you want to, how you can use the same open source tools and build your own application life cycle management system because I think it's very important knowledge for people to have. So, quick enterprise software, acronym academy, this whole notion is about, there are people out there that buy the technology from us usually. Like we're the developers and like even if we're working inside of an organization rather than at a consultancy, there's still someone else who's the ultimate owner like the site owner or the project manager or the project owner if you're into Scrum or the stakeholder, whatever you want to call it, right? And usually there's an administrative kind of capacity within the organization, whether it's your organization or the client organization, and they're going to have to kind of live with this thing for as long as it's around. And sometimes a website is like a two, three, four, five, maybe even more year commitment. And so they need to know that they have the stuff in place to be able to keep it online and keep it running and make the updates when you need to make the updates. And this is no joke, right? Like I used to do a lot of Drupal consulting with chapter three. And when I first started, we just really like didn't want to have anything to do with this. It was very much like, we'll build you the website, we'll train you to use Drupal and then go for it, right? And that was good for us because, you know, we were able to build our business and we were able to work on a lot of industry projects. And we helped a lot of people and thankfully, you know, a lot of the stuff isn't that complicated or, you know, people can, you can get away with kind of fudging it a little bit here and there. But more and more as the world begins to adopt Drupal and we get more serious about best practices, this is less and less something that you can kind of hand wave away. Also, if you happen to run a consultancy or work for a consultancy, being able to deliver on this kind of stuff is like really good business because it keeps your customers around for the long haul, which is really important if you're trying to grow this industry. We need to build long term relationships. So these people are looking at two to five year timelines. They're also thinking about Drupal isn't the only thing they do. Like they can't be Drupal experts because they have to own seven, eight, 20 different pieces of technology and, you know, even if people try to standardize more on the web tier, they're also like dealing with like whatever their CRM databases and blah, blah, blah. They got a lot of stuff on their plate and it's hard. You kind of have to appreciate the fact that a bunch of these people are overworked, underpaid, stressed out and under a lot of pressure and we should be nice to them. I think it's important that this is not just for big corporations and big organizations, this stuff is for everyone. This helps all of us build better sites faster and get them, keep them developing and keeping on going. The thing that I dislike the most is when you have a really cool site build process and you get this really great site out the door and then it never evolves after that because it's too hard to do the deployment stuff and keep it all in sync and like you have a couple bad experiences where you break the build or whatever and then all of a sudden everybody goes into lockdown mode and you're not able to innovate anymore. And that, that just kills me right here in my heart. So this is for everyone. So in the broadest spectrum, ALM is like all this soup to nuts. It's like, you know, the guy who's going to do the giant Microsoft project, a Gantt chart or whatever, and they're going to go from requirements gathering all the way through design, development, project benefit, etc, etc. I'm not going to talk about all that. I'm really just going to talk about development, deployment, maintenance, updates and upgrades and what are some best practices you can use for these that will help you in doing your job and what are some tools you can use. So developers want to move fast. As I was saying, it's very gratifying for us to be able to do things quickly. And I think there's, you know, there's, there's no coincidence that Facebook chose as their engineering model. We like to move fast because that's very appealing. It's gets to that like powerful early experience. And there's this great old proverb of like, if you want to go fast, go alone, but if you want to go far, go together. And I think that often we are sort of faced with that type of choice and it's a false choice. I think we can go fast and go together. And in fact, if we really go together as a community, we can go even faster than any of us could alone. You know, we're kind of like this. We're like, we're going to hack it up. We're going to, you know, we've got this glowing thing and a happy mug and we're in the matrix and so on and so forth. And the, the, the people sort of who are in charge of that chart or maybe signing the checks or whatever, they're probably a little more risk a, because you have to appreciate that. They don't really understand very often what we do. Like the whole Arthur C. Clark sufficiently advanced technologies indistinguishable from magic. Like, have you ever tried to sit down with someone who's like in your family, a normal person and just explain the internet to them? Like there, it's, it's as crazy to them like they don't just don't think about it at this point. It's just assumed, oh yeah, now get online and the website is there and they don't really, there's no reason for them to try to comprehend all the little things that have to happen in order to just load a web page on your browser. They just assume that it works and then it's kind of magic. And so when you're in charge of managing a process and you're effectively think you're working with a bunch of magicians who may dress unconventionally and, you know, go to these cool conferences and you're not quite sure what they're doing. It can make you a little bit uptight, right? So you have people who are afraid of downtime because downtime is money. That's huge for most sites, even small sites. They can't be offline. They can't be down. They can't be broken. Even if like the site is up, but the CSS is broken. That's still broken, right? If the user at the end of the day isn't able to load the site in the browser, it might as well, the server might as well be on fire for all their concerns. Like as a developer, I distinguish between these things, but as a site owner, most people don't, and nor should they because they're right. And so you get this kind of thing. It's like, yeah, if you could just go ahead and test everything before you deploy it, that'd be great. And I think, you know, I chose the Bill Lumberg meme for this because sometimes when you get this kind of ask, you sort of feel like you are in that office-based movie and this guy is kind of a douche. And you're like, man, why? But he's right. You should test everything before you deploy it because what you should deploy should be rock solid. And the point is what that process of testing before you deploy should be easy. It should be simple. It should be like powerful. And it should be like all set up for you. That's the right way to do it. So do you have to take risks if you want to move fast? I mean, one way to do it is you can, you know, you can get on a motorcycle, you can leave your helmet behind, you can crank it up and you can just head off down the road or you could like get in a sports car with a strap on harness and like have all the equipment you need and, you know, drive a hundred miles an hour and be relatively safe on a closed course, on a closed course. So no, you don't have to take risks. Not if you do it right. And that's what we're going to hear you talk about. It's the success of doing it right. So swagger. What are the things that cause you to lose your swagger as a developer? I'm going to run through my favorites and then we can talk about more at the end. There's a wonderful poem, Two Roads Diverged in a Yellow Wood. And I, I took the one less traveled by and that has made all the difference. And that's kind of a nice inspirational poem about being yourself. But in a project, if the two roads diverged, you are so screwed, right? Because this is the first thing that steals your swagger is like if you are not in sync with the rest of the project, especially after you go live, right, you go live. And unless you're in one of these like edgy use cases where there's like no nothing actually happening on the live site and everything is just pushed out from there. There's a few cases like that, but they're very rare with Drupal because why do people want to use Drupal because it's a content management system and you can have people log in and add content and leave comments and fill out forms and so on and so forth. That's the real work of the website and it's happening in live. And if you are not able to stay real close to that and in sync with it while you're developing, you're going to slowly drift apart and then eventually you'll have something like a bug you can't figure out and then I've actually done this, right? Working on a new site, spent two hours, two hours, two precious hours of my time that I was charging a lot of money for. Figuring out that it was just that my database was so out of date that there were no nodes that had been published in the last week and that's why all the views on the front page were broken, right? And those are the sorts of things that happen and like they're unexplained and it takes a while to figure out and divergence, divergence in content, divergence in code gets you into tricky situations where you think you've got something solved and then all of a sudden it breaks or it doesn't work or it doesn't behave as expected. And so really one of the main core goals of the whole continuous integration movement is to minimize divergence. You want to diverge to do your work and you want to merge back in and you want to stay close and you want to stay tight. If you've got, if you're doing like feature branchy based development and stuff like that, that's really awesome. But if your feature branch is sitting out there for more than a couple days and you haven't, at least you don't have to push everything back in. But if you haven't pulled from the master branch or however you have that set up in a few days, you're doing it wrong. You should be pulling like every hour because why wait until the end to deal with the conflicts? You should deal with things immediately and stay closely in sync. Divergence leads to fear, leads to nervousness and then nervousness leads to like all sorts of things that people think are going to prevent them. Like what happens typically in my experience is there's a bad experience somewhere, something breaks or it doesn't work as expected and then there's a meeting about it and there's like people are kind of tense because it's like you feel like you're on the spot and maybe you didn't do your job right and you know there's pressure and then some remediation gets made and very often the action that is taken out of a kind of a nervous tense sometimes and the worst case scenario finger pointy kind of meeting, the cures that come from those types of beatings are frequently worse than the diseases themselves, right? Because people are not really thinking about things rationally, they're no longer considering like what's the best practice here, they're just trying to have an answer to the problem so that they can say that they did something and that you can just start to see projects get more and more and more off track and out of scope as these types of decisions are made. I have a friend who is a wilderness survival expert and so he's done things like you know rescue people who are drowning in lakes and things like that and when you do your wilderness survival training they teach you that disasters are very frequently like one thing that happened, right? It's the disastrous events where people end up getting hurt or dying aren't usually like oh a rock just fell out of the sky and crushed someone. Usually it's like a series of small mistakes that compound into a bigger mistake and when people are feeling stressed out and under pressure they're more likely to make these rushed decisions and small mistakes that add up to becoming something that's really bad and then like you have another bigger meeting that's hopefully a little bit more like nice and everyone decides to get on the same page. So this all adds up to you not being able to hack which sucks like that's when you know you've lost your swagger because you're no longer able to hack. I think hack is a good word I like I'm like I like to try to reclaim these words like hacking and cowboy and stuff like that because I think it's important to have your swagger you just got to do it safely right. So and and fear right fear becomes the mind killer and fear is poisonous. Fear is poisonous inside an organization it's in poisonous inside a software project. It's poisonous inside your personal life and being able to reduce eliminate mitigate and clear your mind of fear as a developer is really truly the key to being able to continue to to move quickly and at a high velocity throughout the life cycle of a project. I think cowboys are cool. Look at Clint Eastwood. I think you deny that but they are especially cool when they use version control and continuous integration. So one last inspirational quote learn how to see realize that everything connected everything else see the big picture think about that and then act with wisdom right. So I'm going to talk a little about how to use get in a way that allows you to perform automated actions after you do things. Who here is familiar with GitHub show of hands. OK so basically everybody because they're totally awesome and they I'm not going to show you GitHub because you can kind of figure that on your own they got documentation but all the stuff that GitHub does you can do on your own. I think it's important to know that. And it works on a hook system which is a lot like Drupal's hook system. There are there are actions that happen in the process of a git transaction that then allow you to do other things. So you can pull from a remote really easily get as this beautifully distributed version control system that allows you to seamlessly pull from multiple different upstream locations and merge things together. That's like been a game changer with the past three or four years in terms of my work and I really recommend anybody who's not using get to sort of get with it. But pushing is a little bit harder. Like if you want to have this workflow that everybody is into now for good reason like where you get push and then you are deploying. You can't just push to the remote repo if it's a working copy because get will reject that I'll show you it rejecting in a second. What you need to do is use what's called a bear repo right and a bear repository is just a different style of checkout and get that's meant essentially to do this type of coordination work between other repositories. So it actually is not a working tree in and of itself. It's just a pure metadata repository that you can push to and pull from and then very easily trigger actions afterwards. So demo of that real quick. Can you guys is that visible. What if I. What if I do something like. OK. Hello internet. All right. So what I have here is just a server that I set up. It's a normal virtual machine does anything special fancy on it. I just installed get and like a couple other very very basic tools. And so where I am in this is in the var get repository. That's why I set up as just a very simple repository. It's got one file in it. That file is available on the internet right here. And it's just a simple index that HTML file for for your demonstration purposes. That file actually lives in. Var dub dub dub code. I believe that's where I put it right. So there's index HTML and. Here. I'm in on my I'm on my my laptop here. Let me actually just move this up so you guys can see it better. So I'm here I'm on on my local and I'm just going to show you the not working version where I've checked out a copy of the working repository because you can you can pull from anywhere you can basically clone from anywhere that you have SSH access to you can clone from get and that's that's a really nice capability because it makes it very easy to share code with other people. But if I want to make some changes here like if I were to say edit the index HTML file with an edit commit that and if I try to push it right like you would with get gets going to think about it right and it's going to say no dice because the way that keeps track of changes if you actually try to push into a working repository it's going to mess with the hashes and it's telling you that this is unsafe you can force it to do that if there's ever a reason where you actually absolutely must do this but it's not recommended and I like that get is pretty good about telling you you know there's always a force option but you know you know you shouldn't usually force it and that's pretty good. So the trick is you use the bear repository and that's what I set up in that var get area and if I go here and I can make an edit right and that's going to go and push through. Okay right and and you're going to see some output here and it says you know code deployed sir and and if we reload we're going to see I've added my change that's been deployed in that working directory and it's now on the internet. So how did I do that? It's actually quite simple. There is a hook file called post receive that you can use for this. You can also use it to do email updates and all sorts of other things. I'm just showing you how you can use to deploy code. You can tap into this for all sorts of purposes and there's great documentation in the get project on this and because we're all Drupal developers I went ahead and used PHP as my scripting mechanism but you can use bash, you can use Python, you can use Ruby, you can use whatever you like here, anything that you can invoke from a shell. And what this is doing is I have a this is this comes in later. I have a little function to help read like the arguments that are being passed to get and I'm basically saying you know read the arguments that are passed in and if I'm pushing to master right set an environment variable that I need change the directory and then I'm having it echo the current working path and who am I to be able to this is while I was trying to debug it last night. And it just does like a little reset hard in case someone in case somebody ever came in and like edited directly on the the environment that I'm trying to push to get this will squash whatever those changes are because I don't want people to do that and it's going to do a checkout of master to make sure that it's on the right branch and then it's going to pull from master and then it'll say code deployed, sir. And this basically gives you the ability to have this is the you know one of the cornerstones of having a development workflow that allows you to integrate, get very easily with a mechanism that deploys code automatically when things are pushed to master and that's such a time saver to coordinate a development team. You can to be honest like if you're going to do this in production you can get way way way more sophisticated with this. I mean you can be doing things to check the syntax you can be doing things to notify people you can be coordinating other project resources if you want to but it's all just like a shell script at that point and you can write that shell script in PHP if you want to there's nothing wrong with doing that. You could be invoking and drushing here other things. So that's the wrong presentation. So and get can be used in a lot of other ways. I can't stress enough how wonderful it is when you base your workflow mostly on this technology because it opens up a whole world of possibilities and it can save your butt in so many different ways. Like as a recommendation there's a great demo that I saw once and I challenge everybody to try this exercise sometimes if you work on a development team because it's actually kind of a fun game. Get an egg timer and set it for like 15 minutes and start writing some code and try to make it so you can make a commit every 15 minutes because the truth is if you're working along a path unless you're like going down some kind of rabbit hole you can like sit down plan out what you're going to do and be like OK, step one first 10 minutes commit OK, reset the egg timer second 10 minutes second 12 minutes second five minutes commit and like this is a really cool exercise and it gets you into this habit of notion of saying OK, I got something it's good I want that in there and then when you've got something that's holistically working you push it out and then it gets deployed or you push it out and your colleagues merge and they check it out and integrate with their work that type of like frequent commits allow you to easily step back in time and it also kind of enforces a nice discipline as a developer in terms of building in solid steps that you can think about and move forward with. The other thing that's great and I really like to do is to manage my Drupal project and my core updates with Git as well and so what we do here is in that local working copy you start by cloning Drupal and so you get all the project history which is actually I've actually been trying to play around with ways of truncating this because I don't really don't need the project history going back to Drupal like four but it's all in there for posterity but you get the whole project history and then you make your modifications you add your modules you can add a patch to core if you want and do whatever you need to do and then you push it out to your remote bear repository and that deploys it and then when a Drupal core update comes your update mechanism is Git pull Drupal core Git URL tag of the release and unless you've literally like changed the same line that webchick wants to change when we're fixing a bug it'll just merge in seamlessly and you can push it out and that allows you to not only have a pretty easy and simple update workflow it allows you to patch core where you need to if you want to get ahead of the project and so on and so forth so it's a great technique for managing your Drupal core updates so now I want to get in a little bit into this notion of continuous integration right and this is the idea of what I talked about right there was kind of like how you can push out to a development environment and have a bunch of developers work together on that continuous integration is how you deal with that when there's also a production environment and the secret is that you add a third one in the middle called like staging or testing and the proper workflow that works every time and I encourage everyone to just accept even though it's not the sexiest thing in the world is you push your code up from dev to test to live and you pull your database and your content files the opposite direction when everybody first starts working with Drupal they are always like oh but I could write a script that would just push the right tables in my SQL or I could check the database in and like Diffit or something and it's just not a good idea it's you're gonna spend a lot of time working on that and it's gonna be like this brittle duct taped Rube Goldberg Cluj machine and eventually it's gonna totally screw you and so if you just build your workflow around this which is dependable, solid and reliable it'll work great and this is really cool for doing all the more advanced configuration management stuff that's available now and it's coming in the future because what you're doing when you're using this workflow is you're saying okay I'm over there in dev and like you know ideally you're also there should be like a third line where you're like you sync the live data back kind of frequently just so that you're not getting again you're not diverging too much you don't go off into the yellow wood but you're working there in dev and everything is working good and then when you when you do this action of getting ready to deploy your continuous integration action and that quality assurance space is to bring the data back and push the code up and what that does is it lets you say what would happen if I deployed right now and that can be as simple as does it work that could also be if I run update.php or features up or you know do my custom script or click the two buttons I think I need to click does my deploy actually do what I think it's going to do and if the answer is no then you just go back into dev and you do some more commits and make it work and then you re-sync again and because that live database is going to come back in and wipe out whatever update.php did you just get to run that process over again and you can do that as many times as you need to until it's bulletproof and then you can deploy like I have the Clint Eastwood picture up before like how many of you guys have seen the good, the bad and the ugly show of hands so it's a little older movie it's pretty popular so the sort of one of the crucial scenes that it is like Clint Eastwood comes out and like they shoot him up but it turns out he's had like an iron stove plate under his parka, parka the whole time and then he wins and this is kind of like that moment where you're like I'm a cowboy and I'm going to play it fast and loose except I'm totally bulletproof and nothing can kill me and that's the feeling you get from this which is a really good feeling and I encourage you all to experience it the tool that I like to use for this is Jenkins how many of you guys have used Jenkins? Okay so many of you but not all of you I'll just show real quick Jenkins is essentially a job running and management system that's designed for continuous integration you can use it for a lot of other fun things too I like using it for all sorts of cool stuff it's a Java project so it's not like Drupal but it's not that hard to get running and it's really well built like as Java projects go Jenkins is kind of like it's in the 99th percentile of quality in my opinion it's a great piece of software it's got a solid community about it they told Oracle to go suck it and did their own thing and it was cool so let's not get there yet so brief demo so basically Jenkins allows you to define jobs and then lets you run them and so like you can have a job called sync database and that job can run the MySQL commands to sync the database between the environments you can have a job called run unit tests well I'll talk about that a little bit later but if you wanted to run if you were doing Drupal core development you wanted to run unit tests you could have a job in here that does that and what it does is it keeps track of every time something was run whether it succeeded or failed and it gives you a log of everything that happened while it was doing it which is great the other thing about it is that it has a built-in REST API so it's very easy to integrate this with your other scripted tools and you know you have to do a little bit of work to figure out exactly how you want to do that but you're not like oh I got to invent something it's like here's some software you just drop right in there and it can do it and this is a really really powerful tool that doesn't take much expertise to set up and it gives you an enormous amount of flexibility and I recommend everybody who's interested in this type of workflow just check this stuff out because it's very very good there's also services you can do there's like a Jenkins service there's other CI services that are coming out because more and more people are getting on board with this stuff but if you want to roll your own this is the best rolling paper I can imagine so what about Drupal 8, right Drupal 8 has some new stuff in it Drupal 8 is going to have this configuration management initiative Drupal 8 is going to export your configuration to code Drupal 8 is Shangri-La and this man has fixed everything for us how many of you guys know Greg? you should, he's a really great guy but if you know anything about him you know I'm kind of like playing against his personality type because the answer is nope this is much more his vibe sometimes you know Greg's a really great guy he's a friend and he's a wonderful person and if you see this man at the conference you should thank him for all the work that he's done because CMI is a major major major win for Drupal like right now Drupal is using a configuration idiom that was that dates back to Drupal version one I think it's basically at the time it was revolutionary that you could even put configuration in the database and edit it through the web UI that was like 10 years ago and it was like holy wow that's really useful that's amazing and then 10 years later we've discovered there are a lot of drawbacks to that too and we're sort of catching up with the rest of the web in terms of using standard configuration file formats and writing this stuff out to disk so that we can version control it and deploy it rather than having it in the same database as our content and having the two be muddled together so it's a major major major win I can't stress how important this is and it's one of the best initiatives in Drupal 8 because it got in pretty early and all the other initiatives are built on it so there's no way this isn't happening which is great and use this yaml if you guys haven't seen this I couldn't actually come up with a screenshot to show you but you're gonna like it because if you like version control and you like looking at diffs to see what's changed the way that this is written how many of you guys have used features? Yeah, so how useful is it to look at a diff of one version of a feature module and another? Like on a scale of one to 10, two? Sometimes it helps but sometimes it doesn't because these features are mostly like I mean God bless Earl for doing that like C tools, export stuff because nobody else did and fucking hey but exporting these giant PHP objects like when you try to compare the two of them very often it's just like a mess well in terms of what the diff looks like it doesn't really, it's hard to look at a diff and actually see what's going on the CMI initiative exports to yaml and it does so in a really economical way that keeps it organized so like when you actually look at a diff unless there's like a huge delta of change and that's a problem anyway because you went too far into the yellow wood in the first place if you look at a diff and the delta isn't too huge it's actually really easy to say okay this changed to that this got added there and this name changed to that and you're like oh I can look at a diff and understand what the config changes are even if I didn't make them and that's really really really powerful but you still need a solid workflow because it's gonna still be the case that you have to like get this stuff developed you have to check it into version control you have to deploy it and you have to make sure of that before you deploy it you test it so the CMI initiative is basically gonna make this continuous integration process much much more effective and much less painful for people but it doesn't mean that you don't have to do it right it just means that it'll be cooler and better and allow you to build sites faster a word about automated testing I've been a part of a like some pretty big Drupal builds in my consulting days and I've seen organizations spend six figures writing simple tests that never found anything and it's because the core simple test unit testing framework is really meant for core development and that's where it really provides an enormous amount of value and Drupal 8 wouldn't be possible without it and it's totally good but when you're building a custom bespoke website for a client the unit testing it's you're sort of coming at it from the wrong angle right what you need is much more of a kind of a functional test and the good news is that better testing for site builders is coming right we're sort of in this middle ground now between peer tester in development or unit tester in development and we're moving towards behavior driven development behavior driven development is a sort of a new set of idioms and tools that are designed around expressing like here's what should happen when this happens in a kind of a high level way not when I load a node it has this variable because that very rarely breaks when you're just building a site and you're trying to do a custom menu callback but behavior driven development is a much better idiom for testing the functionality of a website and eventually we'll get into accepted tester in development and when that happens we'll reach Shangri-La maybe and the tool that is kind of becoming like the PHP tool that's becoming the leader for this is called Behat and there's been some work done already to integrate Drupal with Behat I recommend that everybody's sort of trying to get hip to this because it's not like was the stuff I showed you before like a get deploy hook or Jenkins those are like settled questions right in my opinion you should use Jenkins it's not really like don't spend a lot of time evaluating different systems just use Jenkins and it'll work great and you'll be set use git, it'll work great you'll be set Behat is looking like the winner in this space but the right way to use it with Drupal and the proper integration paths and how best to use it as a site builder are still unsettled questions that we need everybody to kind of think about and experiment with and help the community work together on discovering the best practices for and so if you're into this kind of stuff get hip to Behat because it's going to be a big deal I think last little points here on the yellow wood keep your development environment fresh I mentioned this before in order to make this really work well you should just have scripts for this like you use git for everything and you script everything make it automated make it testable make it like just a brain dead science where you don't have to think about where things are just run a script fresh in your dev environment and if you can save 25 minutes a day by scripting something that's a person day a month and if you have a team of six or eight people then you're saving a person week a month so it's really really worth investing in some of these automation systems because they reduce error and they essentially and they improve your time they get people out of doing robotic automated things that frankly people are not good at because we're creative thinkers and we like to analyze patterns and solve problems but computers they rule it like doing the same thing over and over again and we should use them for that I want to sorry the two pieces in here tricks data has mass so if you have a lot of content in your site this can be a challenge and you should kind of think creatively about how to approach the challenge one simple trick that I recommend everybody think about if you're writing scripts for doing your data synchronization is break up your MySQL sync into two steps one that dumps the schema of the whole database and then one that dumps the tables but skips the ones you really don't need to sync like the watchdog the access log any cash tables other stuff like that that can actually cut down the time it takes to sync a big database by five to ten minutes and again you say five minutes here you say ten minutes there suddenly you've got another person week at the end of the month and your team can do more awesome things Drush aliases this is another thing when you're like working in a production environment or a dev environment very often like at some point you won't have shell access or you won't be able to get shell access but you should still be able to get Drush access if you set things up correctly and how many of you have used Drush aliases okay so basically I don't need to tell you guys how this works I'm not gonna, I'm gonna skip that because I think I'm running a little long here but this is super important and it's part of keeping your swagger it's part of staying on, you know, on point and there's no reason not to do it if you wanna figure out how to do this come talk to me afterwards all right deployment right this is just a simple few notes about deploying when you deploy to production there are people who have strong opinions about whether you should be pushing things out with R-Sync or triggering jobs to pull data from another chronicle source and, you know, there's kinda like some religious discussions about what the right tool is this should you use Capistrano, can you use Jenkins, should you roll your own scripts, et cetera, et cetera push, pull script method A, Python, Ruby, whatever it is as long as it's automated and as long as it works the same way every time and as long as it gets all your code out to wherever it needs to be like if you have multiple production environments you gotta make sure that the code arrives within 30 seconds or so you're doing okay and you'll probably be all right and the thing is not to get hung up on like a million little details the thing is to make sure you hit this minimum bar for deployment because if you're ever if you're still doing deployment by hand that's the bigger problem because eventually by hand is gonna fail and then you're back in like the fear zone and everything falls apart ideally you integrate this with version control I'll show you a little quick example and then you script, test and automate so if I were gonna integrate something with version control I might take this and I might say get tag this is the commit that I just made deploy 99 get push origin tags so this is gonna go ahead and push out to my production environment and it's gonna do it live for us and what I have it here is just this would be the API call that I would have made and it would have gone something like this deploy 99 and watch it happen it's already done it checked it out this is like my live environment and here we see it's the same thing that I deployed before and again all I'm doing with this is still using I'm still using the post receive hook for this I just scrolled down here to hide it from before and I'm just looking for the keyword deploy and the tag again you can get much more sophisticated and broke with this if you wanna use a different mechanism for doing deployments I don't like tagging for deployment personally cause tags are like individual atomic units I don't like doing a branch for deployment because sometimes the branch gets an update and if for some reason it doesn't deploy for some reason it can become tricky to know what got deployed and what didn't whereas tags it's always abundantly clear what the latest deploy tag was and what's in that and if you need to go back to another tag it's pretty easy to figure out which is which and so this is just saying okay look for the deploy tag and if so run our do it live script and in this case I sort of give an example of how you might rig that through Jenkins if I'd had another hour last night I could have made that curl do that for me rather than having me copy and paste it for instance so investing in automation is essential this is sort of the mantra of this whole thing like if you're doing these production environments the configuration of the production environments should be automated there are a lot of hard things about running big production environments that I don't wanna get into too much here cause that's not the substance of this talk but like how do you make sure that everybody's got the same MySQL configuration settings how do you make sure your network file system is mounted correctly how do you make sure that you gotta automate all of that because if you're doing it by hand like that's human failure happens way too often and it's nobody's fault it's just what people are that we're not good at doing the same thing over and over and over again and never screwing up that's just not how we work so investing in automation is essential you need to build the board yourself right you should strive to have this level of unstoppable galaxy conquering automation in your infrastructure and your workflows and the end point of this is that sites that are backed by automated systems that give you the ability to do all this stuff without having to do a bunch of manual work or remember things are gonna be better they're gonna be better websites because they're gonna be able to continue to evolve after they're launched they're gonna be able to respond to what users demand and they're just gonna kind of lead the pack they're gonna win right if two sites get launched around the same time and one of them launches and stays the same for two years and the other one launches and continues to iterate and evolve and respond and improve this second site is gonna be the better website at the end of the day and we all wanna build the best website we can we all wanna help our customers we all wanna help our organizations we all wanna be proud of our work and having these tools in place lets us keep our developers swagger and continue to do that and you'll have this breakaway effect where some people are getting up at the front of the pack and they're out and they're leading and if you've ever watched cycling races it usually happens and there's this huge separation that occurs and the good news is that you don't have to do this all on your own there's a huge amount of open source development work in this space I've showed you a few tools there are many more there are whole conferences devoted to this discipline that are full of interesting exciting people there are also services out there that can help you do this there's services for CI there's services for like Drupal specific hosting that does this workflow for you there are services that help you just run Jenkins there is GitHub which can help you get started with Git and give you the tools to do a lot of this stuff having to write so many shell scripts and you don't have to do it all on your own you don't have to like own everything yourself but you should really be thinking about how you're going to embrace this new paradigm of building KX websites and keeping it rocking even after the launch goes out and that is the end of my talk and I'm happy to take your questions there's a microphone back there so if you guys do have questions go ahead and line up you can ask me anything ask me what my favorite module is ask me like how late I set up last night whatever you want to do I have a question for you sure obviously designers and coders and project managers and everything have different skill sets yeah often I've struggled to identify ways to get some consistency around designers using Git or Jenkins thank you do you have any recommendations for how to to standardize on that and how to get people up to speed and do with diverse skill sets that's a really good question and the thing is that again because this is an emerging discipline you know a lot of this is still not super easy and some of it you know requires skills that are outside maybe what someone's wheelhouse is I think that there are better and better desktop tools for using Git there are the open source ones really aren't as good as the ones that cost 40 or 50 dollars a pop but they're potentially worth it and most of them have demos and trials so I'd like if you're a Mac user I would look at Git Tower is a pretty good one there if you want to use my service I've got a way for you to like use FTP and still use Git at the same time and they'll demo that for you in the trade floor but basically there are you know you can you can find ways to integrate these things that let people still use a lot of the tools that they're familiar with for designers let them use some one of their IDEs like Dreamweaver or whatever that's based on an FTP protocol type workflow or at least give them a Git GUI so that when they're working in their local development environment they can easily see what's changed commit it and push it and then it's just a matter beyond that point of having having the steps down and being very clear and automation will help you do this because when you've automated you're doing it the same way every time and hopefully if you are mindful of the developer experience while you're automating you can get things to be as straightforward as possible so that like if it's if it's the same three steps each time and you can like write it on a laminated index card and put it on someone's desk then that's really good so I think you know those are general answers unfortunately there aren't like there aren't that's not a settled question because this is an evolving space but basically what you want to do is look at try to try to find ways to let people use the tools they already know and love and integrate with this stuff for instance also GitHub lets you I don't know if you guys have if you've seen this on GitHub you can go in and actually use their web interface to edit a file and turn that into a commit if you want that's kind of cool and there's more stuff that's going to come out like that that will integrate better with these tools and so I kind of keep up with that and and you know see what see what you can see yes hi Josh hey Bevan are you just going to be available or not yes I will post them right after this cool what do you think of using Drushmake to get an update Drupal Core and Contra modules as opposed to chicken them in so I am really interested in how we can better integrate Drushmake with a Git centric workflow because I think that you know there this is this is another place where people have like interesting debates right there there are a lot of services now that really are based on kind of building tar balls to deploy or other things like that it's and it's out of like a it's a more of a java ish deployment mechanism where you're you know you're throwing out this this this zipped archive and thrown on the web and Drushmake kind of by default wants to do that there are ways to make Drushmake pull the core from a Git upstream and there are probably ways to integrate that I've been kind of experimenting with ways to make it so that you can do you know start with a Drushmake file and then you know upload a new Drushmake file and then see the diff in Git of what was actually changed so you can approve that turn that into a commit because the thing that's critical is that each step along the way as you are developing is versioned and while you can version the Drushmake file unless you're a very very specific and particular Drushmake developer and you specify the exact version of every module you want to use it's very easy to end up with a Drushmake file that just referenced like views and then you know you you build that one month and then you deploy it again three months later you got a different version of views and it breaks so I'm kind of interested in figuring out how to like implement Drushmake which is very good for Drupal distribution development and product development without kind of letting it without allowing to think about everything and now I've got a broken build kind of process. Cool. Yeah. Do you think having a a Git hook implementation on sandboxes that runs Drushmake every time you pull is a useful step to help facilitate that? Yeah, that could totally work like what you what you really want is like you're you're pushing up a Drushmake file it's doing the Drushmake and then you're able to kind of examine the diff between them and if you like the looks of the diff and the site works as expected you could turn that into a commit and then if you need to deploy that out because like literally you could run into a situation where in your development environment it looks good but if it's just running Drushmake everywhere like the next hour when you deployed it to prod one of the versions of the modules could have changed in a way that breaks the site that's unlikely but it's actually possible so what I'd like to be able to do is have Drushmake be integrated with Git as a development process but still use version control and tagging as a mechanism for doing testing and deployment because that way you know that it's never going to change yeah yeah finally I use Pantheon I think it's fantastic thank you for being a part of making it oh thank you very much and for the people here that don't use it or not familiar that I think would be really useful if you did plug it a little bit and just explain which part of this whole process that fits into and which parts it offers and doesn't offer well if you want to stick around after the questions I'll do a short, short demo but I'm not here to I'm here to talk about this stuff not just to promote Pantheon yes yeah I'm Mike and thanks for your talk it was really affirming of some of the things that we have as part of our development group in the processes that we have one thing that we do is with GitHub or specifically in our case Bitbucket sure that's another great service I should have mentioned them before we have post commit hooks which are very similar sort of to the hooks that you put in with the project that you did an example of and I was wondering if there were differences because I because I use these post hooks that are part of Bitbucket I didn't know if there were differences with putting the file within the project like you had and doing it that way versus the other way so the way that this works and I'm not as familiar with Bitbucket as I am with GitHub so feel free to correct me if I'm wrong but the way that the when you have a hosted Git service typically they're not let they don't want they don't want you to check in a post commit hook because that could run whatever arbitrary shell stuff on their service and from a security standpoint they're not interested in dealing with that but what they will allow you to do is say I've got something that's listening for a rest call usually it's most people are doing this with rest these days and after I push to Bitbucket or to GitHub you will ping out to whatever I tell you to with the metadata and you can actually set Jenkins up to listen for those sorts of things if you want to run your own steps after that and that's how all the services that are out there like CircleCI or Worker or these other ones that are kind of trying to build CI as a cloud service to integrate with those things that's how they all work they're like copy and paste this URL into your project and what's happening is you're pushing to Bitbucket Bitbucket's like okay I got your code I'm going to ping out to your service and then that service is or your Jenkins instance that service could be a service that you bought or it could be something that you built it's basically taking that and saying okay let me pull from the Bitbucket now so I have the code and then potentially do other things if necessary and it really does get us into this place of where we're kind of building network distributed systems which is fun and exciting to me I don't know it's complicated but I like it so yeah and it sounds like that's the way we're kind of handling things I just wanted to make sure I wasn't missing some sort of advantage to checking in the post commit like you are having that as part of your project yeah no what I was demonstrating was just if you want to roll your own get server that's how you might do it because you don't have to worry about the security of your own scripts you're writing it's actually more work to like build your own thing that's calling out to rest okay thank you sure yes I don't know if this is too specific of a question but how does the how does committing to the get bear repo workflow differ from like rebasing to just like a test site like so this is a good question so they're not necessarily the sort of orthogonal like the bear repository is something again if you don't want to use bit bucket or github or another service and you want to run your own get server and you want to be able to push code to that server and then if you want basically want to be able to push to your own server you need to run it as a bear repo and that's just a coordination point like I'll show you real quick in the bear repo which is oops turn off caps lock which is where I am right now it's not like you don't see the the checkout or anything else it's like the inside of the got dot get meditated directory the bear repo is not something you could point a web browser at or run code out of it's really just something that's able to receive incoming packs from get perform action and then perform actions and then and then you can pull from it later so in the test instance like friend if I if I had set up a testing example where you know you create a test dash something tag right then the bear repo could say oh I detected a test tag let's go you know rebase or reset hard the test environment and then maybe kick something off that does automated testing or just send an email to the group saying go look at it right now or whatever but that's just the bear repo the way to think of the bear repo is that it's a coordinating mechanism it's and it's and get distinguishes between this is there's bear repose and working repose working repose actually have all the files in the code in them bear repose are just pure metadata for coordination so essentially like if you have get hub or bit bucket it would replace the bear repo in the workflow exactly thank you sure I was just wondering if you ever tried thing along with Jenkins say what what is it thing think thing yeah it's pretty much and for PHP I know I haven't I've tried it with Java and I felt like it was like was not the best experience for me just because it's complicated and I felt like I was joining a fraternity or something but but now I mean there's Jenkins that I didn't mention before I didn't go too deep in Jenkins Jenkins is so it has a great plug in ecosystem to kind of like Drupal has modules Jenkins as plugins and so there's a thing is that yeah so this is like a probably a bigger build management system for PHP projects and if you're my guess is that in the future symphony thing maybe those things work well together but I don't have any experience that personally thank you sure two things are there any good documentation or tutorials on setting up Jenkins like locally to test with and then deploying maybe Jenkins to a server sure so setting it up locally you will need I would not try to do it unless you have a Linux box or a Linux virtual machine at least and then if you're doing that it shouldn't be really different than setting up on a server right there I think you probably can get it work together there might be a brew recipe for it but it's very much like a a Linux E project and I would not I would say you're better off just getting the right operating system to run it than trying to deal with the eccentricities of running under Mac OS or on Windows but there is really good documentation on the Jenkins dash ci.org website they have a wiki that has recipes for doing pretty much anything you would want to do to get it rolling including you know securing it for production use and other things like that they maintain packages for the for Ubuntu and Red Hat and everything else you basically just install Java install Jenkins you know open up the port that you want to work on and go at that point and then you know you you like with anything you get more and more and more sophisticated over time but the zero to Jenkins should take about ten to twenty minutes thanks sure and the second thing is for those of us who aren't familiar with Josh Haley says could you run through your fake demo real quick sure I will totally do that hi thanks a lot that was an awesome talk thank you I am I have to be ninety percent billable and our company doesn't have a tools budget right what metrics do I start tracking in my ten percent of the time to demonstrate empirically that this is something that must happen well no but they're they're they're not in terms of your time that's that that's the secret cost of open source is that you get older while you use it as I'm beginning to learn after that that joke killed so the things that I would track are quantitatively you're gonna need I'm not quite sure how sophisticated you are in tracking like developer productivity in general but quantitatively you're gonna want to like get a handle on start to if you if you if you if you're ten percent time includes some like management of a team is that correct or uh no it's that's for like answering emails oh okay yeah so I would try to find one percent of your time to just start serving yourself and your colleagues on a weekly basis about like how many hours did you spend because you got hung up somewhere right and that should allow you to demonstrate to your management at some point that you know we're spinning basically the whole the whole the the argument for management is anytime that you spent what did you do this week that wasn't like really working on the website like did you have to like try to on on mess up my sequel did you have to like spend an hour getting a fresh deep database done did you have to like you know waste a whole day because you had to re set up the project or so forth and just start those things don't necessarily happen every day but stuck start keeping track of them and just like get on on like a note pad how many hours it was and my guess is that over the course of a month you can then go to your boss and say look and if you're you work for a professional services consultancy right so yeah I used to run chapter three and we would account for this and it's like it's the time where you know everybody wants their workers to be ninety percent available that's really hard to hold up to right and you always end up discounting some hours because you're like well yeah we were working on your site we weren't really working on your site if you know what I mean and if you just start to add up those hours on your end show them to your boss and you say look this is something this is something we can improve and developer efficiency and the time it takes to get your work done goes directly to the bottom line of that organization that's also a reason to look at getting it as a service not not to to to my own horn but I I the problem the downside of a lot of this is that if you don't have a large enough organization to actually devote the time to maintaining this you should think through the build versus buy decision because it may be that the buy decision if the cost is good is a better one for your organization than the build decision but I think it's important to really know what it takes to build and really consider it for yourself absolutely thank you very much sure alright I'll show you guys Drush and this is real quick and then I'll show you little pants if you want to see so Drush got Drush on my laptop Drush has aliases and what aliases are are ways of pointing Drush at a remote server remote installation of a site so just like you run Drush like inside the the the main code directory of a site you want to do some Drush work on you can set Drush up to essentially be aware of a remote alias and run things there so for instance I have the aliases in on my laptop for the Pantheon public WWW website so I can do like Drush at this status and it's gonna go you know basically you have to have SSH to make this work you have to have some kind of SSH channel but then it can go and find on Pantheon or wherever you're hosting this what's going on with Drush okay so it's up-to-date Drupal core you know there's MySQL etc and you can see the the admin theme and so forth and if you wanted to do like Drush you know WS like shows you the latest Watchdog entries this can be very useful for doing certain sorts of things right and you can you can clear the caches you can do anything else I really encourage like the use of Drush as you build especially if you build complex projects where there's ever anything you want to do like a data migration or import or export or something has to sync with a remote service really think about building that stuff through Drush and not through like a something that runs in a web browser because anything that could take a long time you're much better off building it on Drush than trying to connect it to a user clicking something it's just way more bulletproof and I'll show you real quick the anatomy of one of these files so in order to use this you just have a dot Drush directory and then you have something in there this is from Pantheon but it's really anything dot aliases dot Drush RC dot PHP in your dot Drush directory in your home will be ready to pick up and all that is is you know it's it's PHP file and it spits out an array right so you get an array of aliases there's a doc root a URL database URL and you can actually put a bunch more config options in here if there are certain things that you you want to actually have every time you use Drush you know there's certain things you can specify on the command line the Drush alias file you can use actually locally if you just have a lot of command line arguments you don't want to have to retype over and over again and this is a convenience method for using Drush effectively that allows you to use it against remote hosts and in our case we make it possible for you to use it against dev test or live because that way you know you can act it's a great way to be able to still get your work done even though you don't have shell access to the live environment for instance uh real credentials you can't see the password because this is a oh yeah you can I'll have to go change that anyway yeah yeah definitely not uh we'll have to migrate those hey well this gives me a great chance to you guys want to see like I don't want to do like a pantheon product demo because seriously just go by the booth and those guys kill it at that and I don't want to steal their thunder but I can show you something that they won't show you at the booth which is what I would do if that happened so these three added sites so this is the god mode pantheon and we got a lot of stuff going on behind the scenes of this thing it's pretty awesome super stoked to be working on it and building it so I'm just going to go over here and I'm going to migrate these data servers and this one too because you can see that yeah and all this is like the things we got this I'm not going to try to explain all this but it's it's like a lot of really interesting stuff and so what's happening here is the database server is getting replicated and will there's this mutiny flag we have and it's like kind of a clever joke where the new database gets created and has the mutiny flag and then once it's ready it like goes and destroys its master and then takes over and so what that's going to do is give it put it on a different host and actually give it a different username and password so I'm secure but pantheon is a is a is a tool that's designed to do all this stuff for you basically I I the presentation is based on my experience as a consultant building this kind of stuff as a one-off for some big organizations and it's like a six-figure project sometimes and doing that a few times over and then we started pantheon to turn that into a service so we got a little bit more tight about some of the stuff we do and we do a lot of other interesting things at pantheon because we run this at scale we have you know tens of thousands of sites and you know fifteen hundred to two thousand developers logging in and using this every week so you can't just have everybody load there it's not just oh give him ssh access we have to kind of get clever about about a bunch of things when you run at that scale but it basically gives you that dev test and live workflow you can sync stuff you can move things through there's an air log if you need it etc and if you want to see like the overall demo of how things work I really I really recommend checking it out at the booth because those guys give a really nice demo and there's other people you can talk to me afterwards if you want but I wanted it to show the under the hood stuff thanks for coming if you guys have any other questions just step right up otherwise I will see you all around the conference