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 installation process. -
Same as above except that the runtime uses
ec-groovy
bindings to interact with the server. In this approach, theproject.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 Plugin Wizard Based 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.
-
-
Plugin Wizard-based approach
-
Provides a methodology to package and promote plugins. It is not a development framework.
-
DSL based promotion that the Plugin Wizard 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 thepluginspec.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 bypdk
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. Howeverpdk
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 topdk
.
While the Plugin Wizard 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.
|