Core Concepts Overview¶
Let's assume you're familiar with core Git, Docker, Kubernetes, Continuous Integration, Continuous Delivery, and GitOps concepts. These are the core concepts of DevStream.
The Architecture of DevStream¶
The architecture image below shows how DevStream works in general:
Config, Tool, State and Resource¶
The architecture documentation explains how in general DevStream works. If you haven't read it yet, make sure you do that before continuing with this document.
DevStream defines your DevOps toolchain in config files.
We have three config files:
- main config file
- variable config file
- tool config file
The main config file contains:
varFile: the file path for the var file
toolFile: the file path for the tool file
pluginDir: the directory path for the plugin directory, default: ~/.devstream/plugins, or use
-dflag to specify a directory
state: settings related to the state. For more information, see here.
The variable config file is a YAML file containing keys and values, which can be used in the tool config file.
The tool config file a list of Tools, each containing its name, instanceID (unique identifier), and options for that tool.
- Each Tool corresponds to a plugin, which can either be used to install, configure, or integrate some DevOps tools.
- Each Tool has its Name, InstanceID, and Options, as defined here.
- Each Tool can have its dependencies, which are specified by the
dependsOn is an array of strings, with each element being a dependency. Each dependency is named in the format of "TOOL_NAME.INSTANCE_ID".
See here for example.
The State records the current status of your DevOps toolchain. It contains the configuration of each tool, and the current status.
- The State is actually a map of states, as defined here.
- Each state in the map is a struct containing Name, Plugin, Options, and Resource, as defined here.
- We call what the plugin created a Resource, and the
Read()interface of that plugin returns a description of that resource, which is in turn stored as part of the state.