How do you best deploy your tools to your users? Of course, what is “best” depends on your situation. If you are just starting out, you are probably going to choose the simplest approach, represented by the lowest maturity level. As your tool gains more and more users and is released more and more frequently, investing in a more complicated deployment mechanism becomes reasonable. Below is an overview of what I found to be the most common “rungs” on that ladder.
Level 0: A bunch of plugins
The easiest, simplest way to deploy your MPS-based language to your users has to be something like this:
- Create a build script to build a MPS plugin out of the languages. MPS provides a wizard for that (right-click on a project, New → Build Solution).
- Build the MPS project and run the generated build script.
- Publish the produced plugins and any dependencies on a file share.
- Users install MPS on their machines, download the plugins and copy them to the MPS plugins folder.
- To release an update, you do the same steps and ask your users to delete the old plugins and unpack the new ones.
Level 1: An RCP
The next step is to provide your users with a self-contained package that contains everything they need: MPS bundled together with the necessary plugins and with unnecessary plugins removed. This bundled version is called a rich client platform, or RCP.
MPS can generate a script that would package such an RCP for you, also letting you customize the branding along the way: you can give your IDE a custom name and custom splash screen.
The initial installation would be similar as before, except that instead of putting up a bunch of plugins for download, you put a single RCP distribution, perhaps wrapped in a platform-specific installer, or simply as a ZIP file for users to unpack.
Upgrades are done by uninstalling (= removing) the old RCP and installing the new one.
Level 2: Automatic updates of plugins
A client of mine would not allow users to install any new software on their machines. Users lacked admin rights and any installations were done by IT personnel. Combine this with frequent releases and you get overloaded and grumpy IT people.
In this case, it made sense to set up a plugin repository and publish the plugins there. All IntelliJ IDEA-based IDEs already support downloading plugins from an internet repository and checking that repository for updates. The team has set up an internal plugin repository and configured the RCP to use this repository. New plugins were then published to the repository and users could download updates as soon as they were published. No admin rights required.
Note that it is not possible to update the plugins that are bundled with the initial installation. Therefore, to use automatic updates you have to publish a minimal RCP (MPS + branding) and as a result this RCP will be non-functional when it is installed. Your users have to install the necessary plugins from the plugin repository before they can start working. This initial installation can be somewhat automated but is still a problem.
Level 3: Automatic updates of the RCP
JetBrains IDEs can auto-update themselves, including the bundled plugins. What’s more, they can do that via binary patches, so that you do not have to download the full 1GB package with each new version. This is also possible to implement for MPS-based RCPs. I have seen it implemented at one of my clients and some early discussions around making the implementation openly available took place but there is nothing that I can point to yet.
If you want to have a go at implementing this yourself, the updater of IntelliJ IDEA Community Edition can be found here.
The users now get a fully working version of the RCP right from the start, and the tool can upgrade itself to a newer version by downloading a patch. However, the question of user permissions (and allowing the users to run software which patches other software) will need to be considered.
I’m curious whether your experience matches these levels. How do you put your MPS-based tool in the hands of your users?