Okay. So at this point, if we look at our travis.yml file, we should see a new section there under the deploy section called api_key that's the key value, and then an encrypted section for our key that we stored from Heroku into the travis.yml file. Travis will be able to decrypt this string because we were logged in to the Travis back-end when it was encrypted and that's the private keys that were used, to encrypt this credential. So next is to configure our deployments section with some additional select our options. For that, we're going to want to go to the Atom IDE, and reload this travis.yml file by double-clicking on the travis.yml file again and we should see a new section there. Now, we don't necessarily deploy when we submit a pull request, what we want do is make sure that whenever we submit a pull request and then we merge it into a branch, that the branch is the merged version of the branch is what gets deployed. So for that, you can use the on keyword in the deployment section, and then we can select a branch that we're going to deploy to. Now, that could have been master but for us, we will use a branch name called heroku_production. What's important here is if we go back to the GitHub website, and we create a branch name with that value on our repository. So if we go back to github.com, navigate to your repository, for the Probot Hello app, and then click on the branch name, and in this field where it says find or create a branch in the background, paste in your branch name and click on the create branch option. So that gives us a deployment target for our branch to be able to merge it into so that whenever some new changes merged in for our code, our code is deployed automatically to that branch into the Heroku app. So, if we go back to the Atom IDE, we're also going to want to specify what the app name in on Heroku. So let's choose the keyword app, and then the value for this is determined by what you called the Heroku app on your Heroku dashboard. So if you go back to dashboard at heroku.com, and click on the Heroku navigation icon and look for your app. Then, you'll find the Heroku app name right there, and you can copy this, and then go back to your Atom IDE, and then paste that in, oops looks like we got some extra texts there. We can delete that. So let's save those changes, and at this point we're ready to submit these changes to GitHub as a pull request. So let's go back to the GitHub desktop, and we should see all our changes that we've been making here. Let's give the commit a name or a title. So this will be our Heroku Demo, and we can give it a description. I'll commit these changes now, and then click on the publish branch button, and that'll upload your changes to github.com onto the heroku_deployed branch. So at this point, you should be able to go back to your github.com repository. Click on your repository. If you don't see an automatic create pull request button that's okay. Just click on the pull request. Tab here, click on new pull requests. In the base fork make sure you select your local branch, because we're going to be merging this to our local branch not the remote branch that we base this repository of. So let's choose our local branch. So that's great, and we should be pointing to our user account and then our repository, and we're going to merge this to the heroku_production branch. In the branch that we pushed up is called the heroku_deploy branch. So we'll base our pull requests of emerge from heroku_deploy to heroku_production. So let's create the pull requests, and you can leave the title just as it is, and click create pull requests. So at this point, the Travis system should be triggering a build for your pull requests. You should be able to see the files that have been changed your travis.yml should be in there, along with the configuration section for the heroku.provider in their Travis file, with our encrypted secrets. So the important part here is that now you have secrets set are stored in your source code configuration management system that are not going to be usable by anybody who sees your project unless they are creating new secrets to encrypt new secrets. So this is usually just a one way encrypt with the Travis CLI. There's no decrypt option there. Then you'll see the other files that are associated with this pull requests that were based on, the master_docker branch. So these are changes that are coming from the master_docker branch. But they should look a little bit like this, and that should prepare this pull requests to give you a few shippable Probot app, as a GitHub application to Heroku. So at this point, let's check out what's going on with our Travis build, so click on the details there. That takes uses it checks API pane of the Heroku deployment pull requests, scroll down to the bottom, and click on view more details on Travis, and that'll open up our project to the Travis builds. So this is currently building. Now, the pull request won't actually deploy the Heroku application, and you should skip the build and we'll look at that when this pull request is finished. But what's important here is under more options, if you click on settings for this particular Travis build is that, the Build pushed branches feature is turned on. What this does is that, when we merge our change for this pull request, then the heroku_production branch will automatically build and deploy for this particular repository. Now, if you don't want this option turned on, you can actually do manual deployments in the way that you do that is under more options, you click on the trigger build option, and then you select the heroku_production branch, and then you can trigger a custom-built. What that will do is automatically deploy the heroku_production branch for your particular change to your Heroku app. Okay. This build is finished and just like we expected the Heroku provider did not deploy the pull requests because well this is a pull request. It's not a branch merge, and it wasn't the heroku_production branch either. So at this point let's go ahead and merge our changes. So let's go to the pull request, and that should be available on your repository on the pull requests section, click on heroku deploy, and then make sure you have green checks here for your test cases that past, and click on the merge pull request button. So at this point if we go back to Travis, and we click on our repository, and click on branches, we'll see that there's a heroku production branch that's being built. Click on the first block that's in yellow, and then let's take a look at the job log and see how that deployment is going, with our secret. So if the successful Travis will have decrypted are secret and use that API token to access the Heroku back-end, and deploy our application. So let's wait for this job blog to finish, and then take a look at that. Okay. It looks like our build is complete. It exited with a zero. That means, everything was deployed and we can see here that, there's now a new application deployed to Heroku account under this particular URL. So we'll go copy that, and take a look at it later. But let's look at the log and see what happened here. So when we reached the deployment section, because this was the heroku_production branch, and our configuration follow matched that, it began deploying the dependencies to prepare for the deployment, and then it executed the deployment. Now what's important here is that we don't see any authentication errors, which means that the Heroku provider was able to decrypt those secrets, and use the API token to communicate with our Heroku account, and then begin to deployment by attaching itself to the Heroku back-end system, and selecting the correct binaries for our node application through the package.json specification, and the MPM specification and then, deploying our application fully and getting it up and running. So let's see what we got. If I paste in that URL, we see a working probot app. So this is excellent. Okay. So let's take a look at what it takes to install this application. So we call that the Heroku Probot WenlockCA application. So we should be able to navigate to our user account. Click on settings. Go down to developers settings, find our app under GitHub apps, and there it is again, click on the Edit button. Under install app, we should see our user account. So we should be able to hit the Install button, and then select any other repositories. We can do both repository or one repository, or we can do all the repositories, so let's do all repositories, and then we'll see what access we give it rewrite access to issues. Reinstall that, and so now this application is listening to events through GitHub for our particular repositories on our user account. So if we go to your repositories, and we click on our Probot app, and if we don't have issues enabled we can enable issues by going to the settings option, and choosing the issues checkbox right here. Now looks good. Okay, and then we have issues. So let's create a new issue that tests this out. Verify our app work, submit. We'll refresh this page, and there it is. Thanks for opening up an issue. It worked. Okay. So let's recap what we did. We moved our application from Glitch to Heroku, and in order to move to Heroku we needed to make sure that we had encrypted secrets. The encrypted secret that we chose to encrypt was the API token. The API token on Heroku, is used for deployments and there was this section in our Travis file that we could configure for the deployment of our application to Heroku. Travis made that very easy for us to do. We use the Travis encrypt command to encrypt that API token from Heroku, and then we published our changes as a source code configuration change in our travis.yml file to our repository. Now, the travis.yml file now contains the secret. However, it's in an encrypted format. The only way for us to change that secret, is to regenerate that secret with the Travis encrypt command. Securing the secret in our source code of configuration system gives us a single point for where we can manage the secrets for our project, and it also gives us the ability to maintain some ownership over the encryption process for our particular secret. So outside of that, we did some work here on deployments to see how we can integrate the web apps application for probot with Heroku, and run our application and see that it was fully functional. So I hope you enjoyed that and you come up with other experiments and secrets that you might encrypting your travis.yml for the future.
