Continuous Integration does not update Page History

Tim Sieberg asked on March 20, 2018 23:10

I enabled Continuous Integration on our site but its not working as I would expect. The issue I'm seeing is that after retrieving the latest files from TFS and executing "ContinuousIntegration.exe -r", is that in LiveSite mode (viewmode=0) I see the change that was pulled in from another developer. In Preview mode however (viewmode=2), I'm seeing the last version of the page as it was on my local machine prior get and restore operations. This means if I edit the page, I do not see the change that was pulled in, so I'm not editing what I would consider the latest version, but instead the latest I had on my machine prior to the restore.

The change that was made on the page occurs within an Editable textbox. The only changed file is the document.xml file for the particular page that was changed.

I have Object Versioning turned off. I also have Automatic version numbering disabled under Settings > Content > Content Management

We're using version 10.0.51.

I have spent hours trying to clear caches, restart things, examine the database. I'm hoping some one knows what the issue is and can help me out.

Recent Answers


Trevor Fayas answered on March 21, 2018 00:32

Continuous integration does not track version nor workflow, which it almost seems like the pages you have are under a basic workflow and it's loading the edit document vs the published.

A recommendation I can make is use the API to try to step back the workflow on any documents that are in the non published state.

Another option is to (backup first) clear the version and workflow tables in the database, that should load then the latest documents as the current version/step.

Documentation does mention this, that only when a document is published is the ci info generated.

1 votesVote for this answer Mark as a Correct answer

Tim Sieberg answered on March 21, 2018 14:13

So if I understand correctly, to use CI, I either need to write code manipulate the workflow, or write scripts to modify the database. I was hoping CI would work out of the box.

We have each developer using a local database. If we use a single shared database, would this problem be resolved? Or is there a way to disable this workflow on all pages? We currently have it setup to immediately publish all page changes, so we're not really using workflow anyway.

0 votesVote for this answer Mark as a Correct answer

Trevor Fayas answered on March 21, 2018 21:40

Well, to use CI it's probably best that you don't use workflow, becuase it will only track a change when you hit publish, and by default with WOrkflow when you are editing it will show the current workflow step.

So the scenario where you have Create a Document and Publish (Say "Version 1"), and you then edit hte document, it's pulling from the Workflow. When you import from Continuous Integration, it overwrites the "Version 1" so to say, but you still have the Workflow step.

If you want to keep workflow, you may want to write a script that either checks in or cancels the checkout of all pages before doing an import, so that way there is no workflow step, and it will set the imported content as what you have.

You do not want the developers to use a shared database, as the changes need to be tracked on each computer so it can make the CI information for the change.

One question you should simply ask is "Is continual integration vs. versioning the way to go for my situation." CI is an option if you want all your database changes in a Code Repository so you can do pushes, changesets, etc. But you lost a lot of functionality with it.

Having a Shared database and just using built in Kentico versioning is great if you don't need the code repository, downside is everything is in the database. I've only used CI for our Custom Development Kentico instance where we create tools that we use on other sites.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.