Only if you roll your changes out while the site is live rather than during a maintenance window. Take the site down for an hour at 4am, push your code live and run your db updating scripts on each db. It shouldn't really be too big a deal.
On Wed, Feb 23, 2011 at 7:33 AM, Jason Fisher <[email protected]> wrote: > > The big caveat I will give about have multiple databases with multi-tenant > code is that any change to the shared code has to be reflected in every > single database simultaneously. And that's a challenge and a half. > > ---------------------------------------- > > From: "Rick Faircloth" <[email protected]> > Sent: Tuesday, February 22, 2011 10:58 PM > To: "cf-talk" <[email protected]> > Subject: RE: Feedback on this approach to "many sites, one codebase" > (MSOC) > > I can see both sides on this one very clearly. > > To this point, all I've ever done is develop custom > applications and websites. I haven't sold the exact same > site in 10 or so years of development! > > However, I really want to get away from working > just one-on-one with clients. They can be a real pain. > Some are just downright ignorant and impossible to work with. > (You can tell I've had a couple of bad experiences lately... ;o) > > I'm want to move into developing sites for specific uses, such > as for recreation departments or real estate agents and brokers, etc., > and have them sign up for the site online, choose their template, > put in their content, and, after a free trial period, they pay > their money. If they need support, they can email me. > > If they want functional customization, I'll build a custom function for a > client, > charge them for it, then make that function available to anyone > else using my "SAAS" sites. The customers will never own the sites > and never have the opportunity to "take the code" elsewhere. > > If they want cosmetic or style customization, I can do that > and charge them for it. It will still remain my site and not > the client's site. > > I'll still build custom apps along the way, I'm sure, but I'd > like to start making my work on an app/site pay more than one time. > > However, like you Matt, I may end up going back to individual > customizations, if things don't work out so well on the SAAS front. > I do have some clients who always insist on being absolutely unique > and want to have the "best" site. To those who want to be absolutely > unique, I can sell the template for a few thousand or whatever amount, > and they'll have exclusive rights to use that template, but they > still won't own it. Soon as they stop paying, the template goes > back into the fold. > > I just want to test this approach and see if I can make it work. > > Rick > > PS - when it comes to the database, I'm leaning towards a different > database for each client. I'd hate to have problems with a client's > data and have to parse through everyone else's data to see what > the problem is. Of course, I do have some "common data" databases > that everyone would share...local area info, etc. But I'm currently > still using distinct databases for client-specific data. > > -----Original Message----- > From: Matt Robertson [mailto:[email protected]] > Sent: Tuesday, February 22, 2011 1:02 PM > To: cf-talk > Subject: Re: Feedback on this approach to "many sites, one codebase" > (MSOC) > > Even though my own CMS can handle multiple sites running off of a > single installation, I don't run it that way. The points brought up > about clients wanting individual customizations and portability fit my > situation. I understand if you are offering software-as-a-service > things change, but for me this turned out to be enough of a headache > that I reverted to separate installs and have never regretted it. If > a customer wants an upgrade, they pay me an hour or two individually > to make that happen. If they want a specific feature that I don't > want to fold into the overall codebase, I can do it - and earn the > money for doing it - without worrying about consequences on 40 other > web sites on the server. But thats a business decision and not > coding. Mentioned just as food for thought. > > For sites for my own company, where presently we have about 36 up and > running and will be at around 60 when we are done, we *do* share a > single codebase. There are no special mappings. Each site has an > Application.cfm that looks like this: > > request.appName="AR_060110_1033"; > request.rootFolder="ARDotCom/"; > request.FQDN="www.mysiteAR.com"; > > <cfinclude template="../common/Application_common.cfm"> > > The common file has some server vars too: > > server.BaseRoot="C:/foo/bar/sites/"; > server.dsn= etc. etc. blah blah > > And thats enough - along with more code in the common > "Application.cfm" - to set up absolute and relative paths to the files > I have located in the common-use folder. Every site has its own > independent application scope. > > I've opted to set the app name manually so I can reset session and app > vars if need be... a rare occurrence but its nice to have the option > available. > > The root of this web site is a root folder in a discrete IIS web site > and, since CF has no trouble recursing back up beyond a web root > insofar as physical paths go, the /common/ folder is not accessible > from the web, but it is from CF. Very simple to set up. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342516 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
