What do you want to learn? Leverged jhuang@tampa.cgsinc.com Skip to main content Pluralsight uses cookies.Learn more about your privacy Integrating Node Applications with GitHub by Daniel Stern In this course, you will learn to test files automatically with Travis, how to deploy GitHub repositories automatically with Trello, and much more. Start CourseBookmarkAdd to Channel Table of contents Description Transcript Exercise files Discussion Recommended Course Overview Course Overview Hi, I'm Daniel Stern and I'd like to tell you about my new course on Pluralsight Integrating Custom Node.js Applications with GitHub. I'm extremely excited to be presenting this course as it's full of information any developer would consider highly practical and useful for everyday situations. GitHub is a tool used by corporations and independent developers alike to create more reliable code and collaborate efficiently. In this course, we'll learn to augment the GitHub experience by integrating it with other productivity tools. We'll start off by learning to integrate GitHub with Travis CI. An essential tool for any team which makes it possible to send error-free code to production every time. We'll then learn how to integrate our repository with Heroku. GitHub-Heroku integrations are some of the most powerful of all as they'll allow us to deploy our app to the web live with every commit and allow us to use our custom Node.js back-end. We'll also learn how to connect GitHub to Trello so as to better connect with our clients and teammates. We'll even cover WebHooks an advanced tool that you can use to create your own integrations. All in all, I'm very proud to be presenting this course and I hope that by watching it you can improve your productivity and take your Node.js apps to the next level. Integrating NodeJS Applications with GitHub Introduction / About the Author Hello, I'm Daniel Stern and welcome to integrating Node.js Applications with GitHub. GitHub is an extremely popular and useful tool that's used not only by independent developers but by large organizations all over the world. There's no question that GitHub is the industry standard for managing and organizing your large projects. But is there a way for us to integrate our Node.js applications more closely with GitHub? Is it possible for us to leverage some of that online technology to increase our productivity? The answer is yes. Whether you're implementing, testing, or deployment or communications, integrations with GitHub can all greatly increase your productivity. I've worked with GitHub for many years, and in addition to having worked with it in many large companies, I've also taken the time to make several of my own public repositories, many of which have over one hundred stars. I've definitely spent the time it takes to learn about GitHub, and now I'm going to share my knowledge of my favorite integrations with you. All in all, it will be a great course, so please stick with us. Course Roadmap Let's take a moment to discuss the roadmap for the course ahead. In the first chapter that follows this one, we'll be discussing continuous integration software, specifically Travis. This software allows us to automatically test our application and run our custom tests on a variety of platforms automatically every single time we push to GitHub. Integration like this is, of course, incredibly valuable for any large company where there're dozens or hundreds of developers working on the same code base. We'll go over the whole process of integrating our GitHub application with Travis. Now, if you've worked with Node.js applications in the past, you'll know that they can be much more challenging to deploy than PHP based applications. Fortunately, a popular tool for deploying Node.js applications, and one of my favorites, Heroku, comes with some very nice GitHub integrations. We're going to use Heroku to automatically deploy not just our main repository, but also any portal request we have to the internet every time that they're pushed up to GitHub. Next, we're going to have a look at creating issues automatically and also managing your repositories with discussing board software. We'll be using Trello, for example, but what we'll learn is pretty general, and you can apply it to your software if it has a GitHub integration. Facilitating discussions really does help keep our code clearer and also pleases the client, so this should be a very good chapter. Finally, I've taken the time to add a special chapter about custom webhooks. Basically, a custom webhook is a service endpoint that you can set up that GitHub will hit with specific information on a specified schedule. So, for example, you could create a custom script that every time a new branch was pushed, an email will be sent to you. Really, anything you want can happen. That's what makes these webhooks custom, and at the end of this course, we'll be putting one together and deploying Git to Heroku and watching GitHub interact with it. Before Beginning the Course Alright, so we're about to get started with the hands-on portion of this course, but before we do, let's make sure everything is all setup. First, you're going to want to make sure you have an account at GitHub.com. as most developers do, which it shouldn't be trouble, but if you don't, now is the perfect time to get signed up. Here I am at the web page for GitHub, GitHub.com. As you can see, it's very easy to signup. All you have to do is pick a username and an email address and a password. Enter this information, and you will be all set up for the next step. This course doesn't require a gold GitHub membership or anything like that, just a standard one will do, and if you already have one, there is no need to create a new one. Just make sure you're signed in before you continue. Next, you're going to want to have Git installed on your computer. This tends to be fairly simple whether you're using Windows, Mac, or Linux. Well, not a hundred percent necessary, we're going to be using the Git CLI to push our changes and our branches to GitHub. There are other ways, but using this way will help us keep our focus the most on the integrations we're trying to learn about. To download Git, just visit git-scm.com as is visible in my navigation bar. You'll see the opportunity to download Git for whatever platform you're using. Now, there are other Git clients, for example, the Heroku Git client, and if you already have one, you should be fine. However, if you have no Git in your terminal, just go ahead and download and install this application, and you won't fall behind in the next video. For anything else that I'll be having you sign up for, Heroku, Trello, we'll be doing that at the beginning of their respective chapters, so that's all for now. Why Integrate with GitHub? Over the course of these videos, we're going to discuss how to integrate application with GitHub, but before we do that, I thought I'd spend five minutes discussing why just so that you can make sure that taking on this project makes sense for your goals. So, GitHub is a commonly used tool for managing code bases as we mentioned. It's used by a lot of companies and only getting more popular. Therefore, learning these integrations make sense not just for the project you're working on now, but potentially many projects in your future. Next, if you ever try to manually test applications, especially an application to be contributed on by multiple developers, it's not easy. Not only does it take a lot of time, but it's very easy to make a mistake, forgetting to test one version of Node, or accidentally testing a particular version and thinking it's another. Integration lets us do all of this automatically which is a big life saver. If we take this a step further and realize that continuous integration helps us save time by not repeatedly doing tests we don't have to, we can realize that if we have many developers on our project, then these time savings become multiplied. The sky is the limit for how much leverage you can get out of GitHub, but the more developers you have, the definite, more advantage you get from it. Finally, since integration happens automatically, it can prevent poor code from ever being committed to repository. Maybe you as the senior are at home asleep, and some junior developers who are working late decide to commit some code that doesn't pass the linting. Instead of yourself having to look at it and deciding it doesn't work and sending it back, your integration software, in this case, Travis, will do so automatically. This allows any lead developer to know with confidence that only high quality code is entering the repository. And as we know, low quality code is the reason for most errors that occur in Node.js applications. Business Reasons for Integrating NodeJS Applications with GitHub So, we just talked about some of the reasons why you as a developer would like to use GitHub and integrate with it. Now, let's take just a few minutes, and discuss the business reasons to integrate applications with GitHub. Whether you, yourself, are the business owner, or you're a senior developer and you're trying to explain to the decision makers why you should use GitHub or pay for a particular integration, this knowledge will be useful. So, first of all, no one likes it when sloppy code gets into the code base, but when a change that breaks the entire application makes it to deployment, thousands of dollars can be lost instantly. Now, by connecting your deployment tool, say Heroku, to your continuous integration towards Travis, you can set it up so your production branch will only deploy automatically from branches that have passed the test. That means there's no room for human error or someone accidentally pushing the wrong branch. If the branch doesn't pass the test, then it can't make it to production. It's just that simple. Next, an ability that Heroku has, as well as many other deployment tools is to review a branch automatically by creating a temporary website for it. If you've been in a senior development position, you know how tiresome it is to clone GitHub branches from the earlier developers, get them running on your computer just to test them, and make sure a simple things works. By integrating with Heroku in the right way, you can simply go to the appropriate URL to see the changes. This really lets senior devs jump and quickly review work, making them less likely to create errors in their own work that they were maybe working on at the time. Next, when we're talking about integrating with a message port like Trello, this is really a tool that lets the client see inside your workflow. Since you may be sharing aspects of your Trello message boards with your clients, they'll be able to see the progress on GitHub as it happens. Clients can feel assured that their important issues are getting the attention they deserve. Finally all these integrations we're dealing with, be it Heroku or Trello or otherwise, are all software as a surface. That means that your organization can save lots of time and money by not implementing these tools themselves. With just the small monthly fee that is required, these advantages can be gained, and for a business that is low on time, these can be very useful. Integrating Node Applications with Travis CI and GitHub What is Travis CI? Alright, welcome back. In this module, we'll begin integrating our application with GitHub. Starting with Travis Continuous Integration Software. So what is Travis? Travis CI stands for Travis Continuous Integration. In other words, continuous when it's happening all the time morning, noon, and night. And integration, as in something where every piece of the whole works together. Software, in other words is an application that tests your software all the time. When you can't, when it's necessary it runs the tests and integrates them into your work flow. So Travis is very popular with large teams. It makes more sense as a tool for a large team with dozens of developers than just for a single developer. As teams grow, the complexity of builds increases to the point that it's no longer possible for one developer to fully understand it and perform it without any errors time and time again. In technical terms, what Travis CI does is when you make a push to Git it goes ahead and clones your Git repository. It then builds your repo and runs it on its own servers. It checks the results of this running against the tests that you've specified. And if everything works, the test passes. GitHub can then see if that test has passed using the built in API. So to conclude, Travis is a very exciting continuous integration software. And we're going to be implementing it into our application this module. Is Continuous Integration Right for Your Project? In this video, we're going to ask the question is continuous integration right for your project. As I mentioned earlier, continuous integration makes more sense for large teams than it does for small teams. There are other factors too that effect whether or not you should consider using it for your next project. First of all, with continuous integration the testing does not all lie on one person or group of people. If you have an application and a single human is solely responsible for testing it then if that human makes an error and everybody makes errors then the entire application could fail in production. When you use a CI you make that CI responsible for testing your application. Computers aren't very creative but they never get tired and they're able to perform the same repetitive task perfectly time and time again. So, that can make a lot of sense. Next, relating to the previous point sometimes test suites can have hundreds maybe 200 tasks. Running all the tests might require spinning a protractor or a different tool or maybe a whole variety of third party or end to end tools. It's easy enough for a human being just to run a JSHint script and be done with it. But if there's hundreds of scripts that need to be tested against various different versions then it's going to be nearly impossible for a human being to do this every time without making an error. So if you have a large test suite you basically need continuous integration. Next, certainly you've been in a position where you've been developing an application at work and everything seems to work fine but once you push it to the production branch or see it in an actual server something doesn't seem to work right. Running your tests locally can make you think that your application works when it doesn't. However, Travis runs your tests externally. It's able to spin up a version of Node at exactly to your specifications for each and every test. So basically, if you're only running your tests on your local machine you're kind of running blind from a perspective environment unless you're using Docker or something to completely recreate that environment. And as I just mentioned Travis can easily test multiple Node versions. So if you have an application that supports Node one, two, three even four, even io.js. You can easily test all these different versions. You'd be surprised when an application that works in one version of Node fails in a different one. Next, and this is a very interesting point. Travis is used by our other GitHub integrations. For example, Heroku can use the bill status from Travis to make sure that everything is good with a production branch before promoting it to actually being seen by users. This is a pretty amazing feature when you consider the alternative which is a broken application being pushed to users and nothing working. So Travis really does make a very nice backbone integration to get started with. And once we integrate Heroku we'll see how seamlessly it works together with Travis. Finally, as if all that wasn't enough Travis will work for your public repositories absolutely for free. If you have some private repositories and you also want to run continuous integration with Travis that might cost a bit of money because Travis is a business after all. But if you're just working with public repo's so something open source or just for your own learning you can use Travis at no cost. A Look at the App In this short video we'll be taking a look at the application that we'll be using for the entirety of this course. If you want to code along you can grab the application from the project files. Basically you're looking at a basic message board app. This might be an application that a company would use to share internal messages with its employees. It uses JSHint working with Gulp to provide some means of testing our code quality. And it uses Express combined with Node to make the delivery possible. This is important because our Heroku deployment tool is very good at deploying Node applications. So here I am, I've opened the application folder in my text editor brackets. First, I'll run npm install. Now I'll start the application with npm start. It's listening on port 80. Now let's check it out. Alright, so here's our application. As you can see, it's extremely simple. It consists of a title and then a list of any number of items. Each with its own title, a message and a link that can be clicked. So basically on the main directory the App enters through mainjs. Where the Express server starts. The Express server uses the App directory as a static directory to do most of the front end logic. This JSHint RC is our configuration for JSHint. We're also using Gulp to orchestrate all our pre-build tasks. Here tests, we have a dummy test file. Basically, it will just throw an error if we tell it to do so. This will let us see what happens to our deployments when our App throws an error on build. The rest of the App is pretty self explanatory. So I'll leave it to you to have a look at your own time. In the next video, we'll be preparing our App to integrate with Travis. Preparing the App for Travis Alright. In this video, we're going to make a few small changes to our application to make it compatible with Travis. Now apps that are integrated with Travis require a .travis.yml file. And this file contains information regarding what environment you should run tests on. Which Node version or versions to use and other things. So the .yml file will change from one project or platform to another. We're going to make one that's just right for our project but remember, for other Travis integrations you'll be writing a different .yml file that makes sense. Okay, here I am in my text editor. We're going to need to add a .travis.yml file to this body of code. So let's add it in the main directory. Remember, the dot at the beginning. First we'll define a before script. This script is going to run before any of our code runs. So we'll just do our installations here. We'll say npm install and then we'll install Gulp globally. Now when we want it to actually test we're going to have to call it gulp test. So we'll define what we want it to do inside our Gulp file. We'll specify the language is nodejs. We'll define an environment. As you can see here we're using process.environment.port for our listener port. This is going to come in handy later for Heroku. But here inside Travis inside env we can define this so we can say env.port and we'll make this different. We'll make it equal to 7777. Finally, we need to specify our nodejs version. We're actually going to use two. We'll say it needs to work under 5.1 which is one of the more later versions. As well as four. Which is one of the first versions after merging with IOJS. Finally, just to be a little tricky let's put in version 0.12. Since I used some ES6 in this demo this should actually fail at the 0.12 build. We'll see what becomes of this once it makes it to Travis. Finally, let's commit these changes to our GitHub repo. If you haven't already, git init. And then we'll add all the files and commit them. Uploading the App to GitHub Alright, in this video we're actually going to get our application loaded up to GitHub. Now most people are familiar with how to use GitHub so this shouldn't take too long at all. Now, first create a new repository. I already have one here that I've created called integration test repo demo. Once you have it created, grab this link up here. Now, open up a terminal window in the directory of your application. Now you're going to need to have Git installed and integrated with GitHub in order for this to work. This is fairly beginner so we won't be covering this in this video. If you need to get your computer integrated with GitHub please have a look at the tutorial on github.com. It only takes about 10 minutes. So we'll say git remote add origin. And we'll paste the string that we just copied. Now we can push this to our origin. First, let's add all the changes. Now, let's actually just make sure we're on our master branch. I'm here on a different branch on my computer so I'll down to master and make sure that it has all the latest changes. Using the minus sign after git checkout we'll check out whatever branch you just had checked out. Same works for merge. Alright, now let's push this to origin master. Alright, and here's my application. It's up at github.com/integrationtestrepodemo. So that's about all. If you've gotten this far you're pretty much ready to integrate with Travis in the next video. Integrating a GitHub Account with Travis Alright, so we've gotten our application all ready and uploaded to GitHub. In this video, we're going to integrate Travis with GitHub. Now, as much as I'd like to take credit for devising a brilliant way of integrating GitHub with Travis I have to admit, it's actually completely trivial already. Travis has made it so easy to integrate Travis with GitHub that this video shouldn't need to be very long at all to explain everything you need to know to get GitHub fully integrated with Travis. Once this is completed Travis will automatically run continuous integration every time we update our master branch. It's just that easy. It really is designed to take some of the mental load off working with GitHub repositories and testing. Okay, so here I am at travis.ci.org. If you don't have an account already you'll have to sign up. But amazingly, you can sign in with GitHub. Which takes something like a 10 step process and makes it into a one click button. I really like Travis's sign up. So I'll go ahead and click this sign in with GitHub button. And that's it. We're in. Just ignore this repository I have here. This is a previous one that I put together. So here, next to my repositories click this plus. This will let you add a new repo. As you can see, it only shows your public repositories. Let's find the App that we just made. If you don't see a repo, click this sync account button. Alright, and here is the new App we created. Integration test repo demo. So I'll turn that on. And that should be all that I need to do. Now I can find my repository here on the left. Alright and it's integrated with Travis. In the next video, we'll do a couple of builds. Exploring Travis Features Alright, so here I am in Travis. And nothing is happening. It says there are no builds for this repository. Well, I haven't actually pushed anything to GitHub since I integrated with Travis. So let's make a change to our GitHub repository and see what happens. Here's my repository. I'll just open package.json and change the author. This will trigger a rebuild. It's like I pushed to the repository. Now, you can see I do have a build and it errored almost immediately. The error says please make sure the file is valid yml. And it found a character at line two, column one. Hmm, let's see. Yup, looks like there are tabs in this script. Those need to be double spaces. Let's fix this right in GitHub. And we'll save our changes right in GitHub. Now back to Travis. And now you can see the build is working. It's doing three builds. One for each version of nodejs I specified. If we click on the build we can see everything that's happening. For the time being, it will just have to install Node and get sort of the environments all set up for it to work. So we'll give it a second to run all those builds. So it looks like our build in 2.1 passed but let's see about all our builds. Ah, our nodejs 0.12 build failed. And as you can see, you can't use let in the same way. So that build didn't work. Hmm. Alright, let's try making a couple of changes. First in our yml file let's go ahead and delete this version 0.12 or we'll put a pound sign before it. Since we know it doesn't work. That was just a demo. Next, let's go to my test script. I'm going to change debug throw error to true so it just throws an error. That's all it does. And we'll save that. Now let's go back to Travis and see what's going on. And it's actually created two new series of builds. One for the update I made to test and one for the update I made to Travis. Hmm, as expected. In the first change, when we updated travis.yml the build passes because now we're only testing 5.1 and four. Both of these work so we get a green build. This one however, both the builds fail. Because we changed tests. Here's the error that gets thrown and this is your way of telling Travis something doesn't work in this branch. And Travis will fail the whole build. Hmm, well let's get everything working properly. We'll go back to our repo and change debug throw error back to false. We'll commit those changes and let the build happen. After experiencing Travis firsthand you have to admit that everything really does happen instantly. The automatic integration is very cool. We really haven't had to do anything other than integrate it with one click and add a Travis yml. And our tests are running all on their own. Of course, being one person with a single test this might not seem so amazing. But if I had a test suite of say, hundreds of tests and the team contained dozens of developers this integrated platform running the tests would be so, so valuable. Alright, and all our builds passed, awesome. In the next video, we'll be looping it back and adding a continuous integration status to our GitHub page. Adding Build Status to GitHub Repositories Alright, so we've integrated with Travis. And now Travis knows whether our App is working or not. But what's an easy way for us to know when our App is working or not? So you might have noticed the message build passing or build failing on certain project's GitHub pages. This can be added through Travis. So, this flag will let a developer know a problem has occurred. It might also let someone who is not developing the project but say, just choosing to use it in the case of an open source project like Angular to know that the latest version might not be the best version to use. On the flip side, if there is a big green passing button then it inspires confidence in those who were maybe not sure about using the resource. And of course, you don't really need to integrate anywhere you don't want to add continuous integration. So, there's no reason not to learn about this interesting skill. Alright, so here I am in Travis. You can see here I have this funny little build passing button in the corner. If I click it it gives me a link. I'm going to select the markdown version so it works right inside my GitHub read-me without any additional trouble. I'll copy that. Now, let's go back to our GitHub repo. I'll add a read-me with this button. Now I'll just paste in what I copied from Travis. Commit that. And there we go. It says our build is passing. If the build were to fail, we'd know because this statement would change. And that's about all there is to it. We have our repo integrated with Travis and Travis integrated with our repo. Travis CI Conclusion Let's take a few minutes to wrap this chapter up by reviewing what we've learned. So travis.ci can integrate easily with almost any GitHub project. All you have to do is select the project out of the list and turn the little switch. It is completely free if you're using a public repo. So there should be no cost to get started for any project that you do that is for example, your own personal project or open source. So inside Travis, we can automatically run our tests and we can also test against multiple different versions of Node. With no additional personal effort. We've discussed thoroughly that the real advantages of Travis are to be seen when there's a larger team. Just one person, sure they can take advantage of the services offered by Travis but it's not totally useful when compared to the advantages that are gained by a big team. And finally, we've learned that after integrating Travis we can put our Travis status on our GitHub page which lets everyone know that we've integrated with Travis and that our application is working. In the next chapter, we're going to combine this integration with Travis with an integration into a new program, Heroku. The upcoming chapter has to be one of the favorite modules that I put together for any course so I really hope that you watch it and learn a lot. Deploying GitHub Branches Automatically with Cloud-based Deployment Software (Heroku) What is Heroku? Welcome back. In this module, we'll be doing our most interesting GitHub integration to date. We'll be automatically deploying GitHub branches by using a cloud-based deployment software. Now there are quite a few cloud-based deployment softwares: Amazon Web Services, Google Cloud. But in this case, we'll be using Heroku. So Heroku is a cloud application platform, a new way of building and deploying web apps. Now this is what Heroku says, but I think it's a very accurate statement. Typically, if you're writing PHP apps, you'll deploy it to any standard regular server. PHP is so widely accepted that it's often no concern at all where you're going to deploy your PHP code. However, as you may have experienced in the real world, many fewer host are able to successfully host NodeJS code. But Heroku is one of those tools. So what is Heroku? So Heroku is a tool to deploy apps that are built on various platforms. In this course, we're doing NodeJS, but Heroku is also good for deploying Ruby apps or apps written in .NET or really any app at all. So when we're working on our NodeJS application locally and we want to take what we see locally and push it up onto the Internet, we're going to need a tool like Heroku. As we discussed before, most regular ISPs only support PHP and in most cases, Perl, but not NodeJS. So if you want to deploy your Node application on just a regular host, usually you're out of luck, which is why learning to integrate with an application like Heroku is so important for any developer. Finally, Heroku is often called a Platform as a Service, or a PaaS. This is because they worry about all the technical and hardware details related to deploying your application. Scaling, distribution to faraway places, troubleshooting, integrating with other tools, Heroku has all of this covered so you can focus on what matters, which is the inner workings of your application. With all this in mind, we're ready to get started using Heroku by integrating it with our GitHub. Getting Set up with Heroku In this video, we're going to get set up with Heroku. So if you don't have a Heroku account, we're going to get one in this video. If you already have one, you may be able to skip this video though it's quite short so you might as well watch it. Now Heroku does have a free account which is the kind of account we're going to use. It's more than sufficient for learning how to use Heroku, as well as prototyping our application. However, Heroku does have many paid tiers, which are necessary if you want to actually put your app into production where it may be viewed at any time by any number of people. Heroku does have a reputation for being quite expensive, but since it's so reliable, it should be easy for any business to determine if the added reliability is worth the added cost. Often I believe it is, which is why I think Heroku is a great tool. And in this video, we're just going to sign up with them. So here I am at Heroku.com. I'm going to go up to the corner and click Sign Up. Here's the sign up page. I already have a Heroku account, but I'll walk through this process. So you enter your name and the other information it asks for. And I'll select language. Once you fill up the form, you'll be sent an email to confirm your account. Click in the email and your account will be validated. All right, once your account is set up you should be able to use your Heroku dashboard. You won't see quite as much as I have on my dashboard since I have been using Heroku for some time. But as a quick overview, on the left you have a list of your apps that you can quickly use to jump from one app to the other. In the middle you have a list of all your active applications. This quick view is very useful as it allows you to make sure that none of your apps have thrown an error and aren't running. In the top right corner are the options that we can use to create a new application. We'll be using these in a coming video. But for now, let's learn more about our deployment options. Deploying Node Applications with Heroku Explained So let's take a minute to discuss deploying apps with Heroku. If you've never deployed an app using a cloud-based software, this can all be very new so it helps to take a bit of time to review. Now when working with Heroku, you have three main deployment options. You can use the Git command line interface, which we installed in a previous video. To update Heroku right from the terminal, you can integrate your Heroku with your GitHub which will create a deployment for each repository and automate it to update whenever your repository is updated. The third option is to use Dropbox, which treats a Dropbox folder in your possession as though it were the root folder of your application. As you can guess, we'll be focusing on GitHub deployment. Not only is it probably the easiest to use deployment method, but it is the topic of this course. So you might have heard a bit about Heroku, but what exactly are the details of deploying Node applications with Heroku? Well first off, with Heroku, the apps scales itself based on usage. So with a tool like Heroku or even Amazon Web Services, you don't tell it that you want an app that can support say a million users at the same time right away. Instead, you just say, hey Heroku, I just want an app that will support 100 users. But if a million users all sign up at the same time, I'd like you to expand dynamically so that none of them lose their connection and they all experience the app. And then when they go away, shrink back down to being 100 users. Because you only get charged for the dyno that you use, dyno being another word for deployment that Heroku uses, this can actually be very cost-effective since you're not paying to support a million users every single day. So at its simplest, you can look at a Heroku deployment as taking the master branch from whatever GitHub repo you have, taking that, copying it and then running whatever your npm start script is. And if that script kicks off a server, then that server will be your Heroku application. There are more sophisticated deployments, but this is the one we're going to be using. And as mentioned, deployment isn't really anything too special. You can simulate a deployment when you clone your GitHub repository and then run the script to start your application. Heroku will also install npm dependencies. Intelligently, Heroku won't grab the dependencies off the Internet every single time. But every additional time you update your app, it will just diff to dependencies and grab the ones it needs. Now in my opinion, one of the best parts about Heroku is that automatic deployment is possible. So that means for both your master branch and for pull requests, both of which we'll be covering, you can have your Heroku update automatically whenever you decide to make a pull request or push your changes. That means, as a developer, you can completely ignore the deployment process and let it be automated. In this way, it's easier to focus on developing the application itself. Manual Deployment via Heroku In this video we'll be manually deploying a branch from our GitHub page, in this case the master branch, with GitHub and Heroku. Now it's not too complicated to do. We're basically going to have a look at our package json and then deploy it. All right, here I am at my repository. Now if you still don't have this repository on your computer, you can just go ahead and fork it now from my repo at danielstern/integration-test-repo-demo You might get the completed version, but at this point it's better than following along with no files of your own at all. Now we'll visit package.json. Now the package.json covers a few important things. Really, all I want you to notice for this one is the start object in the scripts object. When you install your application Heroku, it's going to call whatever your start script is. If you have no start script, your Heroku application won't work. In this case, the start script is correctly configured to call gulp. As you can see, our default gulp task calls serve, which requires our main.js, which activates our express application. So whenever deploying an app to Heroku, you need to make sure that your npm start starts the app. Now that we know our package.json is correct, let's create a new application on Heroku. We'll click on the plus and create a new app. I'll call my app integration deploy demo, but you can call your app whatever you wish. And select the runtime and create the app. All right, so we've created our first Heroku app. Now there's a whole lot going on, and this isn't a whole course on Heroku because rest assured, one could easily spend several hours discussing all the excellent features offered by Heroku. So I hope you forgive me if we focus only on the elements that are relevant for completing this module. So here it gives you a deployment method, as well as instructions for deploying if you want to use the Git BASH. As you can see, they're kind of complicated. And luckily, we're not going to be using Heroku Git, we're going to be using GitHub. So we'll click the button that says GitHub here. Now you may be asked to authorize Heroku to your GitHub. After you have, you'll see your GitHub username and a box where you can search for your repo. So type whatever you named your repo here and click Connect on the appropriate repository. All right, so we're connected to GitHub and we can see this bright green connected indicator. Let's see if our app works. Click on these dots in the corner and go to open app. Hmmm, this does not look like our application. Ah, let's scroll down past automatic deploys, which we'll revisit in a later video. To this manual deploy section. Now I'll select the branch that I want to use, in this case, master, and I'll click deploy. Now right here on the same page it's giving me a log of my build. This will probably work, but if it doesn't, we'll be able to see whatever errors appear here in this terminal. If it says your app was successfully deployed, good work. If not, there are many possible problems so I encourage you to have a look on Stack Overflow with the details of your specific problem. However, if it did work, we can now click View. Ah, and it's our app, are app up on the cloud. Anyone can now visit your app anywhere in the world. I don't suggest visiting the URL at the top since I'm using a free dyno for this. The dyno will only be alive for so many hours during the day, so if you visit this URL there's a chance you might get an error. Well, it only took about five minutes and we manually deployed our application. This is a huge step as many developers are very intimidated by the idea of cloud-based deployment software. But now you can confidently deploy your GitHub integrations. Integration Between Heroku & Travis If you've ever played a collectible trading card game or even a game of chess, then you already understand the value of synergy. Synergy is when two things work together that independently they're great, but together they somehow add up to greater than their individual parts. The example of synergy we'll be discussing is the synergy between Heroku and Travis. So once Travis is integrated with your GitHub repo, which we did in the previous module, it will automatically be recognized by Heroku. Heroku will simply pull your GitHub account and GitHub will tell Heroku for you the user set up Travis as their CI. Since Travis is so common and popularly used, Heroku has already figured out all the integration details. The way this works in practice is when you select automatic deploy, which we'll be doing shortly, Heroku will wait for your Travis CI to finish before it builds. If your Travis fails, it won't build. This is fairly useful for branches and such, but it's invaluable for production. As I've mentioned before, you simply can't have the responsibility of making sure an app in production works perfectly lying fully on a single person. I mean, people are good, they can do a lot of stuff, but people need to sleep, people make mistakes. Travis CI, I'm happy to say, does neither of these things, and neither does Heroku. The natural result of this synergy is that if used correctly, code that doesn't work or broken applications will simply not reach production. They'll be stopped well before that. So here, back in our apps dashboard, if we go down to automatic deploys, we can see we have this option, wait for CI to pass before deploy. This option will integrate Heroku with Travis so let's give it a click. And that's about it actually. If that enable automatic deploys button is looking tempting, don't worry because we'll be clicking it in an upcoming video, enabling automatic deployments for our application. Automating App Deployment All right, we've spent quite a bit of time getting GitHub ready, getting Travis ready, getting Heroku ready, but it's now time to reap one of the principal advantages of this workflow, automatic app deployment. So with automatic app deployment, the master branch can be automatically deployed. Whenever it's updated, the dyno that represents it will be updated too. No additional changes are required on the part of the developer. It's possible for lead developers or interested business parties to be notified whenever a deployment happens automatically. So of course, you know you have your Travis, you have your tests, but let's be real, if you're the senior dev on the project, you're still going to want to make sure and look at your application in production anytime it's updated. I'm not saying it's the right thing to do but any senior developer simply has the irresistible urge to always be watching their applications like a hawk. And this is facilitated by notifications. Of course, if you want, you can build your own GitHub integration to be notified in a way other than email, but we'll be covering those in the chapter on web hooks coming up. As we've discussed, the automatic app deployment can itself be integrated with Travis CI or a different CI so as not to deploy any code which does not work. And as we mentioned, this can be further integrated with web hooks for any different number of possible custom behaviors. Automatic App Deployment Demo All right, in this video we'll be automating app deployment. We'll enable automatic updates so that every time the master branch changes, the deployment will automatically redeploy. However, it will listen to Travis and make sure that the change does not cause Travis the error. If it does, our deployment will remain unchanged. There's not going to be a lot of code wizardry here as Heroku really does make this super easy. But we will demonstrate it right now. So here I am in Heroku. In the automatic deploys section, there's a button at the bottom that says enable automatic deploys. To enable them, give the button a click. I have to say that was pretty easy. But does it work? Let's find out. Here's our application. And here's our repo. I'm going to go into my repo here and let's make a little change. I'll visit messages.json and I'll edit it right here in GitHub. And I'll change a couple of things. I'll change water cooler on 5th floor to pop machine on 6th floor. And I'll change the time of the build to 9pm and I'll commit these changes. And viola, after about two or three minutes, the application updated automatically. There was no need for a manual deployment step of any kind. All right, so that was definitely extremely useful. In the upcoming videos, we're going to learn about doing the same thing for our pull requests. Manual Pull Request Review Process So before we enable automatic pull request review apps, in Heroku I want to take a look at the manual process for reviewing a pull request. Now if you've worked in any large company, especially as a senior developer, you are definitely familiar with this process. So typically, we'll start with the junior developer making changes and pushing those changes to a branch on the shared GitHub repo. Next, the senior dev who is also working on the same project stops what they're doing, commits or stashes all their changes and shuts down their app. Then they clone the branch that was pushed by the junior developer, install all the dependencies, check out the branch and then run it. The senior developer then manually reviews the application and makes sure nothing has broken. They may also review the code itself to make sure that the code adheres to style guidelines. Finally, after the senior developer has made sure that nothing has broken, they, or the junior developer, will then manually spin up a dyno, or deployment, for the client to review the different branch. For example, the branch may implement different colors on a logo, and the client has specifically requested they want to sign off on this new logo before it goes to production. Finally, after all this is done, the senior developer can get back to the branch they were working on and continue work. Now if this sounds like an error-prone and slow process, which wastes large amounts of the senior developer's time, you're absolutely right. The manual pull request review process is painful and slow, which is what makes automating them with Heroku so incredibly sweet. So if you're in a position where you're working, say, DevOps for a company and you're trying to explain to the senior individual why it makes sense to invest in Heroku, this is a really good reason. In the next video, we'll be enabling automatic reviews. Automatic reviews basically remove every step from this process except the first. So the developer pushes the branch with updates to the repo, makes a pull request and that's it, mission accomplished. But let's have a look at it in the next video. Enable Automatic Review of Pull Requests with Review Apps So in this video, we'll be implementing review apps in our Heroku account. So a review app is basically a one off application which is created automatically any time you make a pull request. This application is intended to be short-lived but is basically a fully functional application, just like the real dyno. Once the review app is created, it can be viewed by anyone who has access to the World Wide Web. All right, so here we are in Heroku. Before we can enable review apps, we have to add our application to a pipeline. A pipeline is basically a group of apps which work together in some way. Since having review apps necessitates having many apps, it makes sense and is required for us to have a pipeline for us to put them in. So let's create a new pipeline. And I'll just go with the default name. You can call your name what you want. Here in the pipeline view, we can see that our master branch has automatically been configured as the production branch for our app. On the left though, you can see that there's an option for review apps. If we enable them, new branches will automatically be turned into dynos once a pull request is created. Let's enable review apps now. It will tell us we need to create an app.json file for this to work. That's fine, so let's click create an app.json file. It will give us a boilerplate and we want to accept all the defaults and commit it to our repo. You may see an error in the corner, but I found despite this error, the creation of app.json works just fine. Now let's go back to deploy and visit our pipeline. Now we can enable review apps for real. Now we have a couple of options, and they're both valid so let's discuss them. The first option creates review apps automatically. So this is like taking the automatic deploy feature we added for a master branch and applying this to all our pull request. Since this has no chance of affecting your main dyno, there really is not too much risk to this, unless you're worried about the costs of your application development spiraling out of control. Let me just say that if you have developers working for you to the degree of sophistication where you actually need to review apps in some kind of automated process, the cost of your dynos is the least of your concerns. You're probably spending thousands and thousands of dollars on your development team and making them even a little bit more productive would surely save more money than any review apps would cost, but that's just my opinion to be fair. The second option, which I also think is good, will automatically destroy stale review apps after five days. Since most apps go to sleep if they're not used, stale review apps won't cost you money but they will lead to confusion when maintaining your pipeline. So I'll click this and enable. All right, so that works. Next I need to create a pull request for my repo. So here I am in my text editor working on my app. I'll open up my Bash and the first thing, I of course need to pull my changes from GitHub since I've created an app.json and made other changes. That's good. Now let's create a new branch. I'll say git checkout b and I'll call my branch test branch. Now let's make a change to the application. Here I'll make another change to messages json. I'll change the last one to CSS Workshop Today. And let's change the time of the build again to 11pm. Just like in real life, the build is always pushed back. Now I'll go back to my Bash. I'll add and commit the changes with git commit -a for add all modified files, -m for message. Give it a little message there. Now we'll push this branch up to GitHub. That looks good. Let's head back to GitHub. As you can see, GitHub has automatically taken note of our test branch. We can start a pull request just by clicking this here. So we'll create a pull request for these changes, just the changes to this file. Now carefully watch what happens when we do so. Interesting, we have a lot going on beyond the usual. Most interestingly, it says here danielstern requested a deployment to integration deploy just now. If I click this, it takes us to our pipelines page. This message tells me that in the time before I visited it, it was already able to deploy my review app. If I click View, you can see here is the review app. The URL is different, it has a pr-1 after it. If I want to see my original application, it is unchanged and still functional. Woah, well, that was pretty interesting. Now if the pull request closes for any reason, this branch will disappear shortly thereafter. And that's about all there is to it. If you've mastered these steps you're now ready to integrate GitHub with Heroku. GitHub Heroku Summary All right, it has been a very interesting chapter. Let's summarize the powerful advantages of integrating GitHub and Heroku. So as I've emphasized both with opinion and also with examples and facts, such as the manual review process, this integration is arguably the most useful that we'll discuss. It really does save time and prevent errors with every single pull request that you make. In a large project that may see thousands of pull requests in its lifetime, the time and money savings are just staggering. In addition, we learned that Heroku automates one of the most error-prone parts of the cycle. There are many challenges to deploying an application to the cloud, especially a NodeJS application. However, with its various pipelines and review apps, there are many fewer places wherein one can make a serious error and more assistance along the way to prevent doing so. We learned that our Heroku implementation also integrates with our Travis implementation in just one click. Doing so saves time and money by preventing dynos based on faulty or error-throwing code bases to be turned into real dynos, which are viewable from the Internet. In conclusion, I wish this module could've been as long as an entire course so that we could have spent more time talking about Heroku and all its amazing features. However, since we need to move on, in the next video, we'll talk about integrating GitHub with messageboard software, such as Trello. Automatically Creating Issues and Managing Repos with Discussion Board Software (Trello) Understanding Trello Welcome back. In this module, we're going to discuss integrating GitHub with discussion board software. The software we're going to be using in question is Trello, but the ideas in this course do apply to any other discussion board software which supports GitHub. So what is Trello and what can we learn from it and other discussion board softwares? Well, basically all discussion board softwares, at least in the context of a team, are designed to facilitate discussion between teams and clients. So if there's a big project being worked on, say a website, the team's going to want to be able to talk both with themselves and with clients in some sort of way that keeps records in a clean manner. Discussion board software is ubiquitous, whether we're talking about JIRA or Trello or Slack or any number of upstarts or competitors, almost every big team uses discussion boards. This is especially common in agile development, where each card in the discussion board will represent a card in an agile work cycle. And so by extension, almost all discussion board softwares can help manage an app's development over time. As an app gets older, there become hundreds or thousands of stories and issues that become archived. By keeping all the discussion regarding your app in one place, you can easily take a look back at its development and see what things you can learn. All in all, a discussion board is much more than just a forum or a place to put messages. It really is a tool that companies use to manage their entire projects. Discussion Board Software and Development So how would the use of discussion board software apply particularly in a development context? Firstly, the discussion board software could be used to manage a development of the project. For example, if there's a new job that needs to be done, say a login page needs to be added, a card can be created in a discussion board software to represent it, and then the person who has to do that can be assigned to the card. Then the person doing it and the person responsible for it can have discussions on the card relating to the development of that issue. If you compare this to simply telling your developer to do something and then hoping things work out and hoping, say, another developer doesn't do it as well, because they don't realize the first one is on it, it's clear that the assistance in managing development projects is very useful. Next the discussion board software can be used to track a project. How many issues have you been closing each week? Are you on track to reach your total number of issues to be closed by the end of the month? Has there been active discussion between developers and between clients? By holding all the records of your app's development in one place, you can easily check this out by simply looking at the archived cards and stories related to your application. Finally, when a story is complete, it doesn't mean that it has no further use. There's lots of historical information that we can gather from it. If the app is ultimately a failure, we can look at the archived stories and determine why forensically. In fact, stories can be archived for years. And at some point, if confusion happens, like, say, part of the app breaks or doesn't work as expected and people are trying to figure out who's responsible, the archived stories can tell the people interested what exactly happened. Overall, discussion boards are useful in a development context for much more than simply posting messages, and if used to their full advantage, can really help a development team out. How GitHub and Trello Work Together All right, so as I mentioned before, we're going to be using Trello for this course as it has some good GitHub integrations. But what integrations are there in particular? First, you can link a Trello story to an individual GitHub branch. So discussions relating to a branch, for example, if it should be merged or if a feature should be included in, can happen on a discussion board, but linked directly back to that branch. When the branch is merged or committed, the card will update automatically to indicate that for interested parties. Pull requests can also be turned into cards. This allows senior developers and clients to have a discussion on whether the pull request makes sense or not outside of the limited GitHub context. Individual commits can be put to cards. This allows discussions relating to individual granular changes at the commit level to take place and for developers to determine if those commits make sense or not. Finally, issues can be linked to Trello. Now, since an issue already is a lot like a Trello card, you might wonder why this is useful. Well, the simple answer is at the end of the day, your clients may not be comfortable going on GitHub. GitHub is a fairly technical environment, and non-technical clients may feel intimidated by it. So by bringing your issues and all your other discussion to Trello, it's much easier to communicate with non-technical clients while still maintaining an accurate record of what's happening. How Can Discussion Board Software be Integrated with GitHub? All right, so we've mentioned that issues, commits, pull requests, these can all be linked on Trello from GitHub. But what does this link exactly entail? Well, first, it creates a direct link between the code changes that happen in GitHub and the discussion surrounding those code changes. For example, there might be an issue related to a commit that was merged sometime ago, and someone might be commenting on the card, which is the issue that they don't think the commit made sense or that there might be a potential problem. In the future, if it's determined that the commit was problematic, the card can serve as an incontrovertible record of the discussion that took place. Next, as messages automatically appear on any linked card saying, for example, if a branch or pull request is merged, there's no question as to what state the application is in. So rather than having to send an email to someone or go and talk to them, you can just tell on the Trello card if the work has been integrated or not. Finally, by looping back to a previous integration with Heroku, we can use review branches to post the links right inside the Trello card to where the client can view the application. All in all, this makes for a pretty close integration and a much improved workflow. Note on Trello Business Class All right, so in the coming videos, we're going to be doing a demonstration of the matters discussed. Now, unfortunately, to use the GitHub integration, you need to have Trello Business Class. And Trello Business Class does cost money. Naturally, this was not my first choice, but Trello does have the best GitHub integration, so I really wanted to show you. At a price of only about $10 a month, Trello business class really does make sense for large teams. Teams need discussion board software, and Trello is as good as any of the others. So to complete the next chapters, you're going to need to purchase at least a month of Trello Business Class. It's not too expensive, but if you're not interested, you can always skip to the next chapter, which won't deal with Trello, and which you won't need to purchase any additional logins to use. You can also just watch my demonstration as everything will be demonstrated for your benefit on the screen. So if you're uninterested in getting Trello Business Class, please either skip ahead or just watch the rest of the course without working along. Connecting GitHub and Trello - Demo In this video, we're going to demonstrate the simple process of connecting GitHub to an eligible Trello account. So Trello boards can have a link to a single or multiple repositories. You're not limited to just one. And pretty much all the setup happens via single click integrations, just like our Heroku integrations and integrations before that. As we'll observe in a later video, branches, pull requests, issues, and more can all be connected to any card that we create. All right, so here I am in Trello. I have my business class account, and I've applied it to a team I'm calling Integration Test Team. Now, let's create a new board. I'll call it Integrate with GitHub Demo Board. All right, so now my board is created. Now on the right, you'll notice I have this Power-Ups option, which is not available in regular Trello accounts. If I click it, it gives me this big list of cool features, some sophisticated and some not. In this case, we're interested in the GitHub integration, so we'll click Enable on this. If we click the settings cog next to it, we can edit the settings or remove them. Here we're given the option to add repos to the GitHub repository. We know which repo we're going to want to use, so let's go ahead and add a repo. After a little while, a list of your repos will come up. I have a lot of repos, so I guess that's why it took a while. I'll just click integration-test-repo-demo. Now you can see it's been linked in the top right. Also note that I've selected an option which will also update GitHub whenever anything has changed here on Trello. This will lead to two-way feedback, which will allow anyone viewing any of the channels to figure out what's going on. So now if I add a new list, and I'll call this Issues with Browsers, and I'll add an issue. I'll say Firefox 12 Not Working. Now, on the right of the card, you can see a dropdown for GitHub showing Attach Branch, Attach Commit, Attach Issue, and Attach Pull Request. In the next video, we'll be doing so, so be sure to stick around if this is something that you think might be interesting. Advantages to Trello Integration Now, if you're trying to decide whether integrating a pull request with a Trello story really does make sense, consider the following ideas. So the connection between a PR and the story or the discussion surrounding it is extremely clear. If a client comments on a Trello card saying, yes, this looks good, please do this, and it's linked directly to a pull request with, say, even a review branch that allows you to review the thing itself, there's a lot more wiggling room regarding any possible confusion that can happen. And any errors that are made will likely not reflect badly on you, because of the clear link between the client approval and the commits in question. In addition, Travis CI will also integrate into our Trello and let us know whether the PR is passing tests. As mentioned before, by adding the link to our Heroku review app, we can now have Trello, Travis, and Heroku all linked with our GitHub working together. And lastly, if a pull request is merged but no updates are made to the story itself, the story will update automatically, and it will be easy for the client to see what changes have occurred. All in all, there are numerous advantages to integrating pull requests with Trello, and we're going to have a look at those in the following video. Integrating A Pull Request with Trello - Demo All right, in this video demonstration, we're going to integrate a pull request with a Trello story. We'll use the built-in integration and then see the CI status that is updated. It shouldn't take long, so let's jump right into it. So here I am in my linked Trello board. If I have a look at my GitHub repo, you can see I already have a pull request open, the one from our previous chapter, improving the default messages. This should be fine. So let's go back here. I'll open up this and I'll attach a pull request. It sees my app and sees I only have one plausible pull request to use, so it suggests this one. I'll click it. And there you go, a link appears. So let's have a look at what's changed. First, we receive a green 2/2 OK message from our Travis CI. I'm not sure why that's two out of two instead of one out of one, but my guess is it might also be checking the Heroku integration. Here it shows a link to the pull request. If I click it, we go right there. And here on the board, it links back to Trello. The pull request is merged, and my card is updated to indicate that the pull request has been merged. So anyone viewing this card would realize, oh hey, the pull request is complete. This code must really be in the main code archive. And that's about it. Now, integration between branches, commits are very similar to integrating with pull request. With issues, things are a little bit different since issues don't actually contain any code within themselves. But trust me, if you understood that last video, then you're definitely ready for anything Trello-GitHub integrations can throw at you. This tool really is ideal for a project manager or someone in a DevOps position trying to get their team's efficiency to the absolute maximum. Additional Trello-GitHub Integration Demonstration In this video, we're going to explore the remaining Trello-GitHub integrations. We're going to take a look at integrating with a branch, with a commit, and with an issue. First, let's do branches. So in my browser here, I have my Trello board and my GitHub repo open. So I'll go to my repo, and if I click on Branch, as you can see, I have a few branches here, a branch for my current progress as well as a branch for the application when it's finished. Now, if you only have one branch on your GitHub repo, go ahead and create a new one and push it to your GitHub repository. Once you have at least one other branch on your GitHub, go to your Trello board and create a card. So I'll create a new card, and I'll call it Integrate a Branch with Trello. Then I'll open it up and, as usual, go to GitHub. And now I can attach a branch. If I click this, it will show me a list of all my branches. There's a few more here since I have this connected to a forked repository of the same files, where I've done a bit more work. So I'll just select the test branch. Once I have the branch selected, it shows up in this section here under GitHub Branches. I can have multiple branches connected, so I can go to GitHub, Attach Branch, and add an additional branch. As you can see, it provides a link to the branch. As well, it provides who the latest committer is on the branch, and what the message is for that commit. Next, let's do commits. I'll make a new card, and I'll call it Integrate a Commit with Trello. Now I'll go to GitHub. We don't have to make any special preparation since we have lots of commits already. I'll choose Attach Commit and it gives me a list of the possible commits I can choose to integrate. I'll choose rename travis yml. And it shows me a list to the commit. If I click it, it takes me here. So a commit can refer to very granular changes between one version to the next. Finally, let's do an issue. I'll go over to my repo, and I'll go to Issues. And now I'll create a new issue. I'll just call it Thanks for the great app. And I'll submit the issue. Now with at least one issue in our repo, I'll go back to the Trello board. I'll create a new card called Integrate an Issue with Trello. Now, I'll go to Power-Ups, GitHub, and choose Attach Issue. It'll give me a list of my issues, and I'll just choose the first issue that appears. The name of the issue isn't the exact same, because, again, I have this connected to a forked repo. But everything in this demonstration still applies. As you can see, it provides detailed information about the GitHub issue. It provides the name of the issue as well as any tags that have been applied, in this case, the help wanted tag. It shows who opened it and how many comments there are as well as what its status is. And those have been three more ways to integrate GitHub with Trello. Trello Github Review All right, it's been quite a chapter. Let's review what we learned. So we learned that Trello cards can be linked to issues, commits, pull requests, or branches. The same likely holds true for any similar softwares as well. Anything that conceptually can have a discussion related to it should probably be able to be integrated with discussion board software. We also saw how the card will update automatically when a pull request is merged. We can expect this kind of automatic behavior from many different features of Trello. Finally, we saw that given its cost, Business Class Trello was a bit less accessible than other tools, however, it is very useful for facilitating discussions with clients as it is front-facing and non-technical. All in all, our Trello integration is the least technical so far, and by no means the least valuable. Any team that is large and working together on a project can surely benefit from this integration. In the following video, we're going to ask the questions, what if you want to do an integration that hasn't even been conceived of yet? How can you make your own? The answer is webhooks. Integrating Custom Node.js Webhooks with GitHub What Are Webhooks? In this chapter, Integrating Custom Node.js Webhooks with GitHub, we'll actually write our own webhook that we're going to use to interact with our repository. All of the integrations we've viewed so far, Heroku, Travis, those have all used webhooks under the scenes to actually make what they do happen. And now we're going to do that ourselves with GitHub. So, what is a webhook? Webhooks are actually fairly simple things. Now basically when a webhook is used the transmission of some form of structured data, be it JSON or XML, happens to a specific URL. The URL contains a custom listener script. This script is listening for the webhook to call it. When the script is called by the webhook, or the transmission of JSON data, then custom code that you've written can occur. The whole idea is similar to the event callback architecture seen in JavaScript, where a callback is passed to a function and only executed when the function calls that callback at the end of its functioning. Webhooks and GitHub Explained Let's look at the low level functionality of webhooks in GitHub. This will help us understand the demo, which is coming up in the next video. So basically whenever you do anything to your GitHub repository, make a pull request, make a new branch, push something, GitHub can be configured to send a post-request to any URL. The URL can be a Heroku application which you have listening or even your local machine. So the data that GitHub sends is just a whole ton of stuff about the repository. When it was last pushed, the changes that have been made, the current version, basically anything that you could possibly want to know for any integration. Then the author of this script can run any code they wish in response to this data. So for example, the script could listen for if the payload had the information that a new pull request was made. And if that was so, it could send an email to one of the administrators, or do some other automated task. The hallmark of webhooks is their flexibility. They can really be programmed to do anything that the business needs require. Creating a Simple Webhook in Node.js In this video we will create a fully functional but simple webhook using Node. So the webhook itself is basically a post-listener. So using Express in the standard manner we will listen for a post-request to the URL. We're going to deploy our webhook to the internet using the same Heroku integration we've already set up. This means our webhook will be online with no extra steps at all. The webhook isn't going to be too complicated. It's just going to output whatever the payload sends it to the log. But this kind of functionality can be easily built on in the future if there's more specific functionality that you want. Here I am inside my text editor. First let's create a new file to hold this webhook functionality. It's not totally necessary to have a single file for the webhook, but this will help us keep track of what's going on. So, I'll make a new file, and I'll just call that webhook.js. We'll start with a use strict statement at the top. Then we'll make the module exports equal to a function. And the function is going to take one argument, the app or the Express application. So we're going to pass the Express application to this and this is going to do some changes on the application. In this case it's going to add a new post route. So we'll say app is passed to it as an argument. Then we'll say app.post. And the path we want to listen to is just /webhook. So whenever /webhook is called the following script will run. We'll make a function with two arguments, req and res. And this will be really simple. We'll just say console log and then we'll just log a message like activate webhook. Then we will log the body of the request object. Finally we'll send a 200 status to whoever is sending a request to the webhook, in this case GitHub. Finally, I'll need to integrate this webhook with the rest of my application. So, I'll go to main.js. And then at the very bottom I'll say require. I'll require my webhook.js. And remember this is a function, so I'll invoke the function and pass app to it. Finally, back in webhook.js let's just add a log to say the webhook is running. Now if I run npm start. And as you can see, our webhook is running. Finally, let's merge this into our master branch and push it to our GitHub. As you'll recall, this will cause our changes to automatically be deployed to Heroku. So let's add and commit all our changes. First I'll do a git pull to grab any changed files from the repository. Then I'll do a git push to push my changes up to GitHub. And that's looking good. In the next video we'll test our webhook using GitHub. Enabling Webhooks Now it is time to enable our webhook. Webhooks are added to GitHub via the Settings Page. They're added manually with a point and click interface. And when we're there you'll notice that there are already some webhooks that have been created by other integrations like Heroku, and we should not touch those webhooks, since those will break our other applications if we do. So here I am at my GitHub page. In the repository for this course. Now I'll go to Settings. Then here I'll go to Webhooks and Services. First you'll notice that the webhook for Heroku is already there. This is what lets our Heroku app update automatically when we push or create a new branch, et cetera. Services are similar but they come pre-integrated into GitHub. Here at the top right you can see there's an option to Add a Webhook. That's what we want, so let's do that. So first we'll need the URL for our webhook. So to get our URL we'll visit Heroku. You'll notice here it says that my new change was deployed three minutes ago. That's good since that means my webhook is now running. I'll open the app, and as you'll recall the correct URL is this /webhook. So for your app it's going to be different than this one, since we're all going to have a different Heroku URL. So copy that and then go back to GitHub. And we'll just copy and paste that Payload URL here. We'll leave the Token by default and we'll say send me everything. Actually, before we do that, let's click Let me select individual events. This will let you see all the possible events that could be called by your webhook listener. By default only push is selected, but there's events for a new member, a new release, a status change, a watch, even the most granular change is available here. So once you've gotten more advanced with webhooks, you can select the individual events. But for now, sending us everything will ensure we can test our application quickly. And you want to make sure it's active, and then we'll add the webhook. Remember to ensure that your GitHub repository is up to date please add and commit any changes you have and push them to GitHub. And it's taken a little while, but here's our first successful delivery of the package. You can see this check mark means that this has been delivered correctly. And the response 200 is as we expected. Let's redeliver the message. And back in Heroku here's the output of our webhook. As you can see there's tons of information that GitHub has sent over. Now if it doesn't work right away, it can take five or 10 minutes for your Heroku repository to update. In production you can use any of these pieces of information to run custom scripts. For example, in the information that's visible up here it says who is the person who pushed this latest change? For example, it was myself. But, in a big project, you could have it send an email to you notifying you which particular developer made the change and respond accordingly. Well, that's how you deploy a webhook. In the next few videos we'll wrap up this chapter. Webhook Applications Now that we've seen webhooks in action, how can you apply this new knowledge? Well, first of all webhooks are essential for any GitHub integrations. As we saw, Heroku had already created a webhook to allow it to function. So if you ever want to create a GitHub integration as its own project you'll need to use webhooks. So you can write a webhook that triggers a pull request, so if you're running a local version of your application, every time the webhook runs you can pull your code from the central Git repository. Additionally, if you have something in your office, like a buzzer or a bell, or something to indicate some real-world event happening, you can use webhook to do that. And finally for any application where you want to work in granular detail with the repository every time something changes, probably a webhook is the best tool for this goal. Webhooks Summary Let's end by summarizing this chapter on webhooks. So webhooks are pretty much useful for anything for which a third party integration doesn't already exist. You're probably not going to want to use a webhook to do all the services that Travis does when Travis already has this taken care of. But if there's something that hasn't been thought of yet, then webhooks are your tool for doing it. Webhooks are the most low level tool you have for integrating your development team with GitHub. For enterprise integrations that an in-house team is building for teams of dozens or hundreds of developers these make a lot of sense, and it gives you all the control to do anything you can possibly imagine without any limitations. Finally, when you're working on any project where you need to work really closely with GitHub, not just you know, uploading stuff with GitHub, but work really closely with GitHub, like know everything that's going on every second, then webhooks are once again very useful, since a webhook is launched any time something changes on the repository. Well, that's it for webhooks. In the next video, we'll conclude this series of modules. Conclusion GitHub Integrations in Review Alright, let's wrap up this course. Making this course has been really exciting for me, since all the GitHub Integration we've worked with are just so practical. Almost all integrations, including all the ones we've covered have tons of real business applications. So to contrast with some other talks, that are mostly theory, this course is something that you can definitely apply right away to streamlining your business goals and projects. So let's review the Integrations, that we had a look at very quickly. First, there's Travis and Travis runs our tests and integrates with other softwares, so for example, when we also used Heroku, Heroku integrated itself automatically with Travis to not deploy anything, if there were errors in the build. Travis is the cornerstone of any integration and you'll find it integrated with almost every GitHub application, which is serious on an enterprise level. Next Heroku deploys our applications, so we have our application, which runs on our local Node server, but it's complicated to deploy something like that to the internet, so not only can Heroku deploy those things, but it can integrate directly with our GitHub to do it automatically. It also lets us review our pull requests, without ever affecting our production application. Next Trello allows us to discuss all of this, Travis and Heroku in an environment that's linked with GitHub, so nodes of branches and pull requests can appear automatically and be updated in real time right on a Trello card. Integrations like this increase organization and add confidence to clients. Finally we learned about Webhooks. Webhooks, which can be used for nearly any purpose, are easy to write and can be implemented in just a few minutes, however they provide lots of granular, low-level control and they're not recommended, if there's already something which will do that for you. Continued Learning Now that you've completed this course, it's about time to go and integrate all your GitHub repositories with many different integrations. First however, let's review some resources that you can refer to in your continued learning of this topic. So here I am at the documentation for Travis at docs.travis-ci.com, so Travis has a lot of docs, they're very thorough about their documentation. They have a Getting started section specifically for JavaScript and in addition, they have references to many different aspects of their API. There's a lot to read here, so if you find it interesting, I do recommend that you just read it for fun, but otherwise you'll want to refer to this if there's a particular Travis issue, that was not covered in this course. Next, you're not going to want to miss out on the Heroku Documentation and Dev Center. Here I am at devcenter.heroku.com, this provides access to a reference to all of Heroku's API. In addition, it provides you with community assistance to help solve any particular issues, which are too challenging to solve on your own. If we click here on the reference, you can see there's a huge library of articles, that we can read to increase our Heroku knowledge. Next, no discussion of continued learning is complete without Node Weekly. Here I am for the website for nodeweekly.com. Node Weekly is a weekly publication, that you can have sent to your email by entering your email address in the list. Every week, they provide lots of information about Node.js. If we check out the sample issue, we can see that there's numerous articles relating to Node and relating to integrations, in fact there's even a sponsored ad by Heroku right here in the middle, which means that Heroku is watching this publication too. So you'll often find stuff in here relating to GitHub or Heroku. I'll say go ahead and subscribe and remember to read every week's articles. Finally, for more video, you can check out the JSConf YouTube Channel and here I am at the webpage for JSConf, the main JSConf is jsconfeu or JSConf Europe. I really like these talks, because they get professional developers from serious companies to come and do talks, that are about half an hour long absolutely free. These talks are not necessarily better, than a specific focused video series on a website like this, but they do provide a lot of variety and these people who are talking, though they have a limited amount of time are often the most knowledgeable in the particular area they're talking about that exists. Often they'll talk about topics which relate to what we discussed, for example, here's Hannes Diercks talking about frontend testing, we know that if we integrate frontend testing with our application, we're also going to want to hook that into Travis and Heroku, so it's all done automatically, so I do very much recommend you subscribe to this channel and try to watch one video a day. If you can watch the entire back catalog of videos, there's no questions that even if you're not a total JavaScript wizard, you'll be able to participate intelligently in any workplace discussion relating to JavaScript or its business applications. Thank You Alright, well, we've gotten to the end of this course and I just wanted to take a minute to say thank you for completing this course. A lot of times, people begin things, but they don't complete them and challenging courses like this one are top of the list, so by virtue of the fact that you made it to this last video and I assume that you've watched all the preceding videos, I know that you have the determination to learn about any JavaScript or Node.js methodology, which interest you. I do advise you to watch more courses here on Pluralsight, including my own, if you found my teaching style engaging and interesting. I've been Daniel Stern, have a good day. Course author Daniel Stern Daniel Stern is a freelance web developer from Toronto, Ontario who specializes in Angular, ES6, TypeScript and React. His work has been featured in CSS Weekly, JavaScript Weekly and at Full Stack... Course info LevelBeginner Rating (27) My rating Duration1h 43m Released5 Aug 2016 Share course