Safe deployment of incremental changes from SVN to a production machine?
Results 1 to 7 of 7

Thread: Safe deployment of incremental changes from SVN to a production machine?

  1. #1
    Senior Member
    Join Date
    Apr 2003
    Location
    Silver Lake
    Posts
    4,830

    Safe deployment of incremental changes from SVN to a production machine?

    I'm working on a project where we use SVN for our source code control. When changes are committed to the repository, a process on the svn server takes care to copy the changed files to our development server.

    Our production server, however, has no such automatic connection -- and for good reason. We automatically deploy committed code changes to the dev server for the purpose of testing. by the time anything gets committed to the repo, we have typically tested it on our local workstations. We don't want to auto-deploy repo changes to our live server for obvious reasons -- something could easily break.

    The question I have is once we are convinced that the repo changes need to be rolled out to the production server, what is the best way?

    I have suggested running svn export on the production server when we are ready but my coworker is balking -- says it makes him too nervous. Furthermore, svn export will fetch the entire repo unless I explicitly limit the command to some subdirectory or individual file. Additionally svn export might alter file permissions, preventing apache from writing certain data files and/or source files and/or configuration files. There's also the possibility that one might check one's local configuration file into the repo and this would ultimately end up in dev/test/sandbox credentials finding their way onto a production server.

    Can anyone recommend a sound approach to the workstation-dev server-production server setup when using svn? At the moment, we are manually tracking changed files and uploading them to the production server via FTP. This is a chore and prone to human error.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  2. #2
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    7,678
    I'm afraid this is something I struggle with a bit as well. So, just to be my usual trollish self while I wait for a real answer ... home brew diff and patch script?
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  3. #3
    Senior Member
    Join Date
    Apr 2003
    Location
    Silver Lake
    Posts
    4,830
    I'm thinking something involving rsync might be the answer. I'm still worried about copying configuration files from dev server over production config files, though.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  4. #4
    PHP Witch laserlight's Avatar
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    13,537
    Quote Originally Posted by sneakyimp
    When changes are committed to the repository, a process on the svn server takes care to copy the changed files to our development server.
    It sounds like you can do the same thing for the production server, except that this process would be launched on demand.
    Use Bazaar for your version control system
    Read the PHP Spellbook
    Learn How To Ask Questions The Smart Way

  5. #5
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Systems Vehicle "Thrilled To Be Here"
    Posts
    21,843
    Quote Originally Posted by laserlight
    It sounds like you can do the same thing for the production server, except that this process would be launched on demand.
    Treat the production server's copy as a working copy and as part of the deployment process do an "svn up"?
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  6. #6
    Senior Member
    Join Date
    Apr 2003
    Location
    Silver Lake
    Posts
    4,830
    Quote Originally Posted by laserlight
    It sounds like you can do the same thing for the production server, except that this process would be launched on demand.
    Sadly, the SVN server is maintained by a third party. They do have features that would make it fairly easy for us to manually deploy svn updates to our production server, but this requires that we enter our production server's FTP credentials into their system. We have no reason to believe they are not trustworthy, but it still seems like a security risk to store our payment gateway credentials on a third party system.

    Quote Originally Posted by Weedpacket
    Treat the production server's copy as a working copy and as part of the deployment process do an "svn up"?
    I recall having done this once and can't recall the reasons why we thought it was a bad idea. Some ideas come to mind:
    1) all the little .svn directories and such -- might these be exploited to view source code?
    2) risk of over-writing important credential files with sandbox credentials if a dev were to commit such a file to the repo
    3) adds a lot of complexity to the file system with all of the additional .svn directories and such
    4) possible changes to permissions might deprive cron/apache/users of ability to write a particular file?

    Thinking a bit more about it, I'm wondering if it might still be worth it. We might solve #1 with some kind of Apache directive? #2 we might solve by making important credential files read-only? #3 I could probably live with. #4...not sure.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  7. #7
    PHP Witch laserlight's Avatar
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    13,537
    Quote Originally Posted by sneakyimp
    2) risk of over-writing important credential files with sandbox credentials if a dev were to commit such a file to the repo
    A pre-commit hook might be able to prevent that.

    Incidentally, at work, we have git repositories on the production servers that are updated on demand.
    Use Bazaar for your version control system
    Read the PHP Spellbook
    Learn How To Ask Questions The Smart Way

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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