Continuous Integration does not update Page History

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.

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.

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.