Enterprise application construction has high requirements for construction speed, code quality, construction performance, pipeline usability and maintainability. Enterprise R&D teams usually need to integrate third-party system tools or plug-ins to continuously improve the efficiency, quality and experience of the entire construction process. Each team has a different set of capabilities for plug-ins, based on different management and build scenario requirements.

Recently, CODING in continuous integration provides users with more than 10 kinds of commonly used, on the basis of official plug-in, introduced a user-defined plug-in ability, let the team members will be handy tool or command encapsulated into “custom plug-in”, to facilitate rapid configuration in the build process required plug-in ability, and support for Shared within the team, Make it easy for other members of the team to reuse quickly.

Free custom

Custom plug-in does not limit the technology stack and language framework, any command line executable program, can be encapsulated as a plug-in. The development team can develop or use open source plug-ins to meet the team’s build needs and diverse demands. Upload can be used without official approval.

Graphical arrangement

Based on the graphical layout capability of CODING continuous integration, plug-ins can be directly selected in the configuration steps of the construction process in the application of plug-ins, which is simple and easy to use.

Enterprise level plug-in management capability

The custom plug-in supports sharing within the enterprise/team, and the plug-in uploaded by team members can be publicly used by other members of the enterprise, which is conducive to tool sharing among development team members, improving the creativity of developers, and saving time and energy for repeatedly making wheels.

How does a custom plug-in work?

1. Look at the build plug-in

Click “Function Settings” → “Continuous Integration” → “Build Plugins” on the left side of the home page. Here you can see official plug-ins, team plug-ins, and individual submitted but not published plug-ins. View the name, description, and version number in the plug-in details.

2. Develop plug-ins

Plug-in development does not limit the development language and environment, just to meet the specification of the directory structure of the plug-in (below) and the specification requirements of the declaration file. When you write your plug-in code, save the logic code to the my-plugin-project/ SRC directory or any subdirectory, and run the entry file to make sure it is the same as the declaration file.

Plug-in directory structure:

-my-plugin-project // Your project directory -my-script.xx // Build plug-in execution script or entry file, support any language organization (if the execution environment is available, -qci-plugin. yml // Build plug-in declaration file to define your build plug-in name, version, parameters, etc

Please click to see the specification of the declaration document and more detailed development guidelines.

3. Upload plug-in

When the development is complete, package the plug-in code (zip package) and upload it in “Feature Settings” → “Continuous Integration” → “Build Plugin”. We will save your project files, and at build time, the build node will download the project and execute it. Confirm the release of the plug-in after uploading, and set the members of the public team to be visible after publishing.

4. Use plug-ins

You can use the plugin functionality either through the graphical orchestration interface or by compiling the command line. When a plug-in is private, only the author can add and use it, and when the author marks the plug-in as “public,” the rest of the team can see and use the plug-in.

  • Graphical arrangement

Click the target “Build Plan” → “Settings” → “Process Configuration”, and select whether to enable the official plug-in or the team’s custom plug-in when adding steps in the stage.

  • Compile command line mode

Support for editing Jenkinsfile directly from the command line. Examples of reference statements are:

UseCustomStepPlugin (key: 'exec_py_script', version: '1.0', params: [site_packages:'false',requirements:'false']) // Key is the ID of the plugin, version is the version number (default is the latest version, automatically upgrade with the plugin), params is the parameter required for the current plugin.

The “Custom Plugin” provided this time expands the building capability boundary of CODING continuous integration, meets more personalized software building needs, provides maximum flexibility to the majority of R&D teams, and also improves the efficiency and ease of use of building process configuration. In the future, continuous integration of CODING will gradually be compatible with Drone and GitHub Action plug-ins, and the ecological capability of continuous integration of CODING plug-ins will be constantly built.