Quick Database Branching Tip
This is just a quick article to let others know of a really quick tip for testing multiple branches of the same code.
TL:DR - Keep a copy of your database for each branch. Track your database.yaml file, you can still replace it on production with cap.
Lets look at an example. Your site ships jewelry to buyers. You need to make two changes. First you need to change the way you calculate shipping to include a calculation that bases the insurance value on the materials used in the jewelry. This change will require you to add support to track materials on items, and will take weeks to implement (data gathering, testing, etc.) The second change is a quick change to fix an incorrect calculation on sales tax. The change is simple, and will only take a few moments. More importantly, because your charging people the wrong amount for taxes, it’s critical you fix this ASAP. It can’t wait for the shipping changes to take place.
This is a good place for branching to step in and allow you to work on two separate “versions” of the site. One with shipping changes and one with tax changes. Any moderately decent developer will use some kind of source control. Even the most basic implementations of source control have support for branching in some way (though the approaches can be extremely different). Branching allows you to store all your work on the shipping “branch” and make changes really fast to the tax branch. Then you can deploy the tax branch and at a later date, when the shipping branch is complete, blend them together (merge) for a complete website with both changes.
The way developers do this is very different and depends on tastes, SCM in use, and a bunch of other complicated factors. But, in most of them, there is a small left over problem. Usually you have a few untracked files. In rails, it is very common (and recommended) to not track changes to the development database. However, this has an effect when working on database altering branches. The database file will not match what your working on. In or example, the shipping changes require some database changes. However when you start making changes to the tax branch, the code is from a time before the database changes were made. Basically rails’ expectations of database structure does not match that of the actual database.
The fix is actually simple. Copy the development.sqlite3 file (assuming that your using sqlite) and rename it. In your database.yaml file just use the new name in the new branch. Make sure to ignore your new sqlite3 files and track changes on your database.yaml. If your tracking your database.yaml file just don’t store any production information, and you can still use cap (or whatever) to copy over it on the production server. Then apply your database migrations and changes, and you will have databases that switch back and forth based on branch.
P.S. This doesn’t depend on sqlite3 you can use any database, for example in mysql just clone the database with a new name and continue on.
Coteyr.net Programming LLC. is about one thing. Getting your project done the way you like it. Using Agile development and management techniques, we are able to get even the most complex projects done in a short time frame and on a modest budget.
Feel free to contact me via any of the methods below. My normal hours are 10am to 10pm Eastern Standard Time. In case of emergency I am available 24/7.
Phone: (813) 421-4338