This post is exactly what the title says; a short how-to to deploy Broadleaf Commerce to Heroku, a popular cloud platform. This has been done with the Broadleaf 1.6.0 archetype and all the CLI commands were run on OSX, but the commands should be 1-1 for Linux. If you use Windows, you’re gonna have a bad time.
First, let’s pop open a command line and build the archetype with maven with the following command:
Fill in the relevant prompts, and you should see some output like this:
As you can see, the archetype ends up generating 2 applications: admin and site. The wars are built from admin-war and site-war. In a perfect world, we would leave the structure as-is and deploy both applications to Heroku simultaneously. However, Heroku limits the ‘slug’ size (how big of an application you are deploying) to 100MB and both admin.war and site.war are right around 60MB apiece. I’ll deal with the admin application in a different post (it’s a little tricky since it’s in GWT), but for now we’re just going to remove it (or move it to a different location).
While we’re on the subject of slug size, I found a nice plugin for helping reduce the size of the target directory that Maven builds courtesy of Chris Auer. Add this section to the build -> plugins section of the core, site and site-war pom.xml:
Now let’s go in and make the necessary database config changes to work with Heroku.
applicationContext.xml diff:
You’ll also need to change the HSQLDialect to PostgreSQLDialect in the persistence xmls and add the dependency in your poms.
So in the main persistence-mycompany.xml:
You’ll also need to do a similar change in the test persistence xml:
Then completely remove the HSQL dependency and declare the PostgreSQL dependency version in the root pom.xml:
And in site-war/pom.xml and test/pom.xml also remove the HSQL dependency declaration and add the PostgreSQL dependency there:
Now comes a tricky part. The nice thing about Heroku is that you can use it with any number of applications: Ruby, Node, Java, Python, whatever. But this is a double-edged sword: Heroku doesn’t give you a nice application server (like Tomcat or Jetty) to deploy to out of the box. You have to include it yourself in your Maven profiles. The Heroku documentation explicitly talks about using embedded Jetty, but I couldn’t get that to work and prefer Tomcat anyway. The Maven execution that I added for Tomcat actually goes out and downloads a Tomcat zip, unpacks it, then deploys your war inside of it as ROOT. This is achieved with the codehaus cargo plugin:
in site-war/pom.xml
You can obviously change the Tomcat version to whatever you like. I personally chose Tomcat 6. Tomcat 7 would work the same way.
One more Tomcat-specific item. Heroku assigns a random port number for your application, but Tomcat always defaults to 8080. To allow for this, I created a heroku-server.xml that the Heroku Procfile will rename to server.xml and move to the Tomcat deploy directory and allows for the dynamic port binding. I put this in the root of the site-war directory
Now the only thing that’s left are the Heroku-specific files. The Procfile is extremely simple. All it does is kick off a custom shell script which does all the heavy lifting
Procfile:
The real meat comes from startup-heroku.sh:
And that’s it for the configuration! Now the only thing left is to start up the app!
If you haven’t already, go ahead and create the Heroku cedar application which automatically adds a new git remote
Then just deploy with ‘git push heroku’ and you’re done! To check for startup problems, you can tail the logs with heroku logs –tail which shows you the real-time logging info.
Feel free to check out the demo currently running on Heroku. This is just on the free Heroku tier so it might take a bit to come up. If you run into any issues, you can send me a pull request via the GitHub project.