SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Member
    Join Date
    Jun 2012
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Properly Setup a Development Site & Database to work seamless with a LIVE Site

    Hello all,

    This is officially my first post so hopefully this is not already a posted thread but I am wondering how to properly structure a membership site for managing updates seamlessly. It would involve having a LIVE database of users. I was not sure the BEST method to structure this or if anybody knew similar setups that large companies might have in place such as Amazon.com, Facebook.com, or Ebay.com. Just to clarify. I know I would need a development site and most likely a "dummy" database filled with testing information so the real database remains untouched. I was not sure though for example if an update needs to be implemented to proper workflow that would need to be established to do so.

    Ideas, thoughts, suggestions, or pointers?

    Thanks in advance!

  2. #2
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,627
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Amazon, Facebook and Ebay probably aren't using traditional datastores to handle this stuff these days. They are in a special category of scale best not worried about until you get into that category.

    For the rest of us, if you are using a traditional SQL datastore, the main trick is using SQL scripts to manage database changes. Typical workflow here is:

    * Developer writes / tests / debugs script locally
    * Developer commits changes to source control
    * Continuious Integration Server builds app and runs database change script.
    * QA / feature owners sign off
    * Developer pushes change to live site and excecutes script against production database

    We typically just make some backups available for the developers to download and use for testing purposes.

  3. #3
    SitePoint Member
    Join Date
    Jun 2012
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, that was kind of what I was thinking, but is there any recommendations on the server setups in particular? Like a dedicated development server, a backup server, and the LIVE site (external server)?

    I was also kind of curious as to how Facebook or other sites put up a notification window, for certain areas saying it is currently undergoing maintenance.

    Thanks again for your help and insight.

  4. #4
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,627
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Dev server and live server make sense. What is the backup server for?

  5. #5
    SitePoint Member
    Join Date
    Jun 2012
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The backup server is mainly for the idea of version control. Not sure the best route to set that up would be. I hate feeling newbish to this stuff but its definitely a learning experience. Thanks again for the input too by the way - it's always appreciated.

  6. #6
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,627
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Use a real version control system for version control -- I'd suggest mercurial or git. Pretty necessary if you are going to take advantage of continuous integration anyhow.

    What we use is really about 3 instances per site, servers aren't quite a 1 to 1 map. We keep:

    a) ci.whatever.com -- the continuiously integrated version of the site. Really for developers to make sure their changes didn't break anything someone else did, also handy for quick feature feedback from end users or stakeholders.

    b) qa.whatever.com -- much more checkpointed version of the site. For final QA / approvals.

    c) www.whatever.com -- the real deal site.

    We typically don't bother with a popup like facebook because we can usually accomplish the update in a matter of seconds -- we just update the codebase in production from the appropriate source repository and run the database scripts. Facebook's build and deploy process is a bit more involved, but I saw an article recently on it. You might want to google around a bit, I can't recall where I saw it though.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •