Chapter 19
Deployment: Packaging Engines
In the last 3 modules of the book, you have built a complete modular Rails application.
Congratulations!
BlastCRM is only composed of three modules, but we hope you have learned a lot while building them. Since we built a “web” application, it should be available online, right? There are a few steps before we can actually push our application to staging/production. Before we do that, we will show you how to work with your modular application, and how to maintain it.
The first thing we will do in this module, is to learn how to work with a growing set of engines. We will learn how to deal with the source code, and how to manage our modules as gems. Finally, we will push BlastCRM to Heroku.
Until now, we’ve kept the source code of our modules inside the parent application. This wasn’t a problem while creating our first engines and we didn’t care about distribution. But now we want our modules to be easily re-used and shared between different applications. Let’s see how we can do this.
19.1. What is an engine?
In Chapter cha:01_03_basics we explained that an engine is a “fat-free” Ruby on Rails application. However, the fact that it has a gemspec means that we can package it as a gem! By encapsulating the source code of each of our modules inside a gem, it becomes extremely easy to share them!
To achieve this, we would first have to push all our packaged modules to a gem server, like RubyGems. Then, all we would have to do is put them inside an application’s Gemfile, and run bundle install. This would also mean that we need to version our engines (which we already have), and give each module a version like 1.0.0, and then update it to 1.0.1 when we change something, and so on, and so forth.
19.1.1. Why package your engines as gems
There are a lot of reasons for packaging your engines as gems. First of all, when building a modular application, you don’t actually have that many choices. To manage your module/engine source code, either you package it as a gem or you use git subtree.
Honestly, git subtree is a bit of a pain to work with, and we don’t recommend it; we found it quite unproductive and boring… Using gems, and simply changing a version number, is much easier, as we will soon see.
Here are the main reasons to encapsulate your engines as gems:
- Gems can be pushed to a gem server, and easily loaded from anywhere
- Gems can be loaded in your application with
Bundle - Gems can be versioned
19.1.2. Make your first gem
Let’s see how easy it is to make a gem by packaging one of our modules as a gem. Navigate inside the Tasks module folder and run the following command:
gem build blast_tasks.gemspec
This will generate a new file named blast_tasks-0.0.1.gem. That’s it! We got ourselves a gem!
19.1.3. Adding the source
If you now want to make your gem public on RubyGems, and make it available to everyone, you can simply run:
gem push blast_tasks-0.0.1.gem
It is probably not going to work if someone else pushed a gem with the same name and version, so you should try with your own modules!
The version is still 0.0.1, as we didn’t give it a proper version yet. We will fix this in the next part after we’ve talked about how you should version your engines.
19.2. Wrap Up
In this chapter we learned how to make a gem from our module, and push it to a public gem server, RubyGems.
19.2.1. What did we learn?
How to create a gem from a module.
19.2.2. Next Step
Next, we will learn how to manage and version our gems.