Hi
We have these environments: local development, CI, Test, Staging and Production. An external developer also has their own local development environment and hence we're using continuous integration to pull in their work. The Continuous Integration option in Kentico is enabled only for local development.
At present, the Visual Studio solution is built (to ensure it compiles) by TeamCity and deployed to CI, Test, Staging and Production using Octopus Deploy. There's also a step in Octopus Deploy to run ContinuousIntegration.exe -r for all environments. For CI and Test, repository.config is setup to deploy almost everything apart from some pages with environment specific settings. For Staging and Production, it's setup to exclude objects that may have been updated by content editors in production, such as cms.document. We then try and take care of the rest using content staging and synching selected pages from the lower environment. Yes continuous integration restore is not encouraged for production deployments, however the documentation says it can be done and to try and choose a time when editing is not underway and this seems to be the approach allowing for the most automation.
- We've had a couple of issues in Staging and Production perhaps caused by continuous integration restore deploying only the subset of objects. A couple of pages ended up in an odd state and had to be re-created. It may be that an object that the page depends on was redeployed by continuous integration restore and the association between that object and the page was lost somehow. To avoid this, we're considering enabling filesystem storage for virtual objects and adding them to source control and relying on this feature and content staging for Staging and Production deployments where we will no longer run the continuous integration restore. Will this solve our problem and take care of new pages, layout, transformation, page template and page type changes?
- We're in the process of implementing How to Deploy Anything in IIS with Zero Downtime on a Single Server to enable zero downtime releases. Again it'll be mostly automated with Octopus Deploy. Because we have form data coming in, switching to a different Kentico DB is not ideal. Therefore the suggestion is to run continuous integration restore (this might be omitted depending on answer to point 1), then content staging sync from lower environment, then update one site and then update the other if everything is OK. We'll actually leave both sites up once on the new version in a web farm (UNC path for media library). This is to prepare for when the 2 sites are moved to separate servers and we can use the setup for high availability/disaster recovery as well. Has anyone tried this with Kentico, and/or is there a better way to achieve this?
Thanks.