Plant an App has already been around for more than a year. Many of our DNN Sharp customers already migrated to using Plant an App. Lessons have been learnt and shared, and I’ve compiled them here in a success story.
Pre-requisites
Installing Plant an App on an existing DNN instance is non-disruptive, even if DNN Sharp modules are already installed. The problems that our customers encountered were mainly related to having old DNN or DNN Sharp modules. So, make sure that you understand the migration path first.
For some customers, part of getting a DNN instance ready for deploying Plant an App is to migrate from Evoq to DNN Community first. This helps customers unlock budgets and also reduce the legacy footprint so they can move faster with Plant an App. Our team has been involved with dozens of such migrations, so if you need help, drop us a message.
First Steps
We've put a lot of effort into making the transition as smooth as possible. After Plant an App is installed, all functionality should continue working as before. This eliminates the need to do a lot of refactoring work from the start. Rather, we see customers adopting the new features incrementally.
A very important thing to mention is that Plant an App is using the DNN Sharp modules, so many screens in the interface will look very familiar and give you a consistent experience.
Development Accountability
The next thing that you'll want to do is to configure a Git repository and tie it to the Plant an App instance. This will give you the history of all changes anyone does to the module configuration. It helps answer the question "Who changed what and when?". This also has been a game changer for many of our customers looking to build more complex systems but missing the tools that developers are used to in traditional development.
Staying Updated
There's an immediate benefit that Plant an App users get right out of the box, and that is the one-click install and one-click upgrade features. Basically, with a click of a button, Plant an App knows to download and install all DNN Sharp modules that are part of a release.
This has two major effects that help save a lot of time and friction. The first is the time saved by not having to install modules one by one. A Plant an App release contains specific versions of DNN Sharp modules. This means that the exact combination of modules is what we've been testing and is what gets deployed to our customers, hence ensuring the best compatibility.
Ultimately, it becomes very easy to stay up-to-date to take advantage of security patches, performance improvements, bug fixes and new functionality.
Separating the Business Logic Layer
In the DNN Sharp world, the business logic is made out of actions that are attached to various UI elements and/or events, such as a form button click event or a scheduled job that runs in the background. As complexity of the application grows, the business logic ends up being spread all over the place, the lists of actions become longer and longer, and some actions get duplicated over and over again.
What we've seen our customers that transitioned to Plant an App do very successfully, is that whenever they need to change a form, a grid, and API and so on, they take the time to move parts of the actions lists to workflows. Therefore, it can be a transition that happens incrementally over a few months, rather than a big initial effort. We believe this to be the most successful strategy, as it allows for learning to mature in development practices.
Arguably, one can continue implementing the business logic inside each module as before. The workflow super capabilities are in terms of encapsulation, reusability, testability, robustness and visual diagramming.
The Entity Builder
Perhaps the most difficult feature to migrate to is the Entity Builder. Note that for new instances, the Entity Builder is quite easy to use and saves tons of time. We've seen customers deploying new systems in just 2-3 days.
However, when it comes to using it in an existing application, the complexity derives from the fact that custom tables that were created previously have to be migrated to the Plant an App structure. In fact, we have it in our roadmap to extend our Entity Builder to be able to import existing tables from the DNN or an external database. At that point, we expect this task to be much easier.
Continuous Education
Low-code makes possible a very dynamic continuous education paradigm. In Plant an App, you get to learn new things on a daily basis, either it's new technologies, new systems that you integrate, or new techniques for architecting the low-code systems.
To support this, we have put a few layers in place, from a Weekly Webinar, to Documentation, and Low-Code Academy courses (currently in private beta) and a Community Portal where you can learn from peers.