Plugin development framework

Past approaches to plugin development

CloudBees CD/RO plugins have been developed in the past using many different approaches. This section provides an overview for background and perspective.

History

The following two approaches largely cater towards extending access to the internals of the server for the purpose of specific customization. For example, querying the jobs that have run on a day, creating a chart, and showing it in an HTML page, by extending the page menu.

CGI and HTML to build the user interface, invoking ec-perl command line scripts at runtime.
CloudBees CD/RO Java SDK, including GWT bindings, to build the user interface, invoking Perl scripts through ec-perl at runtime.

The following three approaches evolved as there was a need to integrate with third party software and hence required more intuitive and dynamic UIs (that are consistent with UIs), apart from modularized plugin step code to address different use cases.

Build the user interface using a declarative approach (form.xml) which in turn gets used by React, invoking modularized Perl code through ec-perl at runtime.The salient metadata required for all Procedures is declared in a file called project.xml, which gets further exploded and applied as an RDBMS bulk upload during the install process.
Same as above except that the runtime uses ec-groovy bindings to interact with the server. In this approach, the project.xml is considerably simpler than the approach above and gets exploded and applied using DSL during plugin promotion. Further the plugin source code layout is more intuitive.
Same as above except the runtime is modularized Perl that gets invoked using ec-perl. Plugins developed using the last two approaches are referred to as PluginWizardBased plugins.

Limitations of each approach

CGI Based Approach
- Difficult to implement dynamic UI elements.
- Developer is responsible for things like matching style (CSS).
GWT Based Approach
- By default, GWT/Java performs processing logic in the web browser. For data intensive tasks, a combination of GWT/Java + CGI/perl may be required to offload work to the web server.
- Does not leverage React, which is more robust, consistent with UI, and provides a declarative approach(form.xml).
- Relatively longer development and debugging cycles.
Pluginwizard
- Provides a methodology to package and promote plugins. It is not a development framework.
- DSL based promotion that the Pluginwizard introduces does not perform and increase linearly with the number of procedures added to a plugin.

Purpose for a development framework

As the use case for creating plugins becomes diverse, there is a fundamental need to have a unified approach that:

Provides a consistent way to build a plugin starting from code layout all the way to its promotion.
Abstracts plugin based common interactions with and Third Party Tools by providing reusable core libraries.
Provides inversion of control with tooling that goes hand in hand with the resusable libraries and aids development from start to finish.
Offers the possibility to expand the repertoire of core libraries, thus providing continuous innovation.

In a nutshell, the goal of the framework is to accelerate plugin development.

The development framework

The plugin development framework (aka pdk) is a combination of tools, specifications, APIs and libraries that work together with the overall goal of making plugin development easier and consistent.

Plugin starter spec refers to the file pluginspec.yaml used to declare the procedure interface (including UI elements) for each procedure that is part of the plugin.
pdk refers to the CLI that reads the pluginspec.yaml to create the workspace of the plugin and procedure boilerplate code, creating the entire layout. It is also used to build the plugin.
flowpdf-perl refers to the Perl library that is packaged automatically by pdk with the plugin, whose documented APIs make plugin development consistent and easy.

Refer to the diagram below that provides the developer steps to develop a plugin using the framework.

Current limitations

This section is provided for transparency.

Full-fledged support for boiler plate code generation, as well as framework libraries from pdk, is only available currently for the Perl language.
Perl plugin dependencies—third party libraries used by the plugin—need to be compatible with Perl 5.8. pdk provides the ability to load Perl library dependencies from memory, when the plugin step runs. No extra steps are required by the developer to install third party dependencies for Perl on the agent.
For the Groovy language, pdk does not provide either boiler plate code generation or framework library support. However pdk can be used to create/manage a plugin workspace as well as building/packaging a plugin written in Groovy. Developers can use ec-groovy to author their plugins.
Groovy plugin dependencies—for example, third party libraries required by a Plugin—need to be installed in the agent by the developer, either manually or using the @Grab annotation in the plugin step code.
pdk is meant to be used to author new plugins. It does not provide any solution to migrate plugins developed with previous approaches to pdk.

While the Pluginwizard approach mentioned in the section above provides a way to package third party libraries by using the repository server to hold these and then retrieving these as artifacts in the plugin step code, pdk does not currently support this approach, since repository may not be setup by all customers.