Deployment: Managing Engines

20.1. Development vs Production

When working on a modular application, you will essentially be working with two “versions” of the same application. We will explain what we mean, and the theory, by using BlastCRM as our example.

Our current BlastCRM application is the development version. It contains the source code of each engine, and you will need to put the source code of any new module in the engines/engine_name folder. This is the copy (i.e. version) you’ll work with when you want to add new features. For example, if we change something in the Core module, we will commit our changes and push the Core module from this application. Once the code is pushed, we will be able to generate a gem.

With this new gem pushed to a gem server, we will switch to the production application. If you don’t have one yet, you just need to pull the code from the development version. Then, you’ll have to delete the engines folder, update the Gemfile to use the gems instead of the local folders, and run bundle install. This way you will have a clean production application that you can push to a new repository.

Here are the main points to remember about development vs production applications:

Development Application

• Used for development
• Contains the source codes of all the engines (with each engine being pushed to its own repository)
• Cannot be pushed to production

Production Application

• Engines are referenced by path in the Gemfile
• Cannot be used for development
• Does not contain the engines’ source code
• Can be pushed to production
• Engines are referenced by their gem version and source, and loaded with Bundle

20.2. Working with Git

Git is an amazing tool to keep your source code versioned and work with other people. If you want your work on a modular application to be as smooth as possible, you need to have your engines’ source code versioned. Using Git (or any VCS) will allow you to easily work on your modules with your colleagues, and safely add new features by using branches.

But what’s the best approach? Could we just version the parent application with the source code of the modules? That’s one solution, but probably not the best one.

Versioning your parent application is, of course, recommended, but without the modules inside. If you use Git (git init .) inside each engine, they won’t be versioned with the parent application. You will have to push the parent application and each module to their own repository, but it will give you a log for each module instead of a confusing log for the parent application that contains changes for your engines.

MAJOR.MINOR.PATCH.BRANCH

20.3. Eating your own dog food

Have you ever heard the saying “Eating your own dog food”? If you don’t know it, it means using the tools you create to ensure their quality and capabilities.

Let’s say you’re working on a CMS, like WordPress. Obviously, you want to write it in Ruby. One of the most interesting features of WordPress is how extendable it is. You can easily create a plugin by hooking into WordPress. Of course, you want your CMS to be as famous as WordPress, so having a plugin-ready application is a big plus. With everything you’ve learned in this book, you now have two choices:

You could create a regular Ruby on Rails application. You would then need to start thinking about how people could extend your application. Basically, you’re not “eating your own dog food” because you won’t be using this extension system yourself. And everybody loves dog food!

The other option is to build a modular application the way this book showed you. You’re making your application extendable for yourself, which helps you detect flaws and fix them before you let other people create plugins. You could create the Core as a very basic system, and create your own modules to add more features like comments, tags, etc. You could even make it in a way that allows people to disable some features easily, by not loading the engines! Next time you’re building an application that has to be extendable, think about it… modularity might be the way to go.

20.4. Wrap Up

In this chapter we learned about managing our engines.