-
Get a monthly update on best practices for delivering successful software.
So we just went through this humongous (believe me!) effort of upgrading the technical platform for one of our existing Rails applications that was running Rails 2.1, Ruby 1.7 and Mongrel cluster. The goal was to upgrade to Rails 2.3, Enterprise Ruby 1.8.6 and Passenger. It all started out as well as you would think. Updating the Rails gem, Ruby version, installing/configuring Passenger and updating relevant gems was pretty quick and smooth. Some quick and dirty testing of the application did not reveal any major problems or issues. Great! You are thinking the upgrade is mostly done att this point before you move on to the tests in the application!
Tests
Tests can prove to be major hurdle in upgrading Rails applications. In our specific case, close to 70% of the tests were either broken or failing due to a number of reasons. Actually, the number of broken tests was way way greater than failing tests which led us to think the changes in the Rails testing API caused most of these issues. Some of the issues were also caused by a plugin or gem that was used to support the tests not being compatible with the new API. It took us quite a bit of effort to figure out the reasons for the issues and also find the fixes.
Continue reading »
Topics: Ruby on Rails, Testing, Upgrade
Whenever you can get a free, publicly available place to deploy your applications, your first instinct is to grab it with both hands. Google App Engine is one of those places. Each developer can deploy up to 10 different apps in development mode.
I've been working on a grails app recently that uses the grails App Engine Plugin. Along with the GORM-JPA Plugin, which gives you some of the usual grails GORM goodness, you can write some reasonably interesting grails apps.
Continue reading »
Topics: App Engine SDK, Google App Engine, Grails, Groovy, Java
When designing production environments, it's often useful to separate reporting functionality to it's own virtual machines/hardware. I have run into a few cases, where data anomalies can wreak havoc on production systems.
I generally try to set up slave databases that are replicated with the master, and point all reporting application servers to the slaves. This reduces the demand on the master database, thus leaving it free to deal with the actual production systems. Depending on the reporting demands, the number of nodes in the reporting cluster can always be adjusted. Many clients find that their reporting demands suddenly increase drastically due to changes in their business processes, so it's good to have the flexibility to scale the reporting environment separately from the production systems.
One system I support found that there were huge production performance issues out of the blue. It turned out that one of their clients' machines was hacked, and was scraping their site. This didn't add huge demands to the production systems, but caused a incredible strain on the reporting system, as it was aggregating abnormal data. We found that the reports were putting huge strains on the same system that was trying to serve production. It is hard to sell a separate environment to many clients, as there is additional hardware costs, but if both reporting and production reside in the same environments, it's difficult to adjust one or the other when changes to the business of client demand change.
In the long run, if you separate from the start, you will have the freedom to re-purpose virtual machines among the clusters of reporting and production systems, thus giving you the choice of what needs the most help with your given hardware configuration.
Related Services: Full Life Cycle Software Development