Integrating Node Applications with

GitHub
With the pace of development on the internet increasing each year, developers need a
way to manage NodeJS applications that will keep them ahead of the pack. This course,
Integrating Node Applications with GitHub, will help you not only learn a variety of skills
that will help in any workplace that uses GitHub, but many advanced techniques that can
be used to deploy your own applications, or contribute outstandingly to your place of
business. You'll learn how to integrate your GitHub projects with Travis CI, which will let
you know well in advance if there are any errors, and can be integrated with other
applications to allow for error-free deploys. Next, you'll learn to deploy your NodeJS
application using Heroku. Deployment of Node applications can be extremely
challenging, but this course makes it simple and easy enough to be accomplished in a
few short videos. Lastly, you'll learn how to set GitHub up with Trello, which facilitates
professional discussion between workers and clients. After completing this course, you'll
be ready to interact with GitHub projects in the workplace and independently much
more effectively.

1 Course Overview
1.1 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.
2 Integrating NodeJS Applications with GitHub
2.1 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.

2.2 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.
2.3 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.

2.4 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.

2.5 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.

3 Integrating Node Applications with Travis CI

and GitHub
3.1 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.

3.2 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.

3.3 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.

3.4 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.

3.5 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.

3.6 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.

3.7 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.

3.8 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.

3.9 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.

4 Deploying GitHub Branches Automatically

with Cloud-based Deployment Software
(Heroku)
4.1 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.

4.2 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.
4.3 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.

4.4 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.

4.5 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.

4.6 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.

4.7 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.

4.8 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.

4.9 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.

4.10 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.

5 Automatically Creating Issues and Managing

Repos with Discussion Board Software (Trello)
5.1 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.

5.2 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.

5.3 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.
5.4 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.

5.5 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.

5.6 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.

5.7 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.

5.8 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.

5.9 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.
5.10 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.

6 Integrating Custom Node.js Webhooks with

GitHub
6.1 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.

6.2 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.

6.3 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.

6.4 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.

6.5 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.

6.6 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.

7 Conclusion
7.1 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.

7.2 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.

7.3 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.