In this book, we saw how the Play! Framework 2 can be used to create great web applications. However, we only saw them running on our machine, which is a dev machine. So far, so good, but a web application is not meant to be used this way; it has to be productionized, which requires it to be deployed on a so-called Prod server . A Play! Framework 2 application can be deployed in several ways, for example, in a servlet container, such as Tomcat. However, in this chapter we'll concentrate on a particular use case; cloud deployment on a Platform as a Service (PaaS).
But, wait! There is something that a web application needs before before it can be released to the end user. It needs a neutral environment, which asserts that the application is delivering its features correctly. Nowadays we like the Release Early, Release Often vision, but for that to happen we need to have an automated and continuous eye on its quality.
That's why we end up in a more general process called Continuous Delivery . Continuous delivery means that the work done by a developer has to be checked into a decentralized repository. This repository will be used by a tool, a Continuous Integration (CI) server, to check that the modifications aren't leaving the application in a stale state.
At this stage, we're not yet done because the final user cannot use the newly added functionality (or bug fixes). For that, we need the CI to automatically deliver the status to a deployer (it could be the CI itself or a plugin), which will be able to redeploy the application when the status is okay. On the other hand, if the code base is failing the CI, we need it to send events to the dev team, which should pause its current tasks and work on the problem until the application is stable again.
So far, so good, our application will be continuously managed from the dev to the user. But is it running fine in any case? How do we ensure that? Don't we need another handy tool out there, such as an admin interface, which will act as an applications' doctor?
In one word, a monitor that will enable us to react to strange runtime behaviors, utilization peaks, and so on. Fortunately, this tool is already part of the Typesafe stack (remember that Play! 2 is the web layer of this stack) and it is named Typesafe Console.
In this chapter, we'll cover these three pillars of web application management, essentially using a dedicated service on the cloud for each of them:
- Continuous Integration server using CloudBees DEV@cloud services (SaaS)
- Deployment on Heroku (PaaS)
- Monitoring using the Typesafe Console
In this section, we'll talk about CloudBees, which is the provider of a blazing service for Jenkins, the famous open source Continuous Integration server.
This is not the only great service this company is offering of course. Its portfolio spans every single step of a Continuous Delivery process. And they do it very well from the code repository to the runtime and even some monitoring through add-ons.
However, we'll specially focus on their DEV@cloud product, which is the CI service.
So, CloudBees is a Java Platform as a Service that aims to completely abstract the Infrastructure as a Service (IaaS), which CloudBees uses on its side to provide a clean and easy way to manage an environment that builds, tests, and runs a web application. As a fully dedicated Java platform, it is particularly well integrated with the ecosystem tools and framework built on top of this language and the related languages, such as Scala, Clojure, JRuby, and so on. CloudBees is special in several aspects, the first is that it's a freely-accessible panel of services, at least until the thresholds are reached. Nevertheless, these thresholds are sufficiently high enough to enable up to three regular developers to run their tests. On the other hand, the runtime needs are not dependent on the number of coders, but are dependent on its quality and popularity.
Alright! Before starting with it, let me first introduce CloudBees' two major products:
- DEV@cloud: This service provides a perfect environment in which to test a web application. It's completely integrated with a provided code repository or with any code repository we own and is publicly accessible. It can also be fully automated using hooks around the code repository that it's using for running the tests.
- RUN@cloud: This service is the runtime environment that is available in two flavors depending on your needs. There is the multi-tenant and the dedicated one. Since they're abstracting the underlying infrastructure, we could own fully dedicated machines (virtualized) or parts of machines (shared with other applications) without any extra configuration.
After this short introduction to the CloudBees services, it's now time to get back to our initial concern, that is, how to use CloudBees to continuously check that our Play! 2 application remains stable with each modification saved in the code repository.
First of all, we have to go to their website at http://www.cloudbees.com and create an account. Having done that, we can now log in to their website and access our administration console:
The preceding screenshot shows a brand-new account without any application, so it's time to create our Chatrum application. Here's where the magic starts!
Indeed, since CloudBees is a Java PaaS, and it's clever, it has eased the work for developers wanting to bootstrap a new application on their framework of choice using what are called ClickStarts.
A CloudBees' ClickStart is in fact a wizard to create an application using several tools commonly used together. Thus, the created application will include configuration files for them, or even the glue between them. That's not all, the extra tools will be preconfigured as well, such as the Continuous Integration server or the deployer. In our case, we'll find it very handy that we can create a Play! Framework 2 application. CloudBees recognized very early that Play! 2 will play a major role in the web world in the coming years. Therefore, they created an end-to-end wizard, which can grasp our application's code, preconfigure a Jenkins server for it, and also help the Jenkins server to be able to deploy it. Moreover, it is done in just a few clicks. Let's see it in action; click on the upper-left icon in the navigation bar of our admin interface (with the label ClickStart). We should get something similar to the following screenshot:
Look at the previous screenshot. It's right in the center of the page, surrounded by giants such as J2EE 6, Node.js, Hibernate and Tomcat, and a Facebook application environment.
It's time to go ahead and click on the Play! 2 icon! This click will ask CloudBees to prepare a Play! Framework 2 environment, which we'll need to test our application (or run it). Before that, it will ask us for a name for our application:
The input field right below recaps what will be created for our application, in terms of services and so on. We'll name our application Chatrum and click on Create App >.
Plenty of infrastructure tasks were realized after just a few seconds of preparation, which would have taken a full week of work without CloudBees. In the following screenshot, we see that our server is ready with some available tools:
Amazing, huh? We can now check off, in two clicks or so, a source repository (Git), a Continuous Integration server (Jenkins), a web administration interface (CloudBees' interface), and even a database (MySQL)!
We're about to see how to use them all, but first we must open the application by clicking on the Open Application button. This will lead us to our account interface from which we can access all of our services for all of our applications:
As we can see in the preceding screenshot, we can administer everything from here.
As mentioned before, we'll only focus on the first three icons—Repositories, Jenkins Builds, and Applications. The first will show us how to deal with the Git repositories we have at CloudBees, in this case there is only the chatrum repository (see the following screenshot):
The interface includes a lot of information about the Git repository, for example, its URL, its visibility, and so on. The bottom-left corner also explains how to use the Git repository in the cases where we already have some code to push (which might be available from another Git repository) or if it's a brand-new application (when we're starting from scratch). The cases are grouped within accordion panels.
After having pushed our chatrum application to this repository, it would now be worthwhile seeing how to run Jenkins on it.
For that, we can click on Builds in our top navigation bar; it's a shortcut to our Jenkins' administration interface:
It appears that it's just a classic Jenkins console, but embedded within the CloudBees interface. And what's already out there? Our chatrum application of course!
Indeed, at this stage, a Jenkins' job has already been created for our application. However, its sole task for now is to check the code repository for changes and build the application without testing it by default.
That's great, but since the tests aren't being run, we're breaking the Continuous Delivery process. We must now ask this job to run the tests, which automatically implies that the application won't be deployed if at least one test has failed.
This can be achieved by going to the configure page of the chatrum job, as follows:
In this page, we'll have to update the Build | Execute Shell command, which CloudBees has configured for us.
We'll add the following two things:
- A test goal, asking Jenkins to run our tests
- A configuration for a display environment, which is helpful for tests using Selenium
This is done by updating the default command line in the text area. In the following screenshot, we can see which command has been set up by CloudBees for us:
And the next screenshot shows the resulting command line we must use:
What was done is that the compile goal was changed to test, and a DISPLAY environment variable for a virtual display server was added.
So far, so good, we're going to make a little change in our code, push it to CloudBees, and finally check what's going on. The change we will make is asking Selenium to use Firefox rather than its in-memory web browser; since it's a very simple change in the code, it looks fine for this example. To do that, simply navigate to workflow/RegisterSpec.scala and replace HTMLUNIT with FIREFOX.
Now we can commit the change and push it back to the CloudBees code repository, and then get back to the Jenkins console. We'll see that a new build has been launched, thanks to the Git hooks and the configuration, which CloudBees has made for us.
So, we just have to wait for this build to finish (and succeed obviously) to enter the build's result by clicking on its item in the bottom-left panel. A Jenkins job result page has a menu item to view the console output (on the left-hand side navigation bar); if we click on it, here is what we'll see:
Hurray! All tests passed! So we're now ready to code in a peaceful way, even with several devs on the same code base or in different time zones. At least, we know that the future commits won't break the application for the currently tested specifications.
As you can see, a second box has been drawn around another message, which notifies the user that the application has been deployed as well. However, the deployment part will be covered in the next section using Heroku.