SREWorks v1.3 Unveiled: Plugin Architecture, UI Enhancements & Cloud‑Native Ops

1. Plugin Package

In the OAM model, Components and Traits are inherently pluggable. v1.3 separates these modules from the appmanager source code into independent plugin packages. The plugin management and package structure are shown below.

├── definition.yaml                           /* component definition metadata */
├── frontends
│   ├── deploy.json                           /* front‑end customization for deployment */
│   ├── build.json                            /* front‑end customization for build */
│   └── source.json                           /* front‑end customization for source */
└── dynamicscripts
    ├── ComponentDeployHandler.groovy         /* deployment script */
    ├── ComponentBuildHandler.groovy          /* build script */
    ├── ComponentDestroyHandler.groovy        /* runtime destroy script */
    └── ComponentHandler.groovy               /* component definition */

Future minor releases will continue converting built‑in components and traits into standard plugins, a process expected to span 1–2 versions.

Because plugin development currently has a learning curve, the plugin development framework is not yet public in v1.3. It will be released together with developer documentation once tooling is ready.

2. Plugin Visualization

Each plugin can include its own front‑end pages; the frontends directory holds these custom UI files.

When adding a Helm component, users can choose between a custom source (Artifact Hub) or a generic source (code repository). During build, ComponentDeployHandler.groovy pulls the selected Helm chart into the application package.

After adding the component, the deploy.json file in the plugin controls the Helm parameters, which are placed under the values map and can be populated via OAM’s dataInputs mechanism.

Once configuration is complete, an OAM ApplicationConfiguration YAML is generated and displayed on the build page.

Note: The visual plugin mechanism is built with front‑end low‑code capabilities; interested users can import the "Enterprise Application Management" app (APP_ID: app) in the Operations Development section to inspect the low‑code orchestration details.

3. Component Definition Process Standardization

The component definition flow has expanded from a single step to a “4+1” step process, illustrated below.

The additional "+1" step is the Deployment Baseline . Runtime traits such as Ingress are detached from the component definition and attached as a deployment baseline, simplifying user configuration at deployment time.

2. Application Mechanism Optimization

To reduce confusion between "Enterprise Application" and "Operations Application", SREWorks clarifies the two categories.

Enterprise Application → Enterprise Application Marketplace:

Cloud‑native apps that carry core business workloads.

Can be enhanced with intelligent operations capabilities.

Open‑source solutions are packaged as enterprise apps for marketplace distribution.

Operations Application → Operations Application Marketplace:

Cloud‑native ops apps built with SREWorks low‑code front‑end.

Quickly integrated into the ops middle‑platform.

All ops apps are abstracted models; raw open‑source apps are not listed directly.

The marketplace uses the same package structure but different endpoints, and users can also create private cloud‑native marketplaces.

Operations Application Marketplace: Built‑in ops apps are now published to the cloud, receiving faster updates than the core SREWorks releases.

Future releases will decouple the SREWorks base from ops apps, allowing the base to stay static while apps update independently.

To address isolated‑environment deployment challenges, an offline ops‑app package with import/export capabilities is introduced.

Below are the interaction flows for online and offline app distribution.

3. Front‑End Component Custom Integration

Users can now package custom front‑end components as UMD bundles, allowing remote loading without recompiling the core frontend.

These UMD components behave exactly like built‑in ones after one‑click import.

The @sreworks/widget-cli scaffolding tool provides Vue and React templates, enabling developers to publish components to npm or private registries for easy integration and runtime upgrades.

4. Data Ops Platform Streaming Job Monitoring Dashboard

The streaming part of the Data Ops platform, built on the open‑source VVP project, now includes a Grafana‑based monitoring dashboard for VVP jobs, deployed in a fully managed fashion.

5. Other Improvements

Support progress tracking after helm install sreworks.

Add dynamic row‑highlighting for table components with five color options.

Introduce new front‑end widgets: word‑cloud and heat‑map; improve Tab vertical filter.

Customizable operation submission prompts (see issue #86).

Optimize Kankio container build mechanism.

Application management now auto‑registers its own Kubernetes cluster.

Desktop background scaling adjustments.

How to Upgrade to v1.3

The upgrade includes the base platform; expect 5–10 minutes of downtime.

User‑developed cloud‑native apps remain running (no restart), but SREWorks gateway traffic will be interrupted.

git clone http://github.com/alibaba/sreworks.git -b v1.3 sreworks
cd sreworks
./sbin/upgrade-cluster.sh --kubeconfig="****"

If you encounter issues, please open an Issue or submit a Pull Request on GitHub.

SREWorks open‑source repository: https://github.com/alibaba/sreworks