Hi. Today, I'm going to introduce you to some methods for how to store secrets within Travis CI project. So just as a reminder, we did in a previous lesson a deployment of the probot application, the sample application to Glitch. Today, instead we're going to focus on deploying our application to Heroku using the Travis CI system. Now, it's going to be a little bit more simple than the last time. Instead, we're going to be using some of the features in Travis to set up our environment. Just like before, you can follow along with some instructions on github.com/probot to basically understand some of the higher level or detailed steps that we're following. So if you go back to the ucdavis.org organization under github.com/ucdavis, and you find the sample repository called WEB1066-probot-hello, and you make sure that you have that forked to one of your repositories. I already have it forked to my own user account. From here, we can basically download and clone the repository, so that we can open it up and interact with it locally. So remember, you'll need the GitHub desktop and you'll also need IDE editor. If we click on clone or download and then click on open in desktop, and allow the browser to open up the project, and then clone the repository using the GitHub desktop, then we should be where we need to be at. The default project actually comes with a branch called master_docker. If we select that branch, then we can base our new branch from this branch for this exercise. So the last time that we published our application on Glitch, Glitch allowed us to interactively work with a publishing mechanism that allowed us to make the probot application available on the Internet and allowed us to test publishing manually to Glitch. However, if you're using Glitch for continuous integration, that might be a little bit more difficult because Glitch doesn't provide some command line arguments for us to do things such as automatically publish our application when we want to publish it without a user interaction. So for this exercise, the way that we're going to set up our account on Heroku is to basically navigate with our browser to heroku.com. If you haven't set up an account on Heroku before, setting up an account is very easy. You basically open your web browser, you click on sign up and the Heroku interface will have some fields that you can fill in. So you're going to want to fill in your information that will set up your Heroku account, and I'm going to fill in my information with the same information that I use to set up my GitHub account, and that'll make it easier for us to interact with our Heroku account in GitHub, so just finish filling in this form. Make sure that you verify your email address by going to your email and confirming that that's your accurate email address. Once you have your email address verified, then fill in the form with a user ID and password that you can save, and then click here to proceed to Heroku. Getting started with a probot app on Heroku is very easy. All you have to do is start by clicking create new app. Then let's name the app, it has to be something that's unique. For us I can use probot and then we can use our username. So if your username is like mine, it's very short and your app should be probot dash your username. Click the create app option. Then from here, everything else should just be left as is and we'll be making some configuration changes. Configure your probot app to talk with your source code repository. So in settings, there is a section here that you'll want to capture your URL for your application. So for my application, the URL is https://probot-wenlockca.herokuapp.com, and that will be information that we use to set up in the GitHub app. So just as a reminder creating the GitHub app, you can find documentation for that on github.com/probot on the repository probot and there's some information there under docs/deployment.md, and we'll be following these steps to basically reconfigure our GitHub app to work for Heroku instead of Glitch. So if you haven't created a GitHub app before, all you need to do is go to your user account. Click on Settings. Click on Developer Settings, and then click on GitHub apps. Click on new GitHub app. We will call this our Heroku Probot, and then you can use your username. Then for the homepage URL, if we navigate back to the Heroku interface, we're going to reuse this URL for the app. So we can use that URL and make the callback URL the same. So make sure that the homepage URL is filled in, the authorization callback URL is filled in, and Webhook URL is filled in. We will fill in the secrets later on. Let's just double-check to make sure our issues are enabled. Yeah, we lost that. We'll reset that. It's not resubscribing to events. So let's turn on subscription to events, and then create the app. Okay. So we have a successful app. Now, there's some information here that we're going to need for later on, in particular the ID, and we'll need a private key. So let's generate that private key by clicking the generate private key. That goes down into your downloads folder, and we'll use that later on for this particular probot app. All right. Let's open the GitHub desktop and we still have the WEB1066-probot-hello app branch. Let's choose the branch under current branch, and we'll start a new branch. So if we click on the new branch button, we will base our new branch off the master_docker build, so that we have a Docker build for our application, and we'll call this heroku_deploy. That'll be our Heroku deploy branch. So create a new branch. So we're going to open up our Heroku deploy branch in Atom. So choose repository, open an Atom, and that should bring the project into the Atom IDE. We can close these sub-panes, since we won't need them, and in the route repository we should have a Docker file. Let's begin a new travis.yml file. Specify new file. That should give us an empty file. In this file, we can save that file as our travis.yml. So hit File Save, and we'll specify.travis.yml, Y-M-L,.travis.yml. We'll use that and then specify some of the commands that we're going to use to build this. We'll use sudo require, we'll have a services setup for Docker, then before _install, the command we'll be using here is docker pull node:8-onbuild. Actually, let's verify that, that's the correct image. So the base image that we use is based on our Docker files in the FROM statement. So that looks good. Then in the install section, we'll have a command to docker build -t probot-hello., that builds the current image. In the script section, we'll have two commands, docker run --rm probot-hello npm run test. So that runs our test cases, and we'll also have a docker run --rm probot-hello again and npm run lint. That's the lint checks for our script. Now, in order for us to do the deployment, we'll need a deployment section in our probot app or in our travis.yml configuration file. So that looks a little bit like this, deploy and our provider will be Heroku. Now, on the Travis website, there's plenty of documentation that describes deploy section. If we open a new browser and we go to travis-ci.com, and we click on the docs section, we can read all about the deployment documentation. So under deployments and uploads, these are all the providers that are available to us. We're using the Heroku deployment option. What's important here is that we're going to be securing our secret with an API key and a secure encrypted key. Now, there's other options here that might be useful for you later on to control when you do the deployments such as being able to select when you deploy based on a master branch or some other key that you might want to trigger your deployment on. Now, before we go on to configuring our secret, it's important to understand why it is that we want to configure our secrets this way and how it is different than how we've done previous secret configuration. In the past when we had a project, we would have a setting for our project and we would configure an environment variable with the user ID or some key value, and then a value here for the secret that we wanted to provide. However, sometimes when you have sensitive information that you don't want to share with a third party provider, in this case Travis, and you want to secure that information on your local system, then doing a secrets management and encrypting those secrets locally can offer you that ability to save that configuration within a source code repository, and then let the encryption systems with the private keys, unencrypt those secrets when you're uploading them, and have those stored in an encrypted fashion without having to, in the clear, provide those secrets. The other advantage is Travis will automatically redact information for you in log files whenever it encounters the secret, so that if you're sharing your project in an open-source community or something of that nature, then your secrets won't be exposed as well.