SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Member
    Join Date
    Jun 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Creating a publishing process for team members

    We have a Ruby on Rails application where we let designers and content editors edit view files, style sheets, javascript, and images. Basically content in /views and /public. We use subversion as a code repository for the entire app. Our process is that we set up a staging server where designers and content editors directly FTP in and edit files (think .html.erb files). We don't like to let these people have entire working copies of the site reside locally on their system. Once the pages they are working on look good, they take those changed files and add them them into a subversion repository. Once they commit, the changes are pushed to our live server (we use post hooks). Our team needs to be able to make "live" content edits to our site.

    So far this has been a reasonable process. I'm trying to see if there is a way where we can eliminate the step of copying files from the staging FTP into the subversion repository since our designers and content editors have to remember to move several files from different folders in the app into the subversion repository from staging. An alternative would be to let our people make changes directly into the subversion repository which is instantly pushed to a staging server. They then execute a update to production using some type of script or button on our intranet.

    Any thoughts?


    THANKS!!!

  2. #2
    SitePoint Evangelist
    Join Date
    May 2006
    Location
    Denmark
    Posts
    407
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If they can upload files to the FTP server then they'll also be able to download them, so why not just give them permission to do an svn checkout to their local computer? This will also prevent people from stepping on each other's feet which kind of what Subversion and similar version control systems are for. You could always be the one who does an "svn update" on the production server.

  3. #3
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,576
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    ^^^This man has the right answer. Just have them work directly in SVN, perhaps in their own branch if you trust them as little as I trust the art/content types. But it really beats any other way to handle stuff. Only real trick is how to schlep databases around, but hopefully you have already got a relatively frictionless way of handling this for the dev team.

  4. #4
    SitePoint Evangelist
    Join Date
    May 2006
    Location
    Denmark
    Posts
    407
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You could also give them read access and have them submit a patch to you that you can review before commiting it to the repository.

  5. #5
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,576
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    That could work, but patch files are limited and, moreover, you have to teach the art types how to do patch files. Getting them to handle committing changes is much easier. Security-wise, you can constrain them to a branch if you don't trust 'em.


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
  •