Commercial Episerver Add-Ons are a Thing

casper.rasmussen/ September 13, 2018/ Uncategorized/ 0 comments

Most developers in the Episerver community have over time benefited from one or many of the great commercial add-ons that are out there. When saying commercial add-on, I am not just referring to the kind of add-on you’re using to introduce any functionality – I am referring to the ones that are sold as products, or comes with paid services.

How are commercial add-ons different from my open source ones?

Commercial add-ons are proprietary software, distributed under a licensing agreement to authorized users. In simple words, the source code (or add-on for that matter) may not be shared with the public for anyone to look at or contribute too. You’ll frequently see these commercial add-ons come with the subscription of a service – e.g. the use of Vertex Inc., for automated tax solutions, unlocks the ability to connect it easily to Episerver Commerce via their proprietary integration add-on.

You might be asked to make one, one day

Think about this for a second, these commercial add-ons are made by people in our Episerver community. Passionate folks, like myself at Valtech, are helping software companies to seamlessly integrate their functionality in to Episerver solutions, through commercial add-ons. It might not be what comes to mind first when you’re thinking Episerver development, but it is indeed one of the cool challenges we’re facing when being a respected Episerver partner! If you’re getting that challenge one day, here’s some key ingredients we always use in our secret sauce when it comes to commercial add-ons.

Respect breaking changes

When your commercial add-on is put in use for the first time, developers and business users will require respect, strictness and precision when it comes to any exposed API’s (or features for that matter). If you’re introducing a change in anything “publicly” available, like a code contract or another API, you need to rely on release notes and semantic versioning to make that clear. Nobody appreciates unforeseen complications of an upgrade – especially not when it’s a paid and governed product.

Document, document, document

We’re always providing multiple layers of documentation on all our commercial add-ons:

  • any public code is well documented and we always use annotations to mark the obsolescence of something.
  • all our commercial add-ons ships with installation and configuration documentation. No one want’s to explore the steps to take when installing, when you can be told.
  • we use internal documentation to document the e.g. architectural visions and use of design patterns, to ensure our add-on evolves consistently over time.

Consider signing your assemblies

When you’re signing assemblies, you guarantee the authenticity. It ensures the assembly any add-on consumers are using hasn’t been tampered with in any way.

Use access modifiers

Always hide what should be hidden – only expose code or functionality you truly want the outside to interact with! You need to use access modifiers to enclose business logic or internal code API’s you’re not looking developers to use, replace or modify in any way. Whenever something is public, or in any way accessible from the outside of your own assemblies, it should be governed by semantic versioning.

No real chef would ever disclose all the ingredients in his secret sauce. With that said, above hopefully gives you an introduction to an alternate universe of Episerver development, which in many ways differs greatly from creating web or headless consumer facing experiences.

Leave a Comment

Your email address will not be published. Required fields are marked *

Please type the characters of this captcha image in the input box

Please type the characters of this captcha image in the input box
You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
*
*