 So why does it always rain on me? It should probably be the title to this episode. There is a gray cloud coming towards us. Yeah. So for anyone who doesn't care that, that's a nice Travis reference. Smooth. So this episode is going to be on Travis CI, which is a super awesome continuous integration tool that ties in very nicely with GitHub. So you literally like enable, I think it's like a you I think you're adding a web hook or something in Travis. It's a service you can sorry in GitHub that you add in to your repo and settings. And basically whenever you do like a commit to a repo or you do a pull request or anything happens, you can sell Travis to perform basically set up a VM and do whatever you tell it to do. All you need to do is like set up a Travis YAML configuration file in the root of your project and that can be as simple or as crazy as you want to make it. Yeah. I think I was digging out the the web starter kit. Travis.yamlin is literally just like we need it to run in node four, node five as all it does. And then Travis, because it's set up for an environment and node, it'll go, well, I should probably do NPM install and hope that works. And then it checks for NPM run tests. So the NPM script just called test and it'll do whatever it does. And then given that mocker, it returns an exit code of something other than zero. And then Travis goes, well, the build failed because it didn't do what you'd expect. And it's super handy just having that thing just constantly just checking what the hell you're doing. Yeah. Especially for pull requests, like when you get someone just give you a load of code and you're like, does this just break everything or does it work? Yeah, no, it's just it's super useful for keeping everyone honest about stuff that they're trying to PR in. It's just great. Yeah. I have some some Travis pro tips. Oh, are they your own or? They came to me vividly in a dream or a medium blog post. But so one of the things we do on a few of our projects is we cash our package management directory. So like our node modules directories. Some people might cash their barrel components as well. It generally works with you can cash like any directory, can't you? Yeah, pretty much. If there's something you want to generate, but then afterwards just keep it around. Yeah, just speeds up installation, having it cashed. It's kind of a nice little thing you can do. Yeah. Another optimization is setting your git checkout depth so that it's only running against the latest commits, for example. Nice. I think web fundamentals is such a horrific history on git now by this point that we should probably be using that. I remember using this tool to check out the largest directories on my system with the other day. Web fundamentals checkout was the biggest one. Moving on. Google engineers know what they're doing. And my final pro tip I think was just making sure that you know you can whitelist or blacklist branches so that Travis isn't running against everything. If you, for example, have 22 different branches for Web Starter Kit 2, Matthew. Yeah, I should do some cleanup there. But the other advantage of that that I was going to add on was you can also like Travis adds a ton of environment variables. So if you've got shell scripts you want to run and maybe you want to run certain things on master but not when there are pull requests or any of this other stuff, Travis just dumps a load of environment variables. One of them is just like, am I in Travis? If I am, do this rather than do it if I run it from a command line or something. So that's the other thing as well while checking out because it's just a blog post or just all those things. So Travis runs really great when you're trying to get testing done against Linux or OSX, Windows. I don't think it supports Windows but there is another service called AppVaya and it has its own equivalent to the Travis YAML. It's slightly different but largely it's very, very similar. The only got show with AppVaya that I found a bit confusing is it needs a build number for every time it does like a run and there's a way you can set it up to auto increment but it's kind of a bit weird the first time you do it. But once you set up you're all good to go and it's super handy because it is pretty different from a Linux environment. So out there I found it to be a little bit finicky to get set up pretty consistently but once that's done it's just as easy to use as Travis. Yeah and it's one of those things you only really have to do at the start of a project and then you forget what you've done for the next one. But it's all good. So then the last thing about that is obviously when you set these things up is you get a lovely badge to put on your readme. The one last thing I'd mention because I feel like the tool needs a good shout out is David which is literally a badge and it just tells you whether your dependencies on npm are up to date or not and it's all it does. But I found it surprisingly helpful just for the projects I have just sitting there just going well are they up to date are they out of date what's going on. Yeah love it. Yeah so people should check that out at david-dm.org. There's also so on in the same vein so whenever I'm working on node modules there's a CLI called David very similar thing that you can use and what that basically does is again it will let you know you're outdated like dev dependencies or outdated dependencies list them down in the CLI nicely colored let you know what your version is the latest version is and it'll also give you like this one liner you can run to just like instantly bump everything up which is kind of nice. Nice that is pretty cool which is pretty sweet. There's also this thing recently called Green Keeper. Do you remember Green Keeper? Yes that's the one where it will update everything automatically, run your test suite and if it passes it will then ping your pull request going here you go just update them. Yeah so people should probably check all of those out. If you have good tests yes.