Really. Even banking sites come down for hours of maintenance. I suspect whatever your sites are, your 24/7 with no exceptions is a policy vs. a true necessity. Unless you are perhaps in the defence industry.
Live code push? *shudders* On Wed, Feb 23, 2011 at 9:31 AM, Jane Williams <janewilliam...@yahoo.co.uk>wrote: > > Our sites run 24/7: we have no maintenance window that size. I bet I'm not > the > only one, either. > > > > ----- Original Message ---- > From: Michael Grant <mgr...@modus.bz> > To: cf-talk <cf-talk@houseoffusion.com> > Sent: Wed, 23 February, 2011 14:21:31 > Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) > > > 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 <ja...@wanax.com> 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" <r...@whitestonemedia.com> > > Sent: Tuesday, February 22, 2011 10:58 PM > > To: "cf-talk" <cf-talk@houseoffusion.com> > > 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:websitema...@gmail.com] > > 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:342520 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
