Part of the Continuous Delivery process, the deployment phase is one of the most critical. An application when deployed, is released into the wild where innocent monsters (users) are massively mistreating it (using it).

The deployed version is the one that will be used, it will show end-users the new features, bug fixes, and so on (or the problems, if any). It has to be resistant to peaks of use. So there are several needs that we might find very helpful at deploy time. Examples of those needs are the ability to redeploy quickly and easily when hot fixes have been made, or to scale our application horizontally when running on the cloud.

Nowadays, a great solution to those problems is the Heroku provider (cloud hosting) that comes with a PaaS, which is completely independent of the underlying infrastructure. And managing a running application is very easy, thanks to their amazing Toolbelt tool.

Okay, calm down! Let's rewind a bit and briefly introduce what Heroku is.

Heroku offers a hosting platform for cloud applications. For this it supports a plethora of different languages from Ruby to Scala, through to Java or Python. Their philosophy is their key value. As mentioned earlier, their platform is completely abstracting the machines that were started under the covers for our application. All we have to deal with is what they term as dyno. What we must understand about a dyno is that it's like an isolated unit of work dedicated to our application, which is able to receive requests or run commands. In one word, it's like a small machine, we don't have to manage anything.

A dyno is built in such a way that our application can run on it, receive requests, or even start batch processes. The coolest part is that we can add as many dynos as we like (to pay for). Moreover, Heroku deals with them in a completely fault-tolerant way.

So those requests and processes are dispatched, balanced, and recovered out of the box—these problems are no longer ours! Isn't that beautiful?

Furthermore, their ever-increasing popularity has been reflected in the number of tiers' services that have been integrated with their platform as add-ons. This fact results in a very wide ecosystem, including ElasticSearch, Cache, and NoSQL databases.

Great! After this quick introduction to Heroku, let's see how to use it. This leads us to use their Toolbelt tool—a command-line tool enabling any application running on Heroku to be remotely scaled, monitored, restarted, and so on. The best option, now, would probably be to install it and deploy our application on Heroku. Its installation is pretty simple and very well explained at https://toolbelt.herokuapp.com/.

With our account created and the CLI (toolbelt) installed, we must now get back to our application, using the console. From here, the deployment is rather simple. First of all, we have to create our application on Heroku, which will add it to our account's administration console. This can be done as follows:

Yeah, really, two commands and we're done!

Actually, the first command will create an application on Heroku for our chatrum app with a generated name (arcane-castle-4028), the second will push our code to the Git repository that Heroku has created along with the application.

If you don't want Heroku to generate a name for your application (that you still can change in your administration interface on the website), you can update the command as follows: heroku create <your-chosen-name>.

This Git repository will be used by the Continuous Deployment feature of Heroku.

When new commits are incoming (pushed), they will ask Heroku to try and redeploy our application. So, let's try it directly by pushing our code into this repository and see the next screenshot for an excerpt of the output. We can see that it has detected a Play! Framework 2 application. Since it knows how to deploy such an application, it did this deployment for us, directly!

You might wonder how to open it. Try executing heroku open in your console. Great! It opens our application in our default browser.

The problem is that we're not quite done, because of what is displayed on the screen (an error message):

Ouch! What's that? Since our tests are running, everything should be okay on production.

Our reflexes should have been shaken in a way that our eyes should have already been looking for the logs. Right, that's easy, use heroku logs!

Amazing, our logs have been fetched from the server and shown in our console! And, what they are indicating is that we must apply evolutions to our database.

That's right, our application is using evolutions to manage the version of our database schema and this same evolutions plugin has detected that our (in-memory) database is not up-to-date. But since the application is currently running in production mode, we cannot have the common web page we had in dev mode, which asked us to apply the updates manually.

To overcome this problem, we'll take a shortcut and ask Heroku to always update the database schema when needed (on restart/redeploy). But we'll also take the opportunity to use the database that Heroku has provided by default—a PostgreSQL database.

To use this database and to configure an automatic application of evolutions, that is, to configure how Heroku should behave, we can use a specific file that Heroku will use on deployment—a Procfile file.

This file is meant to configure the processes that Heroku must start on our dynos. In this case, we need to update the way the Play! 2 application's process (called as web process ) is created.

The Procfile file must be created in the root of our application and will look like the following:

In this file, we can see that we created a web process using the target/start script. This process is running a JVM to which we've passed several options to be used by the application, for instance, the port to listen on, or the default Java options set by Heroku. Note that we've just reused some environment variables provided by Heroku, and the same goes for our database URL.

But what has been done in this Procfile file to resolve the database status problem is the addition of the applyEvolutions.default=true option. This option tells the application that we want evolutions (1.sql) on the default database to be applied at start time, where this default database has been reconfigured by two other variables targeting the PostgreSQL database that Heroku is providing.

To check this solution, we can do the following:

Your default browser will be opened at the application's URL and will show you the login page. Hurray!

Now that the application is running, we would like to know if the current deployment is sufficient for the load, and we would especially like to monitor some metrics. Indeed, at runtime there are plenty of variables that might slow down our application, or even blow it up. That's where monitoring tools enter the game, and that's the topic of the next section.