More in this section
Forums / Bugs & Issues / Export for Deployment madness.

Export for Deployment madness.

The forums are in read-only mode. In case that you want to directly contact the Progress Sitefinity team use the support center. In our Google Plus group you can find more than one thousand Sitefinity developers discussing different topics. For the Stack Overflow threads don’t forget to use the “Sitefinity” tag.
1 posts, 0 answered
  1. Coenraad
    Coenraad avatar
    0 posts
    Registered:
    02 Jun 2017
    02 Nov 2017
    Link to this post

    Hi there, we are building a Sitefinity site with Sitefinity v10.1, which we want to integrate into our DevOps process where VSTS / any CI builds the code that gets published to the source control and then after building it, publishes it to an Azure App Service where the site is running.

    Along with that, we do an Export for Deployment every time we push to our "staging" environment. Everything up till this part works super well. The builds pass, the code publishes easily enough.

    However, when I put down those "Deploment" files that are located at "App_Data/Sitefinity/Deployment" things get a little wonky from time to time.

    1.) Content managers come back to us and complain that changes they had made the previous day are now reversed, from what I can tell those files exported for deployment only contain "structures" and no content, I even inspected the JSON and there's no content in there.

    2.) From time to time, Thunder completely breaks at random during this "import of the deployment". What that means is we end up pulling down a database that our developers can not use the Thunder plugin with anymore.

    3.) Sitefinity completely ignores the Packaging setting set in the PackagingConfig.config and database. I have my QA, UAT and Staging environments set to "Target" which means they should import the "Deployment" file when it exists. BUT my local development environments which are using a shared development database which has that setting set to "Source" ALSO imports these deployment files. That is a bug according to the documentation.

    4.) When an empty "Deployment" file exists (one that has no sub directories in it) Sitefinity goes and completely wipes the database & content types leaving us with a brand new & extremely naked / empty Sitefinity database. (Great way to rollback... If only it prompted me and asked me if I want to import the content changes?) This is a great undocumented hidden little feature that we have here and has costed us dearly. Is this intended?

    5.) Lastly, we are trying to figure out why it seems that certain content changes stay when we do the import for deployment but others get reversed. Like CssWrapper class updates or style updates get thrown to the wind but bigger things tend to stay, is there like a "memory" or "queue" that Sitefinity has to publish or update records in the database?

    Feedback would be appreciated.

1 posts, 0 answered