We are very eager to announce the new Kill Bill 0.18.x release train (current version at the time of this blog is 0.18.2).
Our last announcement for a ‘major’ release (see current Kill Bill versioning scheme) was almost a year ago . Since this release somehow coincides with the end of the year, it feels natural to not only review what it contains but also to provide an overview of what happened through 2016.
Obviously, a lot has happened in a year and this blog post will just touch the surface of some of the main things we (and the community) achieved.
Main New Features:
At this point the platform is already pretty features-rich, and each new feature brings further complexity and also has the potential to destabilize the system. So, we have to balance fulfilling the desire of some of our (most loyal) users with the stability and risk associated with such new features.
Some of the main features we added are:
- Hierarchical Account
- Shopping Card Apis
- Blocking State Abstraction
- Migration Apis (along with migration guide)
- Subscription Bill cycle day (BCD) change
Subsystem/Feature Rework:
With more adoption comes more bug reports, use cases we never thought of, … and so a large part of the work we did throughout the year was about hardening and enhancing the various sub-modules.
Catalog:
A lot of effort was invested in the catalog to address some of the shortcomings (e.g. ability to have plans of different shapes on the same pricelist), provide apis to dynamically add Plans on the current version of a catalog, harden validation, and greatly improve performance for large catalogs.
Invoice:
The bulk of work we did was around hardening of the code and implementing some detection of abnormal state to make sure customers don’t end up being invoiced incorrectly (e.g. use case where past invoice data on disk is corrupted). We spent a fair amount of time, reading our code so as to add assertions at the right place and added lots of test cases to validate such abnormal state. We have also introduced a new safeguard mechanism that will automatically park an Account whose state seems incorrect (admin action is then required to address the issue before Account can be invoiced normally again).
Payment:
We have worked relentlessly on this subsystem throughout the year as part of the work we have done at Groupon. At this point the system has processed a very large amount of production traffic with lots of different use cases (countries * gateways * payment methods), and so this subsystem is definitely one of the jewels of that stack.
KAUI (Admin UI)
Throughout the year, we have worked on KAUI as well, first to match the set of new features introduced on the server side, but also to address some reports about user experience (UX) shortcomings, and finally to provide a UI that allows most of the operations to be done. Let’s review a bit some of the additions:
- Tenant Configuration screen (catalog management with new apis to dynamically add Plans, overdue configuration, plugin configuration, internationalization support)
- Ability to update per-subscription BCD
- New screens to list recently added Accounts, Invoices, Payments
- New screens to view bus event and future notifications (to provide insight on what happen and what will happen)
- New screens to manage parked Accounts
- Rework UX to minimize number of clicks (for administrators)
- Support for system moving clock (test mode)
Plugins
It seems unfair to not mention plugins in such a blog post considering how much they are part of the system. The issue here is that my brain cannot keep track of all the things that happened here. We have written about 50 OSS plugins and we actively maintain about 20+ of those. They cover things like payment gateway integration, tax calculation, fraud detection, CRM, analytics, email notifications, …
For each major release, we have to diligently upgrade all of those and run some tests (thank God we have spent some time automating Travis to run some of those automatically), but nonetheless some of those main plugins require us to do some manual validation to feel confident the end to end solution is functioning properly.
The plugin management apis along with the KAUI integration also make that piece much easier, as we can now deploy, start, stop and even configure plugins with a few clicks. Note that this work was largely done in 0.16.x release but we have enhanced things quite a bit since then.
Documentation:
On the documentation front, we are growing our guides, manuals, tutorials and screencast, to help with on boarding experience, development work, operational work, and system internals knowledge. We have received some great feedback from the community and also some contributions.
Community:
A couple of months back, i had given a status of the OSS project so I won’t go there again, the main point to keep in mind is that 2016 was a great year for code contributions and we are looking forward to receiving more in 2017!
Lastly, for those of you still on 0.16.x release, we encourage you to upgrade to benefit from all this work. This is not a trivial upgrade but we have spent decent amount of time writing release notes and also have worked on tooling to help with DB migrations. You will need allocate some time to run some regression tests matching your own scenario to verify things work as you expect. We also recommend you export your production data into a test environment with the 0.18.x release, where you can then move the clock forward (day by day) and verify correct behavior.
Please report any issues on the mailing list.
Happy 2017!
