Announcement

Collapse
No announcement yet.

Is SVN good for a webdev?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is SVN good for a webdev?

    Hello colleagues,

    Understanding that SVN is mostly used in "software development" environment which is not quite what webdevs do, I'll elaborate a bit.

    We have two dedicated Centos servers each running a WHM/cPanel with a number of accounts, each account running at least one site, sometimes a few. Each server has ~70 accounts and uses ~100GB in total (including databases). Apache+php run in SuPHP mode. Each account has its own SSH/SFTP login/password that we use to upload files. Each account gets nightly off-site backup, so if we need to revert to a X months old code and/or database state, it's all covered.

    We mostly work with opensource CMSes and/or Web-applications (Joomla, Wordpress, Magento, Limesurvey etc.) with addition of 3rd-party or our own templates and extensions. Typical setup is a cms with some 3rd-party extensions (~7000 files /~100MB) which get more or less regular vendor updates (files written on top). Actual development goes only on small fraction of these files (~100 files /~1MB), in extreme cases on just two: a template's php file and CSS file. In terms of backup and/or version control, we only care about the files we edit: our own extensions and templates.

    As a developer I keep local copies of most server accounts as projects in DreamWeaver. We customise the template and debug our plugins, then if I'm happy with test results on my PC, I upload modified files on server. Quite often there's a need to apply minor changes to a single file and upload it on the server ASAP (i.e. to fix some CSS glitch).

    Once in a while another developer grabs a file off the production server, make edits and uploads it back; he may or may not alert me about it, making it possible for me to overwrite his work without a trace. That is a problem #1 which may or may not be solved by using a centralised code pool provided by SVN or other versioning system.

    Problem #2 is that we run the same (our own) CMS plugins on different sites, adding features to one at the time and struggling to propagate this updates across other sites. Sometimes the code would be the same, sometimes it is slightly different between sites depending on functionality requirements. Usually there's no "best and latest" (trunk?) code to merge with so I have to merge each variant with others to update them all while keeping the differences. It would be nice to streamline this task. It would also be nice to have some way of stamping files with version/date.

    Problem #3 is the lack of the local backup, I mean the code that is not yet uploaded on production server. May be solved by SVN or in traditional way (rsnapshot etc.)

    Question is, should we consider SVN (or other versioning software) at all to be a reasonable and practical solution, given that:
    - we don't "build" software as they do in C, .net or Java shops but update and upload just few files at a time
    - we only need a handful of files to be tracked/versioned, out of thousands we don't care about
    - we hate and most likely won't use command line

    Will appreciate any answers, recommendations and links. No RTFMs please. Thank you.

  • #2
    Originally posted by tgv View Post
    Understanding that SVN is mostly used in "software development" environment which is not quite what webdevs do, I'll elaborate a bit.
    What specifically makes a "webdev" special? Nothing. Code is code. Although in my experience, "webdevs" tend to have a less rigorous development methodology than more traditional developers/engineers, and that needs to be changed.

    <snip lots of minutia that doesn't really matter for this>

    Originally posted by tgv View Post
    As a developer I keep local copies of most server accounts as projects in DreamWeaver. We customise the template and debug our plugins, then if I'm happy with test results on my PC, I upload modified files on server. Quite often there's a need to apply minor changes to a single file and upload it on the server ASAP (i.e. to fix some CSS glitch).

    Once in a while another developer grabs a file off the production server, make edits and uploads it back; he may or may not alert me about it, making it possible for me to overwrite his work without a trace. That is a problem #1 which may or may not be solved by using a centralised code pool provided by SVN or other versioning system.
    You have multiple problems, really.
    1. You have unrestricted access to your production environment.
    2. You have no process for managing your code migration/maintenance
    3. You have no accountability
    4. You have no integration test environment.


    Originally posted by tgv View Post
    Problem #2 is that we run the same (our own) CMS plugins on different sites, adding features to one at the time and struggling to propagate this updates across other sites. Sometimes the code would be the same, sometimes it is slightly different between sites depending on functionality requirements. Usually there's no "best and latest" (trunk?) code to merge with so I have to merge each variant with others to update them all while keeping the differences. It would be nice to streamline this task. It would also be nice to have some way of stamping files with version/date.
    Each site you develop will have its own trunk, and you'll maintain what Subversion calls a Vendor Branch of the CMS and/or plugins to track all those changes.

    Originally posted by tgv View Post
    Problem #3 is the lack of the local backup, I mean the code that is not yet uploaded on production server. May be solved by SVN or in traditional way (rsnapshot etc.)
    Subversion (or any other VCS) should never confused for a true backup system/process.

    Originally posted by tgv View Post
    Question is, should we consider SVN (or other versioning software) at all to be a reasonable and practical solution, given that:
    - we don't "build" software as they do in C, .net or Java shops but update and upload just few files at a time
    - we only need a handful of files to be tracked/versioned, out of thousands we don't care about
    - we hate and most likely won't use command line
    Anyone writing anything even resembling software must use a version control system. If you aren't using one, you are doing your development wrong, before you've even started.

    You also have no development, testing & promotion methodology/controls. You need to get that fixed. You should have, at a minimum:
    • Version control environment for your code
    • The ability to run your apps/sites on your local workstation so you can test prior to committing changes
    • A means by which an integration test server can automatically be updated with the latest code (for example, a Continuous Integration server)
    • Controlled access to the the integration test server and especially the production server so that code doesn't fly in "under the radar". That is, you should only be able to get code into an environment in one way: local -> Subversion -> test -> production.
    • Each release to your production environment should be a known, tested & approved 'set" of functionality/changes. No one-off changes. Controlled, packaged releases.
    This is what it takes (at a minimum) to have a safe, sane, mature software development environment. Software is software, just because your software runs on a web server & is accessed via a browser doesn't make you special or different.

    Originally posted by tgv View Post
    Will appreciate any answers, recommendations and links. No RTFMs please. Thank you.
    Sorry, you do need to RTFM if you're going to use this or any other tool properly.

    Comment


    • #3
      Thank you for the long reply.

      Please don't get me wrong. I understand our processes are screwed. That's why I'm seeking ways to improve. I am happy to RTFM when I'm sure it's a FM of a right system. We've recently bought a small office server (unix) to set up some kind of version control environment and struggling to find an appropriate one: transparent and visual. Reading (ok, glancing) the svnbook doesn't give me confidence that it's a right choice.

      From what I've gathered on this forum, there's a number of peculiarities in SVN which I am not prepared to immediately accept. Such as -- needing to learn C (or bash) to write hook scripts to eventually do what I'm currently doing with one click. Or manually invoking some perl scripts on the server for svn just to recognise moved/deleted files. Or having my precious file structure infested with .svn folders.

      I sure do test my projects on my workstation first. If an "integration test server" is just another box to repeat the tests I've already done, then I do not understand the point.

      Also, I'm afraid "packaged releases" or "builds" in their traditional meaning are not applicable to our reality. If I want to update just one file, I still want to update one file regardless if it's version is tracked somewhere or not.

      I'm dying to see a setup where a real-world shop similar to ours has successfully implemented and used all this safe-sane-mature stuff.

      Sorry if it's the wrong forum to ask.

      Comment


      • #4
        There is a Subversion plugin for Joomla that can help you put your content from the CMS system into source control. I've never used it so I am not endorsing it (and a google search might discover a better one) but it's a place to start:

        http://www.theartofjoomla.com/home/9...-with-svn.html

        What a lot of web developers do in this situation is create a staged deployment process. Something like this:

        1.) User checks out code to their local drive (pc/mac/desktop/laptop/ipad/ect) and makes changes
        2.) User commits changes to a shared integration space in the source control system (eg; a "QA" branch)
        3.) Testing can occur on the newly introduced changes, this should be coordinated through a task/project/test management system if possible and automated tests like the one's offered by Selenium can help with regression testing (the new stuff doesn't break the old stuff).
        4.) Approved changes are carried forward to a staging or production branch (eg; "trunk") where they can be safely published to your online CMS, this step can even be automated using Subversion post-commit trigger scripts.
        4a.) In the event a change is introduced that causes a catastrophic problem it will be possible to rollback to an earlier version, this will be made easier if you create a tag (or a snapshot) of your trunk on a regular basis.
        4b.) You can control access to the source code repository through security settings to ensure nothing sneaks past you into production, and the source code history provides a reliable audit trail to track the origination of any change.

        The concept of just updating one file on the fly, doing an end-around your in place process for managing change, is probably a bad idea and will lead to regression back into your Cowboy Coding approach which makes it easy to introduce errors into your production environment. Pushing out a quick fix, or a hot fix, is still possible following the same procedure but using the staged releases provides an audit trail, an opportunity to test (run some automated scripts for regression) and after the fix is sent into production you still have the ability to rollback the change in the event the fix causes an even worse problem.

        That's my advice anyway, with web development there is a desire to sacrifice safety and quality for speed and the freedom to change whatever, whenever. This can lead to problems of course as I am sure you've no doubt experienced some. Make your changes locally and allow the Subversion to push out the clean copy (trunk) to the server, don't make any changes on the live production server itself without going through your staged approval process and even though you don't have the concept of 'versions' you can still create daily tags (releases) to capture the state of the clean trunk so you have reliable fallback points in the event disaster strikes.

        One more thing, if you are doing multiple customer variants I would suggest looking into svn externals as a way to share common code between projects.

        Comment


        • #5
          Patrick,

          I appreciate your input. Your advice sounds great. And thank you for the link to the article which made some key points less obscure (but not more attractive unfortunately) -- I still have a feeling that I miss some secret know-hows. Will research and experiment further.

          It somehow disturbs me though that it's a second time in a row when I update the product from your signature, uberSVN, and end up with it crashing beyond repair.

          Comment

          Working...
          X