Using Subversion for Concrete5 development
Permalink
So this has been a bit of an ongoing discussion around the office and I figured it'd be a good idea to include the Concrete5 community to maybe get a better solution.
Here's our development flow. We develop on a dev server that is essentially a mirror of a web server. When we're ready to go live (or add content anyway) we add the project to an svn repository. We then checkout the site on the live web server, sometimes using a preview subdomain as a place to demo the site to clients while content is still being added and changes made.
The problem is that svn requires .svn folders in every directory of a working copy, and there is an ugly mess of half added files when you try to add when some areas are owned by the apache user (files, config).
The most obvious approach is to add our dev crew to the apache user's group and set everything to group writeable. So that you don't have to chmod before every commit, we would also want to set the apache user's umask to 0002.
Still there's the issue manually uploading files that concrete5 creates and fixing errors when it gets rid of them. I've been trying to set up an ignore on these directories, but I don't think it's working right.
If we could control the URLs of media, and maybe make changes to a template's CSS, it would be make this a null issue since it's no big deal to tell our developers to be a little more specific when committing and updating, but our content people use a tool that runs an update on a site root.
Sorry for the long post, but I wanted to try and provide as much information as possible. Anyone else use svn with Conrete5? There's several solutions but I'd rather know one that already works instead of going down a random path just to find more roadblocks, and it'd be great to know which one results in the easiest production flow.
Cheers
Here's our development flow. We develop on a dev server that is essentially a mirror of a web server. When we're ready to go live (or add content anyway) we add the project to an svn repository. We then checkout the site on the live web server, sometimes using a preview subdomain as a place to demo the site to clients while content is still being added and changes made.
The problem is that svn requires .svn folders in every directory of a working copy, and there is an ugly mess of half added files when you try to add when some areas are owned by the apache user (files, config).
The most obvious approach is to add our dev crew to the apache user's group and set everything to group writeable. So that you don't have to chmod before every commit, we would also want to set the apache user's umask to 0002.
Still there's the issue manually uploading files that concrete5 creates and fixing errors when it gets rid of them. I've been trying to set up an ignore on these directories, but I don't think it's working right.
If we could control the URLs of media, and maybe make changes to a template's CSS, it would be make this a null issue since it's no big deal to tell our developers to be a little more specific when committing and updating, but our content people use a tool that runs an update on a site root.
Sorry for the long post, but I wanted to try and provide as much information as possible. Anyone else use svn with Conrete5? There's several solutions but I'd rather know one that already works instead of going down a random path just to find more roadblocks, and it'd be great to know which one results in the easiest production flow.
Cheers
Our process is similar to yours except that we share the development server, it's necessary in order to work quickly on some older, much larger sites. Our dev server usually points to the same DB as our live server unless there's a reason not to. We still do the hosts and apache entries.
I like your process, it seems cleaner. With that said, I'm nervous that it might take longer than is warranted as most of our changes are just adding photos or quick template tweaks, by just one developer at a time. Also, svn exporting would take a site offline for too long unless we were to set up some sort of rsync server at our data center (we're in Saint Paul, the Live servers are in Minneapolis).
One possible solution I can think of is: When we're ready to svn add a site, copy everything in the apache writable folders somewhere else. Run the svn add/commit and then commit with those folders empty. After that set svn to ignore those folders and files. With the ignore committed, I should be able to copy those files back in and then checkout on to the webserver, and copy those files there as well.
The advantage is that then you really only have to get complicated just the one time, and that will always be a more experienced developer. Then, "content people" and newer developers just have to worry about adding and committing changes and updating on the live server when they're done. Seems to be the fastest way overall. I think the big difference we have is that we almost never have multiple developers working on a site at once. In theory, that should allow us to skip a step from your process.
Can you think of any pitfalls to that idea?
I like your process, it seems cleaner. With that said, I'm nervous that it might take longer than is warranted as most of our changes are just adding photos or quick template tweaks, by just one developer at a time. Also, svn exporting would take a site offline for too long unless we were to set up some sort of rsync server at our data center (we're in Saint Paul, the Live servers are in Minneapolis).
One possible solution I can think of is: When we're ready to svn add a site, copy everything in the apache writable folders somewhere else. Run the svn add/commit and then commit with those folders empty. After that set svn to ignore those folders and files. With the ignore committed, I should be able to copy those files back in and then checkout on to the webserver, and copy those files there as well.
The advantage is that then you really only have to get complicated just the one time, and that will always be a more experienced developer. Then, "content people" and newer developers just have to worry about adding and committing changes and updating on the live server when they're done. Seems to be the fastest way overall. I think the big difference we have is that we almost never have multiple developers working on a site at once. In theory, that should allow us to skip a step from your process.
Can you think of any pitfalls to that idea?
So this post is probably dead, but I just wanted to post an update in case anyone stumbles upon it in the future.
Two of us at work have started developing on our local machines and then moving over to a dev server to test things out before finally moving over to our web server. We're probably gonna stick with svn for all of these moves but using rsync to go between the staging server and live server is really just an issue of preference it seems. Setting ignore (or just never adding) on the contents of apache writable directories and files unique to the machine it's on (config files) is deffinately the easiest way to go. then just copy back those directories as needed to your local or staging area.
Personally i use textmate, coda, and on rare occasion (usually just sites we take over that were built using it) dreamweaver. All of these tools seem to be built with a situation similar to this in mind. It's easiest just to go with the flow.
ciao
Two of us at work have started developing on our local machines and then moving over to a dev server to test things out before finally moving over to our web server. We're probably gonna stick with svn for all of these moves but using rsync to go between the staging server and live server is really just an issue of preference it seems. Setting ignore (or just never adding) on the contents of apache writable directories and files unique to the machine it's on (config files) is deffinately the easiest way to go. then just copy back those directories as needed to your local or staging area.
Personally i use textmate, coda, and on rare occasion (usually just sites we take over that were built using it) dreamweaver. All of these tools seem to be built with a situation similar to this in mind. It's easiest just to go with the flow.
ciao
1. Each developer, since they are blessed with a machine that can run a LAMP stack (most of us have Macs but the Windows guys run apache/php/mysql and it seems to work just fine.) We all setup a site locally, by modifying our own apache entries and setting up local faux domains in our /etc/hosts files. We then add the site into subversion, and each person checks out the site into their own machine.
So, if the site is "Widgets Inc." I'll add an entry in my /etc/hosts file for widgetsinc.dev, which points to 127.0.0.1. Then, I'll add a virtual host entry in httpd.conf on my local machine pointing widgetsinc.dev to wherever I've got my copy of the code base checked out (/Users/andrew/svn/widgetsinc/trunk/web/, for example.)
2. Then, I can develop my local code in my copy of the Widgets Inc. code base, and commit my changes back to the repository. Anyone else working on stuff for the site can update, and pull them into their own local environment.
3. When we're ready to push stuff to a public dev/testing server, we will for do an svn export, to get a nice, pristine copy of our code (without .svn directories).
svn export /Users/andrew/svn/widgetsinc/trunk/web ./public_site
Then, we'll use rsync to push the code to the live site
rsync -ave ssh public_site/ myuser@myhost:/path/to/widgetsinc/public_html/
4. Then, testers and content people can work on the public site, adding content, while others work on their own dev environment. Periodically, step three is repeated to update the live environment.
5. On complex sites, it's frequently useful to bring database changes back down to the developers. To do this, we will export our database from the live site, and check it into subversion, and the developers can update their local databases from it. Finally, config/site.php, which isn't really meant to be shared, CAN be shared by separating all config items within it inside a switch statement.