Re: [wdvltalk] Change management/source control mindbenders
On 28/09/06, Matthew Macdonald-Wallace [EMAIL PROTECTED] wrote: Quoting Furry, Tim [EMAIL PROTECTED]: If any of you have had experience with multi-developer change management/source control systems for web development, please contact me via email offlist if you don't mind sharing your knowledge. I find myself responsible for setting a similar system up with a couple of constraints that are driving me nuts. I don't quite understand how normal change management/build systems can apply to typical web development... Any reason why thius can't be done on-list? I for one would certainly welcome a discussion on this, it's something I've had an issue with in the past and I'm sure I'll encounter it again in the future! Likewise, I think this is relevant to us all. I now use Subversion (svn), but I'm no expert with it yet. One approach I could think of is having a dev server where: a) you check out a working copy of the website into a directory that Apache is configured to serve, on a certain port number; b) when your changes are done, you commit them to the repository c) the changes are then automatically transferred to a staging copy of the site (served by Apache on another port number, for final approval before golive). The automatic copy could be as crude as a cron job that does svn export every 10 minutes, or better, use svn's hooks to run a script on commit that would copy the changed files over only and for extra slickness, generate a shell script you can run to upload just those files to the production server. When there's multiple developers, each developer has their own working copy, served by Apache on a different port, so they can work independent of the other developers. Of course, there's a fair bit of duplication there, but unless you're working on a HUGE website it's unlikely to be a problem. That sounds like it might work for me. Perhaps I should try it out then write it up on my litle wiki - I've got some basic details of subversion already at: http://wiki.preshweb.co.uk/doku.php?id=svn:basicguide and http://wiki.preshweb.co.uk/doku.php?id=svn:propset Cheers Dave P The WDVL Discussion List from WDVL.COM To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED] or use the web interface http://e-newsletters.internet.com/discussionlists.html/ Send Your Posts To: wdvltalk@lists.wdvl.com To change subscription settings, add a password or view the web interface: http://intm-dl.sparklist.com/read/?forum=wdvltalk http://www.wdvl.com ___ You are currently subscribed to wdvltalk as: archive@jab.org To unsubscribe send a blank email to [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
Re:[wdvltalk] Change management/source control mindbenders
I wrote previously: If any of you have had experience with multi-developer change management/source control systems for web development, please contact me via email offlist if you don't mind sharing your knowledge. I find myself responsible for setting a similar system up with a couple of constraints that are driving me nuts. I don't quite understand how normal change management/build systems can apply to typical web development... Matt responded: Any reason why this can't be done on-list? I for one would certainly welcome a discussion on this,... So I continue on: Well, okay, I'll lay out the complications and you guys can feel sorry for me. :-) 1. I work in a mixed environment. My machine is Windows XP, using Dreamweaver/PHP for development (I'm fine with that, although PHP and Dreamweaver are both new to me). 2. All the websites I'll be working on are internal in nature. Corporate rules forbid localhost servers, meaning I can't build and test my stuff using IIS off my machine (well, I can, but only I can see it...the firewall prevents anyone, including my boss, from seeing my work if I do it that way). All internal websites are served using a Unix machine running Apache; it's set up with specific website folders, and also to recognize public_html folders under each user (that's new to me, coming from a Windows world); I can copy my files out to my user area on that machine and see them fine. In fact, Dreamweaver sets up beautifully to do that, using either FTP or Samba shares against my Unix public_html folder. No problems so far...change things in DW, save the changes, the changes are instantaneous in my public_html folder, and I just refresh my browser pointed to that page. 3. I don't have any control over the Unix box. In fact, it looks like the people who do are fairly unresponsive (I asked for PHP5 to be loaded several weeks ago and it still needs to be done). So I have limited control over directory structure and no control over Apache (which is essentially fine with me). 4. Internal web development needs to be under change/source management. They want to use a tool they've already invested in (Telelogic's Synergy), which is geared more towards a normal development environment of (non-web) software builds (i.e. regular developers use checkout/checkin/local work areas on the Unix box through terminal emulators to make their changes, do local builds, etc., and the tool is smart enough to pull files needed from the trunk and use local work area changed files to produce a modified build for local testing). Up to this point, internal web development has not been terribly structured and is usually done by interns working over the summer. I'm the first full-time hire to handle the needs. Development was usually done against live sites as the only working copy. What I'd like to get to is a separate Unix development directory with limited access privileges, checkin/checkout processes, rollbacks and diffs and versioning and tags; along with a live area where tagged builds are copied to for release to the general users. I can't use Subversion or other tools that are normally bent to shape for web development (gotta use the Synergy). There will be multiple web devs from multiple locations working on some of the stuff at any given time. I think Synergy is a fairly typical CM system, so I think it will eventually work. My understanding of the existing model is: 1. a (non-web) developer gets assigned a task/bug/fix 2. he/she checks out appropriate files from Synergy; there are scripts in place that essentially make complete copies of the trunk files into the developer's own private work area (on the Unix box); checking out files makes the local files of interest writable (all others are read-only so that changes cannot be made without effort). Changes are made to the checked-out files and a local build is run to produce a testable product, still all located in the developer's private work area. When the build is successful and the changes are approved, the files are checked in (made readable locally), and changes are merged back into the trunk codebase to be included in the next formal library build. Obviously a local build doesn't really care where it is located in the file system; it can be anywhere the developer has control (i.e. his/her work area). 3. web projects must be located somewhere in the file system that Apache is already set up to serve...which means that if I set up a development directory in the file system, I'll want it served up by Apache (no problem so far). But what I want is for the development versions of my web pages to exist in that single development area, not in my work area...i.e. a checkout process should make the file writable but *keep it in the development area that can be served as web*, not in my local work area. In other words, when I open a web page to work on in Dreamweaver, I want the changes to flow directly into the file in the work area on the
RE: [wdvltalk] Change management/source control mindbenders
Tim, Think of public_html as wwwroot. I know many who are not willing to install PHP 5 on production servers. Haven't nor have any of the hosts we use. At our local user group we had a commercial host come and give a presentation on their experience with PHP 5 on their test server. They reverted to 4. Working on live sites? Are they crazy? Cheryl D Wise MS MVP FrontPage http://by-expression.com Online instructor led training http://starttoweb.com -Original Message- From: Furry, Tim [mailto:[EMAIL PROTECTED] 1. I work in a mixed environment. My machine is Windows XP, using Dreamweaver/PHP for development (I'm fine with that, although PHP and Dreamweaver are both new to me). 2. All the websites I'll be working on are internal in nature. Corporate rules forbid localhost servers, meaning I can't build and test my stuff using IIS off my machine (well, I can, but only I can see it...the firewall prevents anyone, including my boss, from seeing my work if I do it that way). All internal websites are served using a Unix machine running Apache; it's set up with specific website folders, and also to recognize public_html folders under each user (that's new to me, coming from a Windows world); I can copy my files out to my user area on that machine and see them fine. In fact, Dreamweaver sets up beautifully to do that, using either FTP or Samba shares against my Unix public_html folder. No problems so far...change things in DW, save the changes, the changes are instantaneous in my public_html folder, and I just refresh my browser pointed to that page. 3. I don't have any control over the Unix box. In fact, it looks like the people who do are fairly unresponsive (I asked for PHP5 to be loaded several weeks ago and it still needs to be done). So I have limited control over directory structure and no control over Apache (which is essentially fine with me). 4. Internal web development needs to be under change/source management. They want to use a tool they've already invested in (Telelogic's Synergy), which is geared more towards a normal development environment of (non-web) software builds (i.e. regular developers use checkout/checkin/local work areas on the Unix box through terminal emulators to make their changes, do local builds, etc., and the tool is smart enough to pull files needed from the trunk and use local work area changed files to produce a modified build for local testing). Up to this point, internal web development has not been terribly structured and is usually done by interns working over the summer. I'm the first full-time hire to handle the needs. Development was usually done against live sites as the only working copy. What I'd like to get to is a separate Unix development directory with limited access privileges, checkin/checkout processes, rollbacks and diffs and versioning and tags; along with a live area where tagged builds are copied to for release to the general users. I can't use Subversion or other tools that are normally bent to shape for web development (gotta use the Synergy). There will be multiple web devs from multiple locations working on some of the stuff at any given time. The WDVL Discussion List from WDVL.COM To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED] or use the web interface http://e-newsletters.internet.com/discussionlists.html/ Send Your Posts To: wdvltalk@lists.wdvl.com To change subscription settings, add a password or view the web interface: http://intm-dl.sparklist.com/read/?forum=wdvltalk http://www.wdvl.com ___ You are currently subscribed to wdvltalk as: archive@jab.org To unsubscribe send a blank email to [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
Re: [wdvltalk] Change management/source control mindbenders
Hi Tim, I worked in setup similiar to this last year, only it was Zend/PHP. They had a development server with a main test site and public_html for individual developers. They used CVS (I'm not familiar with Synergy). What I did was telnet to the dev server checkout what I needed, point Zend to the files in public_html, make my changes, test them. When done, I'd telnet back for the checkin. I seem to recall that it would have been possible to do the checkin/checkout on public_html through Window's File Manager, but being used to Linux command line I just interacted with CVS directly. I guess I'm not really understanding what your specific problem is. Sheila Furry, Tim wrote: 1. I work in a mixed environment. My machine is Windows XP, using Dreamweaver/PHP for development (I'm fine with that, although PHP and Dreamweaver are both new to me). 2.All internal websites are served using a Unix machine running Apache; it's set up with specific website folders, and also to recognize public_html folders under each user (that's new to me, coming from a Windows world); I can copy my files out to my user area on that machine and see them fine. In fact, Dreamweaver sets up beautifully to do that, using either FTP or Samba shares against my Unix public_html folder. No problems so far...change things in DW, save the changes, the changes are instantaneous in my public_html folder, and I just refresh my browser pointed to that page. 3. I don't have any control over the Unix box. In fact, it looks like the people who do are fairly unresponsive (I asked for PHP5 to be loaded several weeks ago and it still needs to be done). So I have limited control over directory structure and no control over Apache (which is essentially fine with me). 4. Internal web development needs to be under change/source management. They want to use a tool they've already invested in (Telelogic's Synergy), which is geared more towards a normal development environment of (non-web) software builds (i.e. regular developers use checkout/checkin/local work areas on the Unix box through terminal emulators to make their changes, do local builds, etc., and the tool is smart enough to pull files needed from the trunk and use local work area changed files to produce a modified build for local testing). What I'd like to get to is a separate Unix development directory with limited access privileges, checkin/checkout processes, rollbacks and diffs and versioning and tags; along with a live area where tagged builds are copied to for release to the general users. I can't use Subversion or other tools that are normally bent to shape for web development (gotta use the Synergy). There will be multiple web devs from multiple locations working on some of the stuff at any given time. I think Synergy is a fairly typical CM system, so I think it will eventually work. My understanding of the existing model is: 1. a (non-web) developer gets assigned a task/bug/fix 2. he/she checks out appropriate files from Synergy; there are scripts in place that essentially make complete copies of the trunk files into the developer's own private work area (on the Unix box); checking out files makes the local files of interest writable (all others are read-only so that changes cannot be made without effort). Changes are made to the checked-out files and a local build is run to produce a testable product, still all located in the developer's private work area. When the build is successful and the changes are approved, the files are checked in (made readable locally), and changes are merged back into the trunk codebase to be included in the next formal library build. Obviously a local build doesn't really care where it is located in the file system; it can be anywhere the developer has control (i.e. his/her work area). 3. web projects must be located somewhere in the file system that Apache is already set up to serve...which means that if I set up a development directory in the file system, I'll want it served up by Apache (no problem so far). But what I want is for the development versions of my web pages to exist in that single development area, not in my work area...i.e. a checkout process should make the file writable but *keep it in the development area that can be served as web*, not in my local work area. In other words, when I open a web page to work on in Dreamweaver, I want the changes to flow directly into the file in the work area on the Unix box (which I know can work based on my experiments with my public_html folder)...but this is where all the research I've done fails to mention exactly how a source management tool keeps a web development project *in one place* so changes can be observed immediately, rather than having to checkout a file, make a minor twiddly change, checkin the file, push some sort of build button (that does who knows what, for a website), then refresh the test browser to see if the fix worked...I don't want to do a build
