Since umbraco writes to the db a lot and to disk, it would seem like doing a db compare between 2 different environments and then updating a target environment with the changes is not a good idea or is it? Let's assume I have a local db and a stage db. During development, the local db is updated by 2 devs (editing templates, adding properties to doc types, etc). When deploying to stage, the idea is to compare local db with stage db and run the sql scripts into a post deployment process. For some reason, I don't have a good feeling about this and was curious if it was a good approach or not?
I do use courier and find it very helpful and I also have started using uSync which seems like a very good solution.
I tend to deploy structural changes manually (e.g., adding a property to a document type). This usually takes relatively little time in comparison to the development surrounding those structural changes, and I can often make the structural changes before actually deploying any code (unless the structural changes are destructive, such as deleting or renaming properties).
For content, I just keep each environment separate with their own content. If I ever need some better content on staging, I'll backup prod and restore to the staging server (effectively overwriting the entire DB).
For clients who need a staging environment to develop their content before going to production, I use Courier (though, I have found it to be not all that enjoyable to use, given its many quirks and troublesome history). The necessity for Courier seems rare.
While I haven't tried it, Umbraco as a Service apparently offers quite a bit in terms of synchronizing data across various environments. I believe they use some derived version of Courier and they refer to that as "Umbraco Deploy" (a bit like how they refer to the successor to Contour as "Umbraco Forms").
When you say you deploy structural changes manually, do you mean you mean you login to umbraco on the target environment and manually create or run some script?
I guess if you restore the entire db from prod to stage, you wouldn't need to worry about ids, right? Why do you back up prod if you are overwriting stage?
I personally haven't had too many issues with courier. I tend to only courier over the specifics, meaning that if I make a change to a doc type, I will try to just courier the doc type and not the node the doc type it is associate with. Similar to you, if things are deleted, I will usually do this after a code deploy or do it manually (login to umbraco on prod).
I haven't used Umbraco As A Service either. Have you had tried uSync? It seems to work well. From what I gather, it does not delete existing propeties on doctypes, but imports and adds new ones.
So as far as do a database compare, what did you think about that?
When you say you deploy structural changes manually, do you mean you mean you login to umbraco on the target environment and manually create or run some script?
I mean that I log into Umbraco and go to the Settings section to modify the document type, for example.
if you restore the entire db from prod to stage, you wouldn't need to worry about ids, right?
Correct, ID's would be identical between all environments were you to have effectively identical databases.
Why do you back up prod if you are overwriting stage?
I back up prod in order to create the .bak file that I subsequently use as the source of the restore to staging.
So as far as do a database compare, what did you think about that?
You could do that if you are comfortable with the Umbraco database structure. I have had coworkers do that. As with any of these approaches, you should republish the XML cache and rebuild the Examine indexes afterward.
Also, you might want to copy media (typically stored in the media folder on the file system) from one environment to another.
You are probably better at Umbraco than me. Would you say you are comfortable with the structure of the db?
If you did a script deploy, would you need to do a full one to keep the ids in sync or could it be a partial update and as you mentioned just do a republish (is this the same as right clicking on the site and clicking publish?)
Should I do a data compare between umbraco db's on different environments to keep them in sync?
Hi
Since umbraco writes to the db a lot and to disk, it would seem like doing a db compare between 2 different environments and then updating a target environment with the changes is not a good idea or is it? Let's assume I have a local db and a stage db. During development, the local db is updated by 2 devs (editing templates, adding properties to doc types, etc). When deploying to stage, the idea is to compare local db with stage db and run the sql scripts into a post deployment process. For some reason, I don't have a good feeling about this and was curious if it was a good approach or not?
I do use courier and find it very helpful and I also have started using uSync which seems like a very good solution.
Thanks Saied
I tend to deploy structural changes manually (e.g., adding a property to a document type). This usually takes relatively little time in comparison to the development surrounding those structural changes, and I can often make the structural changes before actually deploying any code (unless the structural changes are destructive, such as deleting or renaming properties).
For content, I just keep each environment separate with their own content. If I ever need some better content on staging, I'll backup prod and restore to the staging server (effectively overwriting the entire DB).
For clients who need a staging environment to develop their content before going to production, I use Courier (though, I have found it to be not all that enjoyable to use, given its many quirks and troublesome history). The necessity for Courier seems rare.
While I haven't tried it, Umbraco as a Service apparently offers quite a bit in terms of synchronizing data across various environments. I believe they use some derived version of Courier and they refer to that as "Umbraco Deploy" (a bit like how they refer to the successor to Contour as "Umbraco Forms").
Hi Nicholas,
When you say you deploy structural changes manually, do you mean you mean you login to umbraco on the target environment and manually create or run some script?
I guess if you restore the entire db from prod to stage, you wouldn't need to worry about ids, right? Why do you back up prod if you are overwriting stage?
I personally haven't had too many issues with courier. I tend to only courier over the specifics, meaning that if I make a change to a doc type, I will try to just courier the doc type and not the node the doc type it is associate with. Similar to you, if things are deleted, I will usually do this after a code deploy or do it manually (login to umbraco on prod).
I haven't used Umbraco As A Service either. Have you had tried uSync? It seems to work well. From what I gather, it does not delete existing propeties on doctypes, but imports and adds new ones.
So as far as do a database compare, what did you think about that?
Thanks, Saied
I mean that I log into Umbraco and go to the Settings section to modify the document type, for example.
Correct, ID's would be identical between all environments were you to have effectively identical databases.
I back up prod in order to create the
.bakfile that I subsequently use as the source of the restore to staging.You could do that if you are comfortable with the Umbraco database structure. I have had coworkers do that. As with any of these approaches, you should republish the XML cache and rebuild the Examine indexes afterward.
Also, you might want to copy media (typically stored in the media folder on the file system) from one environment to another.
Thanks Nicholas,
You are probably better at Umbraco than me. Would you say you are comfortable with the structure of the db?
If you did a script deploy, would you need to do a full one to keep the ids in sync or could it be a partial update and as you mentioned just do a republish (is this the same as right clicking on the site and clicking publish?)
is working on a reply...