Architecture

The following diagram shows an approximation of how DevStream executes a user command:

There are three major parts:

• pluginengine: the plugin engine, which achieves the core functionalities by calling other modules (configloader, pluginmanager, statemanager, etc.)
• plugins: implements the actual CRUD interfaces for a certain DevOps tool

Note: for simplicity, the CLI is named dtm(DevOps Tool Manager) instead of the full name DevStream.

Every time a user runs the program, the execution transfers immediately into one of the “command” implementations in the devstream package, in which folder all commands’ definitions reside.

The pluginengine calls the configloader first to read the local YAML config file into a struct.

Then it calls the pluginmanager to download the required plugins.

After that, the pluginengine calls the state manager to calculate “changes” between the congfig, the state, and the actual DevOps tool’s status. At last, the pluginengine executes actions according to the changes, and updates the state. During the execution, the loads each plugin (*.so file) and calls the predefined interface according to each change.

The pluginengine has various responsibilities:

• make sure the required plugins (according to the config file) are present
• execute the changes by loading each plugin and calling the desired action

It achieves the goal by calling the following modules:

The is in charge of downloading necessary plugins according to the configuration.

If a plugin with the desired version already exists locally, it will not download it again.

The statemanager manages the “state”, i.e., what has been done successfully and what not.

The statemanager stores the state in a .

A plugin implements the aforementioned, predefined interfaces.

To develop a new plugin, see creating a plugin.