How does Sitecore handle serialization with TDS?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
My apologies for the vagueness of that question, but I'm not sure how else to pose it. Here is the situation. We have a Sitecore 8 project that uses TDS for syncing items. We have a policy of not adding most content into TDS, only one-off structural items are to be added, otherwise it's only templates and renderings and whatnot. One of the content items we do have in TDS is the main homepage item which apparently mistakenly got set to "AlwaysUpdate." We have the TDS project set to "disable file deployment."
Last night we did a deploy to production and verified that the site was correct. It was also verified to be correct this morning. This afternoon, the homepage had magically reverted to an older state (values on some fields were changed and a few components went missing). I looked on the file system and sure enough, there was a "sitehome.item" file sitting in the /data/serialization/master/content folder that has a timestamp of our deploy the night before. I'm not surprised by this since the item was set to "AlwaysUpdate," though I thought "disable file deployment" would have stopped this from being uploaded.
What I am surprised at is how the site was seemingly fine all day, and then all of a sudden seemed to not only install the sitehome.item file back into the database, but also publish itself to the CD.
Does Sitecore monitor that serialization folder on a schedule job and import that data back into the system somehow?
tds serialization
add a comment |
up vote
2
down vote
favorite
My apologies for the vagueness of that question, but I'm not sure how else to pose it. Here is the situation. We have a Sitecore 8 project that uses TDS for syncing items. We have a policy of not adding most content into TDS, only one-off structural items are to be added, otherwise it's only templates and renderings and whatnot. One of the content items we do have in TDS is the main homepage item which apparently mistakenly got set to "AlwaysUpdate." We have the TDS project set to "disable file deployment."
Last night we did a deploy to production and verified that the site was correct. It was also verified to be correct this morning. This afternoon, the homepage had magically reverted to an older state (values on some fields were changed and a few components went missing). I looked on the file system and sure enough, there was a "sitehome.item" file sitting in the /data/serialization/master/content folder that has a timestamp of our deploy the night before. I'm not surprised by this since the item was set to "AlwaysUpdate," though I thought "disable file deployment" would have stopped this from being uploaded.
What I am surprised at is how the site was seemingly fine all day, and then all of a sudden seemed to not only install the sitehome.item file back into the database, but also publish itself to the CD.
Does Sitecore monitor that serialization folder on a schedule job and import that data back into the system somehow?
tds serialization
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
My apologies for the vagueness of that question, but I'm not sure how else to pose it. Here is the situation. We have a Sitecore 8 project that uses TDS for syncing items. We have a policy of not adding most content into TDS, only one-off structural items are to be added, otherwise it's only templates and renderings and whatnot. One of the content items we do have in TDS is the main homepage item which apparently mistakenly got set to "AlwaysUpdate." We have the TDS project set to "disable file deployment."
Last night we did a deploy to production and verified that the site was correct. It was also verified to be correct this morning. This afternoon, the homepage had magically reverted to an older state (values on some fields were changed and a few components went missing). I looked on the file system and sure enough, there was a "sitehome.item" file sitting in the /data/serialization/master/content folder that has a timestamp of our deploy the night before. I'm not surprised by this since the item was set to "AlwaysUpdate," though I thought "disable file deployment" would have stopped this from being uploaded.
What I am surprised at is how the site was seemingly fine all day, and then all of a sudden seemed to not only install the sitehome.item file back into the database, but also publish itself to the CD.
Does Sitecore monitor that serialization folder on a schedule job and import that data back into the system somehow?
tds serialization
My apologies for the vagueness of that question, but I'm not sure how else to pose it. Here is the situation. We have a Sitecore 8 project that uses TDS for syncing items. We have a policy of not adding most content into TDS, only one-off structural items are to be added, otherwise it's only templates and renderings and whatnot. One of the content items we do have in TDS is the main homepage item which apparently mistakenly got set to "AlwaysUpdate." We have the TDS project set to "disable file deployment."
Last night we did a deploy to production and verified that the site was correct. It was also verified to be correct this morning. This afternoon, the homepage had magically reverted to an older state (values on some fields were changed and a few components went missing). I looked on the file system and sure enough, there was a "sitehome.item" file sitting in the /data/serialization/master/content folder that has a timestamp of our deploy the night before. I'm not surprised by this since the item was set to "AlwaysUpdate," though I thought "disable file deployment" would have stopped this from being uploaded.
What I am surprised at is how the site was seemingly fine all day, and then all of a sudden seemed to not only install the sitehome.item file back into the database, but also publish itself to the CD.
Does Sitecore monitor that serialization folder on a schedule job and import that data back into the system somehow?
tds serialization
tds serialization
asked Nov 21 at 21:57
tjans
1113
1113
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
6
down vote
Sitecore does not automatically do anything with serialization files from TDS out of the box.
Now this doesn't rule out a custom schedule task that someone may have put into the system, but that doesn't seem likely.
When TDS syncs, it can be configured to publish any items that it syncs, but that would be dependent upon how you have TDS setup in your CI deploymemt process.
Most likely what happened, is that TDS synced the home item in the master database only.
Then one of the following happened:
- Someone published the home item, sending the changes from the TDS sync to the web database, and cleared CD content caching.
- TDS did publish the item to the web database, but the CD item caching didn't clear until a later time: either by a worker process reset or another publish later on triggered cache clearing correctly.
Either way, the answer is Sitecore doesn't do anything to serialized files automatically, unless someone customized Sitecore to do so, which would require further invesitgation.
Troubleshooting
It might be worth while to look at your Sitecore log and look for the Publish item messages and see if someone published it around the time you saw it change.
Additionally, generally there is a log file entry when TDS updates an item. Do a search for the Home path in your log and see if that produces clues.
Also look at your CD logs and see if there was a recycle around the time you saw the change.
Thanks, like you said, customizing Sitecore to do automated serialization isn't likely, as we control the code-base pretty tightly. #2 seems plausible, though we've never seen caching like that hang onto an item for that long.
– tjans
Nov 21 at 22:10
Yeah, its hard to say. These are likely scenarios. I am going to add a troubleshooting step into the answer.
– Pete Navarra
Nov 21 at 22:20
Added Troubleshooting steps
– Pete Navarra
Nov 21 at 22:27
You can use the Validation section of your TDS project to ensure that if the home node is there, that it is Deploy Once. Or use the validation to make sure it is never there. hhogdev.com/help/tds/propvalidation/tdsa002 hhogdev.com/help/tds/propvalidation/tdsa006
– Chris Auer
Nov 22 at 4:28
I'm not familiar with the validation section, but I will look it up, thanks.
– tjans
2 days ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
Sitecore does not automatically do anything with serialization files from TDS out of the box.
Now this doesn't rule out a custom schedule task that someone may have put into the system, but that doesn't seem likely.
When TDS syncs, it can be configured to publish any items that it syncs, but that would be dependent upon how you have TDS setup in your CI deploymemt process.
Most likely what happened, is that TDS synced the home item in the master database only.
Then one of the following happened:
- Someone published the home item, sending the changes from the TDS sync to the web database, and cleared CD content caching.
- TDS did publish the item to the web database, but the CD item caching didn't clear until a later time: either by a worker process reset or another publish later on triggered cache clearing correctly.
Either way, the answer is Sitecore doesn't do anything to serialized files automatically, unless someone customized Sitecore to do so, which would require further invesitgation.
Troubleshooting
It might be worth while to look at your Sitecore log and look for the Publish item messages and see if someone published it around the time you saw it change.
Additionally, generally there is a log file entry when TDS updates an item. Do a search for the Home path in your log and see if that produces clues.
Also look at your CD logs and see if there was a recycle around the time you saw the change.
Thanks, like you said, customizing Sitecore to do automated serialization isn't likely, as we control the code-base pretty tightly. #2 seems plausible, though we've never seen caching like that hang onto an item for that long.
– tjans
Nov 21 at 22:10
Yeah, its hard to say. These are likely scenarios. I am going to add a troubleshooting step into the answer.
– Pete Navarra
Nov 21 at 22:20
Added Troubleshooting steps
– Pete Navarra
Nov 21 at 22:27
You can use the Validation section of your TDS project to ensure that if the home node is there, that it is Deploy Once. Or use the validation to make sure it is never there. hhogdev.com/help/tds/propvalidation/tdsa002 hhogdev.com/help/tds/propvalidation/tdsa006
– Chris Auer
Nov 22 at 4:28
I'm not familiar with the validation section, but I will look it up, thanks.
– tjans
2 days ago
add a comment |
up vote
6
down vote
Sitecore does not automatically do anything with serialization files from TDS out of the box.
Now this doesn't rule out a custom schedule task that someone may have put into the system, but that doesn't seem likely.
When TDS syncs, it can be configured to publish any items that it syncs, but that would be dependent upon how you have TDS setup in your CI deploymemt process.
Most likely what happened, is that TDS synced the home item in the master database only.
Then one of the following happened:
- Someone published the home item, sending the changes from the TDS sync to the web database, and cleared CD content caching.
- TDS did publish the item to the web database, but the CD item caching didn't clear until a later time: either by a worker process reset or another publish later on triggered cache clearing correctly.
Either way, the answer is Sitecore doesn't do anything to serialized files automatically, unless someone customized Sitecore to do so, which would require further invesitgation.
Troubleshooting
It might be worth while to look at your Sitecore log and look for the Publish item messages and see if someone published it around the time you saw it change.
Additionally, generally there is a log file entry when TDS updates an item. Do a search for the Home path in your log and see if that produces clues.
Also look at your CD logs and see if there was a recycle around the time you saw the change.
Thanks, like you said, customizing Sitecore to do automated serialization isn't likely, as we control the code-base pretty tightly. #2 seems plausible, though we've never seen caching like that hang onto an item for that long.
– tjans
Nov 21 at 22:10
Yeah, its hard to say. These are likely scenarios. I am going to add a troubleshooting step into the answer.
– Pete Navarra
Nov 21 at 22:20
Added Troubleshooting steps
– Pete Navarra
Nov 21 at 22:27
You can use the Validation section of your TDS project to ensure that if the home node is there, that it is Deploy Once. Or use the validation to make sure it is never there. hhogdev.com/help/tds/propvalidation/tdsa002 hhogdev.com/help/tds/propvalidation/tdsa006
– Chris Auer
Nov 22 at 4:28
I'm not familiar with the validation section, but I will look it up, thanks.
– tjans
2 days ago
add a comment |
up vote
6
down vote
up vote
6
down vote
Sitecore does not automatically do anything with serialization files from TDS out of the box.
Now this doesn't rule out a custom schedule task that someone may have put into the system, but that doesn't seem likely.
When TDS syncs, it can be configured to publish any items that it syncs, but that would be dependent upon how you have TDS setup in your CI deploymemt process.
Most likely what happened, is that TDS synced the home item in the master database only.
Then one of the following happened:
- Someone published the home item, sending the changes from the TDS sync to the web database, and cleared CD content caching.
- TDS did publish the item to the web database, but the CD item caching didn't clear until a later time: either by a worker process reset or another publish later on triggered cache clearing correctly.
Either way, the answer is Sitecore doesn't do anything to serialized files automatically, unless someone customized Sitecore to do so, which would require further invesitgation.
Troubleshooting
It might be worth while to look at your Sitecore log and look for the Publish item messages and see if someone published it around the time you saw it change.
Additionally, generally there is a log file entry when TDS updates an item. Do a search for the Home path in your log and see if that produces clues.
Also look at your CD logs and see if there was a recycle around the time you saw the change.
Sitecore does not automatically do anything with serialization files from TDS out of the box.
Now this doesn't rule out a custom schedule task that someone may have put into the system, but that doesn't seem likely.
When TDS syncs, it can be configured to publish any items that it syncs, but that would be dependent upon how you have TDS setup in your CI deploymemt process.
Most likely what happened, is that TDS synced the home item in the master database only.
Then one of the following happened:
- Someone published the home item, sending the changes from the TDS sync to the web database, and cleared CD content caching.
- TDS did publish the item to the web database, but the CD item caching didn't clear until a later time: either by a worker process reset or another publish later on triggered cache clearing correctly.
Either way, the answer is Sitecore doesn't do anything to serialized files automatically, unless someone customized Sitecore to do so, which would require further invesitgation.
Troubleshooting
It might be worth while to look at your Sitecore log and look for the Publish item messages and see if someone published it around the time you saw it change.
Additionally, generally there is a log file entry when TDS updates an item. Do a search for the Home path in your log and see if that produces clues.
Also look at your CD logs and see if there was a recycle around the time you saw the change.
edited Nov 21 at 22:23
answered Nov 21 at 22:06
Pete Navarra
9,7662371
9,7662371
Thanks, like you said, customizing Sitecore to do automated serialization isn't likely, as we control the code-base pretty tightly. #2 seems plausible, though we've never seen caching like that hang onto an item for that long.
– tjans
Nov 21 at 22:10
Yeah, its hard to say. These are likely scenarios. I am going to add a troubleshooting step into the answer.
– Pete Navarra
Nov 21 at 22:20
Added Troubleshooting steps
– Pete Navarra
Nov 21 at 22:27
You can use the Validation section of your TDS project to ensure that if the home node is there, that it is Deploy Once. Or use the validation to make sure it is never there. hhogdev.com/help/tds/propvalidation/tdsa002 hhogdev.com/help/tds/propvalidation/tdsa006
– Chris Auer
Nov 22 at 4:28
I'm not familiar with the validation section, but I will look it up, thanks.
– tjans
2 days ago
add a comment |
Thanks, like you said, customizing Sitecore to do automated serialization isn't likely, as we control the code-base pretty tightly. #2 seems plausible, though we've never seen caching like that hang onto an item for that long.
– tjans
Nov 21 at 22:10
Yeah, its hard to say. These are likely scenarios. I am going to add a troubleshooting step into the answer.
– Pete Navarra
Nov 21 at 22:20
Added Troubleshooting steps
– Pete Navarra
Nov 21 at 22:27
You can use the Validation section of your TDS project to ensure that if the home node is there, that it is Deploy Once. Or use the validation to make sure it is never there. hhogdev.com/help/tds/propvalidation/tdsa002 hhogdev.com/help/tds/propvalidation/tdsa006
– Chris Auer
Nov 22 at 4:28
I'm not familiar with the validation section, but I will look it up, thanks.
– tjans
2 days ago
Thanks, like you said, customizing Sitecore to do automated serialization isn't likely, as we control the code-base pretty tightly. #2 seems plausible, though we've never seen caching like that hang onto an item for that long.
– tjans
Nov 21 at 22:10
Thanks, like you said, customizing Sitecore to do automated serialization isn't likely, as we control the code-base pretty tightly. #2 seems plausible, though we've never seen caching like that hang onto an item for that long.
– tjans
Nov 21 at 22:10
Yeah, its hard to say. These are likely scenarios. I am going to add a troubleshooting step into the answer.
– Pete Navarra
Nov 21 at 22:20
Yeah, its hard to say. These are likely scenarios. I am going to add a troubleshooting step into the answer.
– Pete Navarra
Nov 21 at 22:20
Added Troubleshooting steps
– Pete Navarra
Nov 21 at 22:27
Added Troubleshooting steps
– Pete Navarra
Nov 21 at 22:27
You can use the Validation section of your TDS project to ensure that if the home node is there, that it is Deploy Once. Or use the validation to make sure it is never there. hhogdev.com/help/tds/propvalidation/tdsa002 hhogdev.com/help/tds/propvalidation/tdsa006
– Chris Auer
Nov 22 at 4:28
You can use the Validation section of your TDS project to ensure that if the home node is there, that it is Deploy Once. Or use the validation to make sure it is never there. hhogdev.com/help/tds/propvalidation/tdsa002 hhogdev.com/help/tds/propvalidation/tdsa006
– Chris Auer
Nov 22 at 4:28
I'm not familiar with the validation section, but I will look it up, thanks.
– tjans
2 days ago
I'm not familiar with the validation section, but I will look it up, thanks.
– tjans
2 days ago
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsitecore.stackexchange.com%2fquestions%2f15084%2fhow-does-sitecore-handle-serialization-with-tds%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown