Discussing Umbraco and staging with a customer, and we don't understand why the production site can't just be "clobbered" via xcopy and a DB overwrite. I understand if the site is really big, then sync might become a large issue (no one wants to copy 1GB of data around on each publish). But if the site is only, say, 30MB or so, can't we just overwrite the production site's content nodes wholesale? What kind of issues will we run into if we go down that road?
I think the issues come with deploying mulitple changesets down the road. For a first launch, you're right, a brute force method will work. My team does just that, but using Mercurial for the update.
But later, you may want to stage changes for either large amounts of content, new code, or both, after synching the production content back to staging. It's probably all possible the brute force way, but it's a lot easier to sync back and forth with a proprietary tool like Courier. Plus, not all devs/editors who may want to stage/deploy code or content may have DB access or knowledge.
Well the content would only flow from staging->production. We'd write a powershell script to just clobber the production site with the staging data. If we don't need two-way sync'ing, can we successfully avoid Courier?
I ask because Courier doesn't work with u7. Which seems to tell me that Courier must do a LOT of stuff, if the Umbraco people can't get it working with u7 which supposedly is the same engine as u6. And if this is their day job and Courier takes all this work, then it can't be as easy as xcopy or people wouldn't pay for it.
Michael - if content is only flowing from staging -> production then theres no problem in just deploying files and updating the database, see no issue in doing it that way.
Courier is made for partial deployments, so in case you only want to deploy parts of a site, or just add an extra property to a document type or something like that, and you can have made changes on production which wont be overridden.
We do actually have a working courier version internally, it needed a couple of changes in its database schema, but other then that, its working just fine, the reason we havnt released it, is because of the UI intergration part not being done yet.
Resourses are spent on 7.0.x updates, 6.2 and 7.1 releases, so its not like its taken us 2 months of non-stop work to get courier working, its resource prioritising.
Thanks for the answer. One thing I thought of: What if the production site has new members registering? Won't they potentially get node IDs that conflict with new content nodes created? Is the overwrite method only suitable for totally readonly production site?
yup, you'll get nodeID conflicts - if you want a readonly production environment, and need members, then I would use a seperate membership provider for member data
Are there any other features we'd have to avoid or beware of that might create conflicts of some sort? Or are members the only one to watch out for? We can get around that just by using ASP.NET membership provider, I think.
Why is Courier needed for staging?
Discussing Umbraco and staging with a customer, and we don't understand why the production site can't just be "clobbered" via xcopy and a DB overwrite. I understand if the site is really big, then sync might become a large issue (no one wants to copy 1GB of data around on each publish). But if the site is only, say, 30MB or so, can't we just overwrite the production site's content nodes wholesale? What kind of issues will we run into if we go down that road?
I think the issues come with deploying mulitple changesets down the road. For a first launch, you're right, a brute force method will work. My team does just that, but using Mercurial for the update.
But later, you may want to stage changes for either large amounts of content, new code, or both, after synching the production content back to staging. It's probably all possible the brute force way, but it's a lot easier to sync back and forth with a proprietary tool like Courier. Plus, not all devs/editors who may want to stage/deploy code or content may have DB access or knowledge.
Well the content would only flow from staging->production. We'd write a powershell script to just clobber the production site with the staging data. If we don't need two-way sync'ing, can we successfully avoid Courier?
I ask because Courier doesn't work with u7. Which seems to tell me that Courier must do a LOT of stuff, if the Umbraco people can't get it working with u7 which supposedly is the same engine as u6. And if this is their day job and Courier takes all this work, then it can't be as easy as xcopy or people wouldn't pay for it.
Michael - if content is only flowing from staging -> production then theres no problem in just deploying files and updating the database, see no issue in doing it that way.
Courier is made for partial deployments, so in case you only want to deploy parts of a site, or just add an extra property to a document type or something like that, and you can have made changes on production which wont be overridden.
We do actually have a working courier version internally, it needed a couple of changes in its database schema, but other then that, its working just fine, the reason we havnt released it, is because of the UI intergration part not being done yet.
Resourses are spent on 7.0.x updates, 6.2 and 7.1 releases, so its not like its taken us 2 months of non-stop work to get courier working, its resource prioritising.
Thanks for the answer. One thing I thought of: What if the production site has new members registering? Won't they potentially get node IDs that conflict with new content nodes created? Is the overwrite method only suitable for totally readonly production site?
yup, you'll get nodeID conflicts - if you want a readonly production environment, and need members, then I would use a seperate membership provider for member data
Are there any other features we'd have to avoid or beware of that might create conflicts of some sort? Or are members the only one to watch out for? We can get around that just by using ASP.NET membership provider, I think.
is working on a reply...