Continuous Integration Workflow

3.3 Heroku Deployment

Hi. Welcome back to continuous integration workflow. In this lesson, we're going to deploy our application to heroku, using Codeship's deployment feature. Before you can get started, you need the heroku toolbelt. It comes as an installer for your operating system, and is needed to interact with the heroku and the shell. Once you have installed it, you can login using the heroku login command. You will then be asked for your email address and password. After logging in, you can create your app of the heroku create command. When you don’t use any arguments, it will choose a name for you. If you run the command in your project folder, it will configure the project so that further interactions with heroku are automatically using the app you've just created. Now, we need a database. Heroku has a vast number of plugins. One of them, a postgreSQL database. We'll be using the hobby-dev version, because it's free and suits our needs. Add it to your heroku app by running heroku addons: create heroku-postgresql:hobby-dev. There is one last change to make our rails app work well with heroku. We need to add the 12-factor gem to our gem file. It is used to configure logging, and static asset serving. After adding it, run the bundled command to install it. Now we can commit our changes. But hold on, before you push it to the servers, we need to set up Codeship to deploy to heroku first. In the web interface, go to the deployment settings. Create deployment for a new branch, master. Then we can choose a variety of options that Codeship supports with a nice interface. If your service isn't listed, you can always use a custom ShareScript to deploy your code. To deploy it to heroku, we need to have two things. The application name, and our API key. To get the name we can, for instance, run heroku apps to get a listing of all our apps on this account. You can get the API key from your heroku dashboard. Codeship will give you a direct link to it below the text field. We can also configure some advanced options. One is the URL. It is used to test if the application is still working after deployment. We can use our application name, and the herokuapp.com namespace. Then we can set some options. We want to run migrations, and we want to backup our database before deploying. You could also import the database from another application. Codeship itself uses this, when deploying to the staging environment. They import the production database to test if everything will work with the life they just set. All set. We can now create our deployment. You can see the number one beside our heroku deployment. Codeship allows for multiple steps here. For instance, if you first need to compile a JavaScript application before pushing it to Amazon L3, or if you want to deploy your code to multiple providers. Everything is set up, so let's push our changes to the server. Codeship already started to build, and when we look at the detailed bit log, we can see, after those test commands finish, the deployment is started. The output looks similar to what we would get when deploying to heroku, locally from your machine. After deployment is complete, we can visit the app. All looks good, but as we've engineered, the database isn't seeded. To correct this, we can run the rake command, directly on heroku. Use heroku run, and the command you want to run to do this. After the command completes, all the authors and publishers are in our heroku database. Now you know your way around Codeship, from testing to deploying. In the next lesson, we are going to use Jenkins as our continuous integration server, and install it on a Digital Ocean machine. See you there.