By Anthony Baratta
A deep dive into Kentico 9 Continuous Integration
One of the biggest features in version 9 of Kentico is the ability to use continuous integration with your Kentico development process. A fully autonomous continuous integration service could be considered the Holy Grail of software development. Discrete updates are performed by the developer, checked in source control; from there an event driven process builds and runs unit and acceptance tests on the latest version of the application. If any of the tests fail, notifications are sent out and the development team is expected to fix the issue and push the new version back through the testing and the validation service until it test clean. The point is to have a releasable version of the software / service at any time.
Your CI process is only as good as your testing protocol
Of course your continuous integration process is only as good as your unit and acceptance tests, and new features need to have new tests built and themselves validated. However, you are building a historical record of testing patterns that are automated and not subjected to the vagaries of manual testing. The challenge for smaller projects is the overhead from a CI process can push you to bypass your internal bureaucracy for “faster” deployment. We’ll explore how to streamline your CI infrastructure for smaller projects in a later post.
Until Kentico 9, custom development and configuration changes to Kentico were separate processes. Files added to the Kentico solution were tracked via source control. Changes to the Kentico configuration and system objects (let’s ignore content for now) were exported into packages that could be loaded into source control but are not incremental and therefore you couldn’t track the differences between exports. There were available work arounds using the “Source Control Mode” but this still left some types of DB objects (e.g. Page Types) only in the Database. Additionally the Source Control Mode imposed some limitations on applying hotfixes and using staging features.
Database objects can now be tracked as XML files
With version 9, Kentico now has the option to serialize the objects in the database to the local hard drive as discrete XML files. Once the CI process is enabled on your development environment Kentico will automatically keep the xml files in sync with the changes made to the system via the API or Admin interface. These files can then be tracked via source control and used as the base for your continuous integration process. Importantly, the XML files are agnostic to your choice of CI tools.
Multiple developers can check out the latest copy of the serialized objects from source control and restore them into their developer instance to stay in sync with the development branch. Build and test automation can be setup using the new continuous integration files to build and report on the new Test/QA branch automatically or on demand.
You still need source control
It’s important to note that CI serialization will not keep track of versions of an object, that is left to the centralize source control service. Objects deleted are removed from the CI folder structure, and roll backs overwrite the xml object with the updated object info. Additionally, when restoring from your CI files, objects not represented in the CI files will be removed from the database. Any changes to the CI files received from source control should be restored into the development environment quickly otherwise merge issues can result with out of sync changes.
A few caveats
- The new CI process will not export custom modules nor resource strings within resx files. Custom modules can be managed with their own source control project, and imported / exported via the standard module management features. Resource strings are subject to the project’s source control system.
- Like any Kentico development environment, hot fixes need to be rolled out in a control manner to ensure that everyone is working with the same version of Kentico and the dev – test – stage – prod environments are all in sync.
- Finally, you don’t want the CI process enabled on Production. Restore the CI files into Stage and then push the changes to Production using the staging process. Updates to the staging features with version 9 now allow you to push only those changes by user or task group.
- This means the CI process is only used with Kentico CMS Ultimate and EMS licenses. If your client is using Kentico CMS Base you can continue to use the original export / import process.
Conclusion – Kentico 9 CI makes it possible to dramatically increase the quality of your code and streamline your production releases.