 So I'm really glad that I'm presenting on the last day of Drupalcon and the morning after a big party because that means all the riffraff is still asleep. This is the hardcore people. This is the people who care the most about Drupal. These are the people who are going to really make a difference. So I'm so glad, like, we can just focus. You know, we don't need anyone else to distract us. So thanks for being here, guys. We're really the smartest people at the conference. So this is, production is an artifact of development. And I'm really glad that I had the opportunity to meet some of you. It sounds like some people already have a process akin to what I'm about to talk about. Some people have no idea what I'm talking about, but they really like the word soup that I put on my description of my presentation. And other people are just here to gain some context, to judge me a little bit, to be smug about their own process. So welcome all of you. You all have a place. I am Michelle Creechy, warrior princess. I have been working for the last six months at Pantheon, which I'm really excited about. But prior to that, I was shipping deployment artifacts to Pantheon, working for Palantir. So you can tweet at me at Devmichev. I usually say that I can feel people's tweets on my pebble, but it just died. So that was really a nice affirmation during my presentation. Even if people were sort of talking shit about me on Twitter, it felt good during my presentation. So I won't get that kind of affirmation. I'll just have to work on the courage of my convictions. But if I get a tweet from you, it's like getting a letter in the post for me. So it means a lot. I'm also going to refer to my blog down here at C-R-A-Y-C-H-E-E.io, Creechy.io. Again, this is on a Hoku app, so you can link to these things and click these things. You don't have to sort of write anything down. What a relief, right? Writing things down. What are we going to do today? Here's the agenda. I want to talk about what I mean by artifact, which sounds like that's going to be useful since some people don't know what I'm talking about. Makes sense? Then I'm going to talk about how you make production artifacts. And that will be the bulk of the presentation. And then I'm going to give you all of my opinions ever about why you should only deploy artifacts. So let's get to the what. This is development. Development is a process of building a thing. It is a pipeline. It has tooling specifically designed to build the thing, to test the thing. The tools that you need on a development pipeline while you're building something look very different than the actual thing itself. This is the artifact. To put it in terms that a femur might understand, this is development sass. This is sass. This is readable and usable by human. It's much easier to manage this. It's much easier to write this. This is a good way to write your CSS. But this is what the artifact of sass looks like. And it's this that you should be deploying, not this. But in other terms, these are tools that you might have in your repository that you need to build the thing. You might have be at YAML. You might have your composer file. You might have a vagrant file, Docker, Travis, Circle. These are tools that you need in your factory when you build the thing. But this is all that you should be deploying. You're just using these tools to build the Drupal. Here's another way of saying this. Here's what the root might look like. You might have vagrant file. You might have a readme. You might have executables and bash scripts and grunt files and CircleCI. But this is what your artifact looks like. This for the uninitiated is a Drupal 7 root. So this stuff just builds this thing. This is what you should be deploying. This is Drupal 7. But we're still deploying Drupal 7. In marketing, there's this famous saying that sounds good. That no one really wants a quarter inch drill. Wait for it. They want a quarter inch hole. And I think what they mean by that is, hey, listen, people don't really care about how you get it, how you get to the thing that I want. I have a need. So your solution to my problem is irrelevant. You need to just solve my problem. But what I'm telling you is that no, they actually do want the drill. They really do want the drill. And I think that we as a Drupal community have been thinking for a long time only about holes. I'm going to mix a lot of metaphors here. Just stay with me. Just walk with me here on this journey. We think about a deployment. We think about getting to a deployment. Getting the first punch done. And we don't think about doing it over and over and over and over again. Your clients, our customers, they want the same thing over and over again fast. They want you to build a drill. They might speak to you in terms of the first hole. But they want the drill. This is the drill. This is the hole. Don't worry, I'm about to change metaphors. I have now exceeded my knowledge of power tools. So let's talk about chocolate. Don't make chocolate. Still with me. It's dramatic that I wanted it to be. Make chocolate factories. I'm going to switch over to my local. I think it's kind of fun when I walk over here. It's dramatic. Okay. So this is what a factory looks like. A factory has all of the information for how to build the thing. It doesn't need to be this. It probably should be though. But this is your chocolate. You need to make the distinction between the things that build the thing and the thing itself. I feel pretty confident that I did a good job explaining what I mean by artifacts now. Probably too good of a job. So let's just talk about how we get to this place. This is you. I'm so sorry. I'm really embarrassed. I forgot to introduce who you all are. You have been making chocolate for a while now. You're probably really good at making chocolate. Or you know people who are really good at making chocolate and you work with them. And your customers maybe order small manageable chocolate batches. And you've been doing a really good job deploying your chocolate in small manageable batches. And you make delicious chocolate. Listen, no one here is criticizing your chocolate. Everyone loves it. You've done a great job. Your customers are really happy. But you've heard this hot new term in the chocolate community called DevOps. And you feel like I feel I'm kind of at a place where I think the DevOps is going to take me to the next level as a chocolatier. And this is fortunate because now someone big wants your services. You have something more complicated than you've ever done before. Something that's going to need teamwork. Something that is going to need you to work at a scale that you haven't previously worked on before. This client comes to you. I would like to buy 10,000 truffles. And you get to work. You know what you're doing. You know how to make chocolate. You deliver on time. The customer is unhappy. The first thing that you did was when it was delivered to the client, it was melted. Why was it melted? It was melted because you had been making chocolate in your refrigerated factory on site. But you were delivering your chocolate to Miami Beach. And you had not anticipated when you were working on the chocolate that the chocolate would need to survive under those conditions. It was not what they expected. And the product was inconsistent. So this is what happened. You didn't ensure that your chocolate would survive the environment that you worked in. You didn't ask the right questions. When they ordered chocolate from you, you weren't asking yourself where is the chocolate going to go. You didn't gather the requirements properly. When they said I would like 10,000 truffles with nuts, you assumed walnuts. They were thinking almonds. And you didn't establish a consistent development pipeline. So you were making 10,000 chocolates, but the results were different every time. Unfortunately, there's something wrong with you existentially. And this is the problem that we need to solve. You've been thinking that people are ordering chocolate from you. But they're ordering the chocolate factory. They're buying from you the means to create something over and over and over again. So how do you avoid the melted chocolate? I'll teach you how to do other things. How do you avoid the melted chocolate? Well, you need to ask a lot of questions before you begin. So when this client came to you and wanted 10,000 truffles, you needed to follow up with something like, I don't know, where is your chocolate going to live? Do you have control over that environment of where the chocolate is going to live? And how does Miami Beach stay up to date? How do you intend to keep your chocolate shop up to date? What are your concerns for keeping it safe on the beaches of Miami? We know that there's a lot of people working really hard to figure out how to take the chocolate off the Miami Beach or inject it with things. And how fast do you want to render that chocolate? How are you going to be just serving it up? Are you shoveling it in? Are you just a big scoop of chocolate to people? This is important to know the volume that you should be expected to deliver. That's about cashing. The chances are that your customer will not have been thinking about these things, depending on who they are. They haven't thought about it, but it's your job. They hired you, the chocolatier, the chocolatier who makes delicious chocolates, to think about these things for them. So you could think about where you're going to put it, like Pantheon out there, just off the top of my head. And you think about Pantheon and then think about what that environment would look like. And these are the things that you need to figure out before you even begin work on your project. And then you need to work in that environment. So wherever your production is going to be, you need to build a little Miami for yourself. You can't work in your refrigerated facility that you like to work on. That's finely tuned facility that you feel comfortable in. You know what it's like. This has to be a facility that mimics where it's going to live. And that means you need a configurable virtual environment. We fortunately have the means to adjust temperatures and things in isolated environments and finely tune the humidity and the heat and everything. So I recommend if you don't currently have a virtualization setup. So if you're unable to virtualize your environment, I think Fanceable is a really good way to get started. So Fanceable is a point and click configuration. You can select what version of PHP you want. You only have a choice of embutu environments, but that Linux flavor usually works for almost everything. It's very easy to click around, get what you need. You'll get a Ansible directory. So it uses Ansible, which is another configuration tool. So if you've heard of Chef or Puppet, Ansible is a really great way to get started since it's just YAML-based, which everyone's starting to feel comfortable with. And then we'll give you a vagrant file so you can make it so. If that's confusing, though, because you'll have to make a few adjustments because it's Drupal. So there's a few more PHP extensions that it won't give you. But I wrote a blog post about it. So you can check out my blog, No Excuses, part one of five parts, so we'll get to the rest. But this is on creche.io. There, again, are some alternatives to using Ansible and configuring your Miami beach with Ansible. You could use Chef, you could use Puppet, but you could also just use Bash if that's what you feel comfortable in. I think Bash is fine. What I'm telling you here today might not be the best or most optimal way. I'm looking for an on-ramp for everybody. But I think that once you get started with something like this, you can start iterating and finally tuning and finding additional tools that you might feel more comfortable with as a team. If you'd like to go deeper, I recommend Jeff Gurling's book Ansible for DevOps. So again, the configuration option here uses Ansible. It's very easy, point and click. You just get an Ansible provisioned machine. But if you're serious about this, if you're serious about creating these virtualized environments, you should start to understand one of these tools. You should also be keeping an eye on Docker. The setup uses Vagrant or virtual machine, but keep an eye on Docker. That's what I'll talk about next year. Then I'll talk bad about all the things I didn't know this year. Problem number two, how do you make consistent chocolate? The first thing you need to do is you need to determine your workflow. If you want to get the same thing every time, you need to start paying attention to how you got the thing to begin with. In order to do that, you're going to need to ask more questions of yourself. You'll need to be to practice mindful development. Whenever you go to enable something, you're enabling a module. You're disabling a module. You're turning on a feature. You're clearing caches. You need to be mindful of the order in which you did them and the things that you did. You need to write it down and make it executable over and over again. The questions you need to ask are what are the different variables that I need in production that are different than development? You'd want to turn on caches for production, but you're not going to want to turn on caches during development. You're going to want a different email to test email on development than you are on production. You might find that you need to revert all the features, clear cache, and revert all the features again. When do you write, run, update, DB? These are the questions that you need to start being mindful of, and then you have to find a way to make that executable. Part of this is establishing norms in your team. This is about working in a team, also disciplining yourself, but you need to set as a team a standard that you look for on a pull request level or however you're doing handoffs, where it's not done if someone can't just build it. If your pull request has these long lists of enable this feature, turn this off, do a dance, call your mom. It's not done. Everyone should have the same run this build script. It'll be done. You're so lucky that I wrote another blog post about this. I should have turned on ad words, but this is all out of the kindness of my heart. This is getting started with doing that. I really like bash as an initial pass through. I know it's not really cool, but I'm going to bring it back. This is about using bash, which I think is pretty people feel really comfortable with. I have found great success getting teams of all different kinds of skill sets to adopt bash as their build process. Nick, this is for you. There's this great website you should all take a look at called enterprise shell scripting. I'd like to give you a warning that the worst things on the internet are deployed with bash script. Just keep that in mind that you can do some terrible things with bash scripts and cultivate some mindfulness around your bash scripts, but I think it's a good way to get started. It's better than nothing. There are some alternatives to building with bash. Grunt and gulp are really popular, especially with the front end set. Grunt and gulp are going to require Node.js and Ruby and some other tooling that you're going to have to add to your Ansible directory. A good reason to have your own virtual environment with all the tools that you need is that you only have to figure out once how to add it to your configuration, but if you use a tool like Grunter gulp, you're going to need more robust tooling, and I think front-end developers need to be assertive about what they need to compile their sass, they need compass, but it is going to take some more configuration. Also, I think the humble make file is a tried and true tradition of enabling what you need and you would have a lot of respect in the operations community if you had a make file. You should also pay attention to Robo, which is a task runner. Bash is a task runner, Grunt is a task runner, gulp is a task runner. Robo is kind of interesting. It's for PHP. I've never worked with it, but I work with Greg Anderson, who's the maintainer for Drush, and he's been really excited about it, so it might be something to look at. Your third problem, how are you going to make sure that your customers get what they wanted? This took me a long time in my career to understand, but it turns out you're just supposed to listen to them. And it's a particular kind of listening. It's not the listening where you teach them how to build a Drupal, and then get them to talk about content types, and taxonomy, and node, and get them to talk about your stories. It's about learning how the customer is telling their stories. And this is a skill that I'm still working very hard on developing, but it's not about teaching the client your language. It's about understanding the client's language. These are some things that maybe you should ask if you're having trouble. You could write them on a note card when you have to talk to someone. What are your edge cases? What are you doing? Why? Tell me about it. What's going on on Miami Beach? What's so exciting about Miami Beach? They love chocolate? Tell me about what kind of chocolate they like. Who are your customers? What do they say to you? These are questions that you should ask, and if you're not the person that should be asking them, find someone who is really good at asking those questions and who's willing to ask them and talk to you and do the translation for you. There's, you might have heard BDD, or Behavior-Driven Development, and Behavior-Driven Development falls under the umbrella of test-driven development. It's a refinement of test-driven development. So it's, yes, you should write tests first, but you should write those tests in the language of the requirements of the customer as they have described them to you. So the stories that the customer tells, the behaviors that they want on the site, they have given you the quote test in the form of requirements, and that's what you build. That's what you write. And he has a really great blog post that I've gone back to a lot over the years called What's in a Story that I recommend everyone read, but there's also tools to execute Behavior-Driven Development. So you have these conversations about what someone's requirement is, so they want you sort of probe things further. I would like 10,000 truffles with nuts. What kind of nuts? I would like 10,000 truffles with walnuts. So now you have a refinement of your requirement. And if you wanted, you could write an automated test for that, and there's some tools to do that. Behat is really popular. And Mink is the driver to execute Behat. I've written a blog post about how to do this. So it just carries on how to install Behat with Composer, how to set up the driver, set up Phantom.js. That's not what this talk is about. I've written a blog post about it. Email me if you have any questions. But I would like to share some opinions with you about it, if you don't mind. BDD, Behavior-Driven Development, is not Behat. And Behat is not Behavior-Driven Development. Behat isn't executable, and it can support you in Behavior-Driven Development. But just having the Behat does not mean you have the BDD. These are not the same thing. This is just a, Behat is just a tool, and it can be used to help you or not. So I would say that BDD is starting to become the new Agile, in that everyone says they have the Agile, but no one really has the Agile. No one's really doing the Agile. I feel like I've interviewed a lot of people, and I'll ask. I have to ask. So do you work in the Agile environment? And now it's just getting, we do Scrum or something. BDD is kind of becoming the same thing. Like, you know, you have the Behat, but I don't think you have the BDD. If you do want the BDD, conversations are more important than the tools that execute them. If you really care about Behavior-Driven Development, if you care about understanding the requirements of your customers and making sure that you got there, just having the conversation and writing out those requirements is more important than having BDD or Behat. Learning just how to talk and how to understand your customer, that's more important than spending time figuring out how to implement them. I also find it useful to distinguish between testing and checking. I'm looking at my boss because I've explained this to him unsuccessfully. So this is gonna, come on guys, I can do this. I think it's important to distinguish between testing and checking. So checking just validates that you're done and you stay done. But you got to, like, you've heard the client, they've explained to you what done is, and you're just checking to make sure that you got to that place. That is a really good test to have. You should have checking tests. Those are the kind of tests that you want to keep around for a while, but they should be very minimal tests. The kind of thing that Behat's really good at. So this isn't doing negative and positive use cases. This isn't, checking isn't, if I enter 99999999, you know, as my login, you know, you don't, you're not testing the entire spectrum. You're just checking that the requirements were met. That's different than testing, which is exploratory. Testing is the responsibility of the customer to make sure that their requirements were complete. Someone on their end needs to validate that they did a good job explaining all of their requirements in full. And if your customer can't do that, you do that for them. You have someone to interrogate their requirements. And for this, you're gonna need an environment. So you, you have great automation tools that check that you're done, but you still need to put this on a staging environment and give the responsibility over to your customers or their proxy to ensure that they, they give you the full requirements, the full scope. In addition to Behat, which is an executable, a great, a great checking tool. There's some other tools that you might want to use to make sure that you met requirements. Wraith is visual regression. If you click on this, it goes to a post by my colleague Kate Kilgman about implementing Wraith on Drupal. It's a really great post. I highly recommend it. A11Y or Ally. This is accessibility checking. This is becoming more and more important. You're gonna, you're gonna want to validate that you got to, you, you built an accessible site. It can lint your, your, your CSS and your HTML. And then sitespeed.io. That's a low, low testing tool. I think I link to my colleague Steve Pershe's blog post on how to use that as well. And again, this goes back to those questions that you asked your customer about how fast they want to render their chocolate. So I recommend that. If you want to go deeper, I didn't properly link. So this is supposed to link to a book about cucumber and using cucumber. So cucumber is the original Gherkin language. If these don't make sense to you, this is all sort of part of the BDD world. But there's a great book, even though it's, it's like in the Ruby context and in the cucumber context. But if you care a lot about understanding your customer's requirements and getting their stories, I highly recommend that, that book, Effective Cucumber. All right, your last problem, almost done with all your problems. Boy, are you needy. How do you consistently deploy? If you're going to have a pipeline, if you're going to have this sort of factory, you're going to need a packaging and shipment facility. So if you have all of these instructions, you've got, so you've got your bash, you've got Ansible to provision, you have instructions about how to compile your SaaS and when and how to build and how to turn on features and turn off features and clear caches and to enable the production caches versus the development caches. But those are going to need to be compiled somewhere and packaged somewhere. You're going to need to do the packaging. And for that, you're going to need a CI tool. So I recommend, hold for a moment, that's doing a song and dance. I use CircleCI. I've used Travis and I've used CircleCI. I've come to prefer CircleCI for a lot of reasons. The main one is that I can SSH in when it doesn't work. I also found it a little bit easier for variables. And if you're listening to this presentation, CircleCI, I would, I do live in San Francisco and I would love lunch. Thank you. I have also written a blog post about it. So no big deal, but I wrote a lot this summer. So check that out. I'll be looking at my Google Analytics page the next week. Every environment is different, but your process doesn't need to be. So I want to transition here to talking about why you should work this way. But what I'm describing is that you use a continuous integration tool like Travis and CircleCI or Jenkins. And on that environment, you package your Drupal and you're not shipping your vagrant file, you're not shipping your B-hat. You're just taking that artifact that compiled SAS, that Drupal artifact. We didn't even talk about Composer yet. You're just taking that Drupal artifact and shipping only that to production. These are some alternatives to CircleCI, Travis and Jenkins. I recommend that you read the book or at least buy it and put it on your desk so that other people feel like you read the book. Continuous delivery. It's a really good resource for thinking about these things. But let's talk about why the development and production code are different. So the development code should be optimized for humans. SAS is better because it's easier to work on. It's easier to maintain. It's easier to reason about. Composer, as a way of managing your packages, is easier for human beings because I can separate out what's in my control from what I rely on externally. So I know that I'm not going to do anything to the media module. I'm definitely not going to hack it. I'm not going to touch it. I want it fresh out of the oven as it were every time. I just need to point to that thing that I need. I just need to point to needing the media module. I don't want it in my repository. I want to know that whatever is in my repository is everything that I control. It's my instructions. I have my read me. I have my pointers to other things. That's all that I have. It is made just for me. Just for me to understand. Whereas what lives on production is optimized for the web server that's serving it up. It has the caches turned on. It has everything that it needs to read. It doesn't need to read me. It doesn't need any sort of human hand holding. It doesn't need instructions. It just needs to be optimized to serve that chocolate as fast as possible. Here's the second opinion. We should depend on our platform host to host the thing. Not to build the thing. The environment that you need to build something is different than the environment that you use to host something. Again, going back to Grunt or Gulp or Compass, you're going to need something you're going to need Ruby. You're going to need Node.js. I have exhausted my front-end skills. You're going to need a lot of stuff. They should have those things. That's what they need for their process. That's what they need to build the best front-end that they can. Those are different tools than you would have on production. Those are different tools than the serving of the thing. You don't need Node.js to serve the thing unless you do. Then you're in a different thing altogether. Those are two different subset of tools. If you conflate the two, then you've really confused yourself. You shouldn't have those two environments mixed up. You as a developer are not just entitled to your opinions. You must have opinions. It is your responsibility as a developer to form opinions and to hold them weekly. You should always interrogate your opinions but it is your job and that's why you're here at Duplicon and not sleeping. That's why you're in my presentation. I like all of you guys. You get that you should be forming opinions and you should have them and you should defend them and understand them. You shouldn't have to compromise on your opinions. Likewise, you should expect that the people who are going to take care of your opinions when they become an artifact also have strong opinions. Those can be complementary. They don't have to be the same opinion. We don't have to agree on how you build the thing and how I host the thing in order to get along. Those are two different things and you should trust that the people who are going to serve your thing have strong opinions that they have thought about at least as hard as you have. They've gone to conferences. They've thought about it. They're not the same opinion but they are opinions that you should look for those. You should look for someone who has opinions that you trust and hold your own opinions. I have a lot of opinions so obviously I'm doing this right. Finally, or not finally, no dev dependency should be installed on live server. Yes, right? No, trust me. Let me explain Composer to you a little bit. We're going to talk about Composer. I didn't get into using Composer in your build process but I wrote a blog post about it. You should definitely use Composer. You should have a lightweight repository. Just please do this. Please Drupal. Vendors out of Drupal 8 root now. We're all going this way. You should not carry around the heavy load of Drupal in your repository anymore. Have a Composer JSON that points to the things that you need. If that's not totally clear right now, you should read my blog post and email me. You definitely should use Composer. This is just the way everyone's going. But you should have already run your Composer install before you deploy. You should not rely on your production to run Composer. You should not run Composer install on production. Don't run Composer install on production. Don't do it. Don't run Composer install because, first of all, it takes forever for Composer to install sometimes. It is literally going through a dependence. It is going through an enormous dependency tree. It's looked at your requirements, the requirements of the requirements, the requirements of the requirements of the requirements of the requirements of the requirements of the requirements until it gets to the end and bootstrapping that metadata takes a lot of RAM. Composer is going to fetch those dependencies from a lot of sources. Sources that you had not anticipated, maybe like unsafe sources, maybe sources that you don't have a lot of control over and you do not want those sources to have access to your production environment. There's also rate limits on GitHub, so if you're using, you can get around this. But there's a possibility that you would have a timeout, so you think that you're deploying, but it's only a partial deployment because you're trying to build the thing as your deployment as opposed to deploying the artifact, the already pre-built thing. And your deployments could take a lot longer than anticipated. There's a lot of factors that go into this. You think that running Composer install takes five minutes, it could take much, much longer. Finally, your dependencies could disappear. So this is open source, this is out in the public. There is a chance that something that you depended on is suddenly gone. And if you hadn't built that artifact, if you hadn't run Composer install and then run your tests, or your checks, shall we say, against that, you don't know that you just missed part of your deployment. And lastly, it is better to standardize. Your preference should be to have opinions, and then to have opinions about other people's opinions. You've made choices, you have one thing, that should be the preference. That's the ideal world. But the truth is, for a lot of people, they are not able to standardize. They're needing to ship to Miami and to Alaska, all sorts of different environments. And as much as possible, you want to hold on to your opinions in the development process and be able to accommodate these different environments, to be able to be nimble about where you go. And if you have a development pipeline where you have a process locally, you're working in a virtual environment, and you're deploying to a CI tool like CircleCI or Travis, and that is building your artifact for you. That's building just the Drupal. You can ship that anywhere you want. And if that's your process, then it's much easier to be nimble about where you ship that process to. I'm almost done with my thoughts. And then I can hear yours. So here's some things that I've really sucked at that you shouldn't do. You should value conversations over rituals. It's really easy to find something like B-HAT and to hold on to it, or to hold on to We need to have unit tests for everything. It's really tempting to just feel like that's going to save you, or to want to wrap your project in the safety blanket of a ton of B-HAT tests. Does anyone, I'm just curious, does anyone have a project where their B-HAT tests have gotten completely out of control? Anyone has done that? Yeah. I've been there with you. So just learn from me that if you're wrapping your whole project in system tests, in a safety blanket of B-HAT tests, it's not going to save you. It's going to smother the child and it will die. So start interrogating why you think something is important. Why do you think that B-HAT is important? What is it giving you? And value the conversations about them more than just the rituals. Don't think that any of these tools are going to save you, they won't. Oh, I conflated the two, but think about what your problem is. I've made a lot of distinctions in my career lately between what a problem space is and what a solution space is. So instead of talking about B-HAT, B-HAT is a solution, but what exactly is the problem? And taking the time to understand what that problem space is, if you take the time with your customers even to understand what their problem space is. Their problem isn't that they don't have a news content type. Understand what their problem is. The problem is that they don't have a means to communicate with their anonymous users about events that have happened. Understand what the problem is. Understand that, oh, we have a lot of regressions and we're not ever sure if we have delivered the correct thing to the client or not. If you understand that problem then you can look for a solution like B-HAT or you can look for a solution for the customer like, oh, you could use a news content type, but take the time to make the distinction between your problem space and your solution space. Know that any of these things that I've talked about using a composer workflow, using Vagrant, using Ansible, using B-HAT, using A11Y, the accessibility testing, that any of those practices depends on its context. So if this goes back to asking about what your problem space is, if this isn't your problem you probably don't need that solution. And lastly, there are no such thing as best practices. There's just good ideas and better practices given your context. Just going out to a conference like this and looking for the best practices and come home with the best practices is not going to help you if you don't understand what your context is. There's good ideas for solving particular problems, but there's no such thing as the best. And finally, I work for Pantheon, but even before I worked for Pantheon I preferred to deploy my artifacts to Pantheon. And there's some additional tools you can use if you are deploying to Pantheon like Quicksilver, which will allow you to hook into your deployment and run additional tests like accessibility testing, like load testing. And there's also authentication tokens, which make it really easy from CircleCI or from Travis to authenticate to deploy, to ship your deployment to Pantheon. I have a blog post about it. And these both link to how to do it. But as I said, standardization is really hard. There's lots of different ways to ship your artifact, but have your opinions, hold on to them, and make sure that you're shipping artifacts. I can hang out here, but we have time for a couple questions if anyone has any questions. Yeah, go ahead. Yeah, go ahead. Okay, so your question is how to have better conversations with the customer so that you can execute on their requirements? Maybe, I don't know. So there's no best practices, but I have recently fallen in love with domain-driven development and understanding how a customer describes their domain and making distinctions around their domain. I have not found that going straight to the gherkin is useful for me. There are some processes, and I recommend that you read EffectiveCucumber, about understanding their personas. So who are the, as an anonymous user, who are their customers? Who are they expected to act on their site? What are the actions that they're hoping for each of these groups of people to have? And what are those expectations? So there's some good practices, there's some better practices around using gherkin to help facilitate those conversations, but I actually have really enjoyed domain-driven development and thinking about getting the customer to describe the domains of their business, and this is about understanding their different problem spaces. So this is a problem that we have, and literally like drawing a circle and writing the words that they use to describe the problems within that space, and it's a lot of circles with words to describe the problems, but getting them focused on describing their problem as opposed to talking about their solution, which they'll want to do. We need the WYSIWYG. WYSIWYG isn't a problem, unless the problem is I don't have WYSIWYG, but no one has that problem. I hope that helps answer your question. Go ahead. One thing we've run into is that the customer's story which we're trying to listen to is continually evolving, and so they'll have one thing to focus on, but then they see that and say, well, etc. So any advice on dealing with the ever-changing customer story? I wish I could answer that. I can share my opinion because I like to. I'm not a talented product manager or project manager, but I bet someone like that could talk about scope creep. So the question was, how do you reign in requirements? I think you need a really talented project manager or a really talented product manager, preferably both, and I think that you need to do a lot of discovery ahead of time. I think a lot of people overlook the time it takes before you begin a project to understand all of the problem spaces. We're talking about scope creep as much as the way something can be implementation. So you're talking about, hey, that was really cool that that feature came out, but it's slow? Is that the kind of? That the feature came out that it's not working. We didn't know how to envision it before we saw it. So that goes back to checking versus testing. We can check that we've met your requirements, but you need to test that you gave us the right requirements. We need to have that. That's right. I think those are conversations that you should have with the customer and expectations you should set up front. Hey, this is why we have a staging environment for you. This is why we give you that environment. We need you to test that you have given us the requirements in its completion. I have time for, I think, one more, but you're welcome to come and chat. Okay. So you're source coding, like, you're tracking the basis of your project. You're doing the build, and then you're developing the artifact. Is the artifact also version control? And how do you get to the project? Okay. Yeah. So the repository that I use to manage a development environment on GitHub is a different repository altogether than the repository I use for production. And for me, production is deaf, not live. Production, for me, is the first time that the client has the opportunity to look at it. That's live for me. I don't touch it after that. By the time the customer sees it, that is production for me. And then it goes through production stage, or, sorry, test stage live. So to clarify that, yeah, I use two different repositories. I've done that two different ways. I've used Git sub-module to just, you know, deploy it as a sub-module. I don't, I didn't love that. That was pretty sloppy. Now I just have a Bash Christian Circle CI that authenticates to Pantheon. And so after a successful build and I've tested, I wrap up my, my, my, the tar ball of the database. Throw that up there and deploy to a different repository. And Circle CI is the only thing that deploys to Pantheon. No one else has permission. It's only through the robot that it can get, get to product, to what, what's production for me, which is development. Okay. I think we're out of time for questions, but come, come and talk to me, Jordan, or anyone else. Thanks so much for being here, guys.