Seamless Custom Development in Kentico 10
Customization is Kentico's most powerful virtue. I've said that multiple times during my time here, and it's still a rock-solid truth. The ability to customize the hell out of it is a pillar stone for a superior platform. Kentico has gone pretty far with the actual extensibility and now we're pushing it even further with Team Development support and other useful tricks around Modularization.
We introduced the concept of custom modules a few years ago. There were a lot of satisfied reactions regarding it and even more when we closed the circle in Kentico 9. Leveraging NuGet for module distribution was the right move. You don't have to be a rocket scientist to install or update the custom module, and we all like it a lot. However, there was another piece of the puzzle.
Custom Module Licensing
Thanks to some of our partners, we already have a few custom modules. The modules can solve various issues from Request Filtering to Kentico Draft Integration. It's up to the author and the exact problem. Solutions worth paying for are out there. One thing is to find the opportunities for custom development. Another, is to sell them.
You need to license your work to set up a payment model. I'm sure everyone can make up an easy way how to do it. At the top of my mind is a text file license, sitting in some special place. You can do it in a few minutes even with a coffee break, no sweat. But the user experience is from the early 80s, and you may need some adequate solution that won't disgust your clients. For example, a custom User Interface within your module where your customer will see what licenses he has. Or something entirely different because the imagination is endless.
We heard the vox populi. The call for a standardized approach. With simplicity in mind, we've created best practices on how to build your licenses using RSA encryption as well as a centralized place for all the custom licenses of all the modules the client will ever have. On top of that, you can use the prepared API to generate your license and to validate it in your module. All smooth as silk. It should answer all of your licensing questions. Now you can focus on the value of your module and leave the Kentico core to bother with the boring stuff.
This functionality is built into Kentico 10. However, we didn't forget the older version. If you are eager to use the new licensing for your Kentico 9 modules, you can still do it. There'll be a package in the Marketplace available after release containing the tools and functionality necessary to implement licensing for your custom modules.
Custom Team Development
The licensing is fine, but I'm sure you're more interested in the development part. The previous version introduced Continuous Integration as the best way for your team development. But it was just the beginning. Needless to say, we left a big gap between the module development and team cooperation. I would like to say we built a bridge across the chasm but that's not exact. We poured two hundred metric tons of concrete into it and painted highway lines. How? Continuous Integration in Kentico 10 supports every object you can imagine in your module development. Modules, classes, settings, user interfaces, permissions, you name it. If you have a team working on a custom module, this is the Holy Grail.
The best part is we didn't stop there. Continuous Integration supports about 90% of all objects in Kentico. What are the lousy ten percent? Activities, contacts, event log objects, and other data that is purely production oriented or somewhat uninteresting. The good stuff is the 90% of awesome team development effectiveness. Even your localization strings can be easily maintained in CI. If you didn't already take the leap of faith with Continuous Integration, now is the time.
Still not convinced? I will give you a cherry on top. You are probably familiar with the option to filter only the right object types for CI. This feature is already in version 9. However, we pumped it up in Kentico 10. Now you can filter out specific objects defined by the codename's prefix or suffix. Very handy if you have hundreds of test objects or other types of data you don't want to synchronize or see in your CI repository. This is super-efficient if you want to boost your performance or mitigate the mess in your CI repository and therefore save a lot of time for your developers during reviews and commits. Saving the best feature for last–it's very easy to filter out whole pages or entire subtrees just by their alias paths. I'm pretty sure you don't need my help to find a use for this particular one.
Still reading? What are you waiting for? Go! Express some innovative thinking, build your unique puzzle piece, and sell it. You have all you need.