# Best Practice for Separate "Update" Applications for Website

**URL:** <https://www.ruby-forum.com/t/best-practice-for-separate-update-applications-for-website/170129>\
**Category:** Rails\
**Created:** [June 12, 2009, 5:30pm UTC](https://www.ruby-forum.com/t/best-practice-for-separate-update-applications-for-website/170129 "2009-06-12T17:30:58Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Phoenix\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/5e9695/32.png) [@Phoenix\_R](https://www.ruby-forum.com/u/Phoenix_R)\
**Post date:** [June 12, 2009, 5:30pm UTC](https://www.ruby-forum.com/t/best-practice-for-separate-update-applications-for-website/170129/1 "2009-06-12T17:30:58Z")

</div>

I’ve got a company e-commerce site built in Rails 2.3 that’s up,  
running, doing fine. However, for several reasons, security chief  
among them, I’m not allowing ANY way of making changes to the database  
inside the website’s codebase itself (there are absolutely no edit/  
update or delete actions anywhere). Instead, I have two separate  
“updater” applications. And I get told to make a ton of changes all  
the time.

Maintaining three different applications is a PITA. I’m looking for a  
better way.

Basically, it’s set up like this:

[www.example.com](http://www.example.com) ← primary customer-facing site  
[update.example.com](http://update.example.com) ← available internally only (in our DNS) -  
updates products, page copy, etc.  
[fulfillment.example.com](http://fulfillment.example.com) ← where our fulfillment people check to  
process e-commerce orders (primarily read-only, internal DNS)

The trick is that they all use the same database, which resides on yet  
a third server:  
[db.example.com](http://db.example.com)

Now, let’s say I need to make a model change (or in reality, a LOT of  
them, damn “business users”). Not only do I have to update  
[www.example.com](http://www.example.com),  
but update. and fulfillment. as well. In other words, I’m not  
updating and maintaining one web application, but instead three.

What I’ve been doing is writing the new “read” functionality into the  
customer-facing site, including database migrations, and then making  
changes to the model where needed in both update applications. So far  
it’s worked fine, but it’s pretty kloogy.

I can’t put all this under [www.example.com](http://www.example.com) for security and PCI-DSS  
compliance reasons as well as other legal and security reasons my  
organization enforces. They have to be separate applications and  
available under separate virtual hosts (Apache/Passenger) to enforce  
policy.

Is there a better way of doing this, or is what I’m already doing  
really about the only way to skin this cat?

---

<div class="post-metadata">

**Author:** ![Phoenix\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/5e9695/32.png) [@Phoenix\_R](https://www.ruby-forum.com/u/Phoenix_R)\
**Post date:** [June 13, 2009, 5:33pm UTC](https://www.ruby-forum.com/t/best-practice-for-separate-update-applications-for-website/170129/2 "2009-06-13T17:33:13Z")

</div>

If the models are the same in all three sites, would it be possible to  
abstract them out into a separate piece? Maybe an Engine kind of  
thing, maybe a git submodule - or even just using some symlinks (for  
app/models and db/ ? The goal would be to keep the code in one place  
and just have all three apps point to it.

–Matt J.