Configuration
This page will be dedicated to an overview of the configuration primitives that the Developer Multitool uses. Each section will have a brief description of the primitive and then a short description of an example of its use. At the end of the section, we link to a more thourough guide for each primitive which includes screenshots.
Projects
A project is the topmost unit of organization for DMT. Projects can help organize your different software projects into logical units that can be deployed and released together. The first step in setting up the DMT is to create a project that you can interact with.
Repositories
Repositories are links to software repositories that you are interested in building. You add a repository which creates a URL that you can add to your software's repositories host. Currently, Gitea is the only supported repo tech, however, we hope to expand this to github, gitlab, gogs and others in the future. You'll need to add a repository in order to use other functions like builds, deployments, and releases.
Components
A component is a software component that you will build. For lots of software projects, you'll end up with repositories for different "components" for a variety of platforms. For instance, you may have an API backend, an angular or react frontend, then an iOS and an Android app. It's possible these components will share a repo or all be seperated into different repos. By having a separation of the Component from the Repository, its possible to configure a project to build all kinds of project architectures (monorepos, microservices, etc)
Identities
An identity corresponds to the authentication and authorization a Workflow will have. Roughly speaking, identities will indicate a user on a host. You can have multiple identities for multiple hosts or multiple identities for a single host that is running different users.
Environments
Environments are bundles of identities. This allows you to seperate the identies that you run in one environment from the identities that are used in another environment, however the structure of the identities will be the same. You can imagine a setup where you have development, staging, and production environments which all leverage the same identities, but then provide different credentials for each environment. This way you can use the same workflow structure in each environment, but different hosts will be leveraged depending on which environment a task runs against.
Workflows
Workflows are a representation of Jobs, Tasks, and Variables that makes it easier to see the visualize their flow. We can string together Tasks to create Jobs. Jobs are then executed against Environments which will indicate what Identity to use. The environment will also dictate which Variable will be used. Variables exist on the Project level, but they can be overrode by the Environment. This allows for a "base" configuration and then expanding on that base for different environments where different variables might be needed. Examples would include overriding the database URL that is used in production vs what is used in development.
Jobs
Jobs are a collection of tasks.
Tasks
Tasks are single units of work defined by Plugins
Variables
Whenever an instance of a task is made, corresponding variables are created on both the project and the environment. You can configure the project variables with the base settings for the workflow, and then override those variables an a per project basis.
Execution
Runs
Everything in the system is a run. A Run is an instance of a Job (or workflow) that has occured against an environment. The "Run" is the most basic unit of execution for DMT.
Builds
Builds are a particular type of "Run" that exist as a result of a Branch Event that occurs on a Repository. When a Job is triggered that is tied to a Component, a Build Instance is created. The Build Instance will end with an Archive of the build that occured.
Deployments
Once we have a Build Instance, we can "deploy" that Build Instance. This will generate another special type of run called a Deployment Instance. The deployment instance should end with your software deployed to an environment.
Releases
Releases take a Build Instance and create an archive that includes all the code you need to distribute your software. Creating a release will end with an archive that can be uploaded to a distribution mechnism (http, ftp, Play Store, iOS Store)
Putting it all together
When you add up all these primitive pieces, you have everything you need to build and deploy software from a multienvironment, multiversion perspective. This means you can more efficiently track changes in your code bases and create releases across mutliple operating systems, interpretor versions, library versions, and anything else that you might want to track. Take a look at the Cookbook section for some real world examples of how all this configuration can be combined into a powerful tool for software development.