Chip, Insightful post, thanks. One thing that caught my eye is exporting to a staging server calling 'svn checkout', shouldn't you 'svn export' that instead? Checking out files also exports a flurry of .svn folders for local version tracking, but exporting gives you a clean directory structure. Perhaps that's what the 'checkout release' does? I haven't seen or played with that feature.
-nathan strutz http://www.dopefly.com/ Chip temm wrote: >Hi Russ, > > >Does Homesite+/CFStudio have any CVS support (especially for subversion?). > >We're planning to move to SVN from developing from ftp, but wondering how > to > >set the whole thing up. > >Bunch of ways to do this with Homesite. The easiest I know of is to use >TortoiseSVN. From Homesite, all of the Tortoise right-click menus will be >available in the directory browsing pane (but NOT in the file browser below >it). When you change a file and want to update your server version, right >click its parent directory and COMMIT. Simple. If you want to use Homesite's >Project-thingy with its source control integration, you will have to install >something like Jalinidi Igloo which emulates SourceSafe's API (called SCC). >Hasn't been worth it for me. SO, that's the client side.... > > >We have a development server, where all the changes are made and tested by > >editing the files directly through ftp and testing them through the web > >browser. When they're ready, we ftp them over to the production server and > >use Araxis Merge to compare the changes with the old files and merge them > >(just for safety, and also certain files only get parts of them deployed, > >such as the cfc files which contain all the DAO logic). > >How can we make this type of set up work with SVN? I mean if we retrieve a > >file from CVS through Homesite+ or CFEClipse, how do we save the file to > the > >dev server so that we can test it, and then when we're done, how do we > >deploy the changes to production? Is this even possible? > >Russ >The environment >Here's the thing: you need to think about source control a bit differently >than you thought about the FTP method you setup. Ideally, you would have a >souce control server, a staging server (you call that dev server above), a >production server and your local development machine. > >Developing >You develop on a local standalone CF server- you should be able to test >anything here (except load) that you can test on your staging server. When you >are happy with a certain file (or directory), you commit it to your SVN >repository. On the SVN machine there is no web server, cf server, whatever- >it is just a place to keep track of your changes and make sure that if >everything else blows up you keep your job. > >Deploying to staging >When you want to deploy the code to staging (to demo for a client, beta test, >whatever) you go to the staging box and use tortoise (or a shell script call >to cvsnt) to UPDATE (or if this is the first deployment CHECKOUT) the code >from the SVN box. If you are strict, you will include in your staging >deployment process a step to encrypt your CF code. This keeps you honest and >doesn't allow you to make code changes on staging (from where you would likely >forget to commit them). In fact, you should really do a CHECKOUT RELEASE >(this is TortoiseCVS terminology- may be different on SVN) which ensures that >your fresh files are not COMMITable from their new home. > >Deploying to production >Same as deploying to staging. You don't move a thing from staging. You don't >have to. All of your changes are in SVN right? If your deployment to staging >worked and all other environment variables are the same, your deployment to >production will be as simple as pie. > >Using CF Enterprise to help >You could alternately create a CAR on Staging when you are ready to deploy and >push that to Production. This is an additional insurance that the deployment >is a success as the CAR wraps up all the CF server settings nicely for you: >when you restore the CAR on the target, CF is setup exactly as it was on the >source server. > >Saving money >If you don't have an extra server for the source control, no prob. Use your >staging box- but do NOT put your SVN repository in the webroot. The key is to >keep source control separate from the normal running location of your apps. > >Scripting it all >You could setup all of this to run as batch files in windows or linux. The >staging process could be scheduled. You could trigger the running of the >staging deployment by calling a CF page with a CFExecute that runs the batch >file. If you are extra crafty you might use a nifty new CF Gateway to watch >for some file system chage or listen for a ping from somewhere to tell it to >run and get the latest release.... > >You're on the right path- it is less complicated than it sounds! >Cheers >Chip Temm > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:209313 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
