Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Our development team has a live server hosted in a data centre, as well as a dev and staging server onsite

All machines are running Debian 5, PHP, MySQL

We have Subversion running on the development box

We use Dreamweaver CS5

As I understand it, Dreamweaver can connect to the subversion reposity and manage checking/checking out etc, we can also specify connections to the staging and production server

I am trying to get my head around the work flow, essentially our guys will work on local copies of files, will they lock the file/s they are working on, then commit the changes when complete?

Then, when complete and tested, Dreamweaver can upload to staging for further testing, then when done again Dreamweaver can upload to production.

Is this a resonable way to work?

Am I missing something here?

Could someone give me a run down?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

Here's how I do it:

We use Subversion on our dev box. Everything gets checked in: documentation, config, source code, graphics, you name it. Dreamweaver would check in/out on the development box only in this scenario. Also checked in is a build script, which copies everything out to the root, sets ownerships and permissions, and reloads the daemons. This is great, because the developers have sudo privs to run it whenever they want.

To promote, we use a simple little script that does an 'svn export' to a tarball. The tarball gets manually moved to production, unpacked, and an admin runs the build script.

Totally repeatable and reliable. It makes me happy everytime we use it.

share|improve this answer
    
When you say copies everything to root, do you mean the document root? And therefore makes makes "live" on the dev box? –  Tim Sep 4 '10 at 13:25
    
No, to the OS root. That happens to include the DocRoot though. Since the whole project is checked in, there are all sorts of other things that need to get laid down: source code, documentation, utility scripts, developer notes, cron jobs, you name it. Our goal is to have "vendor_build + subversion_repo = working machine". –  pboin Sep 9 '10 at 17:10
    
@pboin, hopefully you're still active here, as this answer is pretty old now. I'm trying to do the same thing - use Dreamweaver to push updated content from SVN to production. Is this still your workflow? Or is there a way in CS5 and/or CS6 to mange an SVN update directly without having to TS into the server and do it with TortoiseSVN? –  kristina childs Apr 23 '13 at 18:47

I am trying to get my head around the work flow, essentially our guys will work on local copies of files, will they lock the file/s they are working on, then commit the changes when complete?

Appears that Dreamweaver doesn't force you to lock the files (we don't use it with Subversion). This works because Subversion has the ability to merge commits. However if in some cases when a merge can not be cleanly done Subversion will give you a conflict message requiring attention (when updating) or block your commit. These alerts should be shown and able to be handled by the Dreamweaver GUI.

Then, when complete and tested, Dreamweaver can upload to staging for further testing, then when done again Dreamweaver can upload to production. Is this a resonable way to work?

It may be. In our similar app deployment setup (dev, staging, production) there is no syncing from dev to production. The sync to production is only from whatever is on staging as that is what has been tested and approved by the client. We do it this way to avoid any potential of an erroneous change finding it's way on production.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.