I
Go to file
epattison 7215ce2dfa Add Renamed.md 2025-08-16 00:07:30 +00:00
Artifact chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Build chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Incident chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Pipeline chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Report chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Scan chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Source chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Task chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Ticket chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
.gitignore chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
README.md chore: creating an initial set of documentation 2025-03-26 20:17:49 -06:00
Renamed.md Add Renamed.md 2025-08-16 00:07:30 +00:00

README.md

Metisyn

Metisyn is a project management ecosystem built out of decoupled components. Each component should provide a core API to make state reqeusts into the system and can be made of multiple event processors to integrate with other components and a UI micro-app to be embeded in the main project UI.

The Metisyn spec defines the expected events. This will allow components to be used independantly, new components to be added over time, or for custom conversion components to allow integrating third-party APIs into the system.

One of the driving ideals behind this project is cloud first, so each component will be made of contanerized subsystems, should support flexibility in data storage technologies, and other clound-native principles and practices.

Components

Here's a quick summary of the components that make up the metisyn ecosystem, you can get more details under each components link.

Source

The Source component manages all of the source code repositories that belong to the project. The base implementation will be built on top of git, but systems could be written for other scm systems.

Pipeline

The Pipeline component is an automation system. It can be used to define complex, customizable processes you need to execute based on events flowing through out the metisyn ecosystem. This will be managed through an event driven flow where the pipeline defines events that need to be processed by other components in the ecosystem.

Scan

The Scan component is a system capable of providing static code and security analysis tooling into your systems.

Artifact

The Artifact component is a system to store your artifacts for the project.

Task

The Task component is used by those working on the project to track tasks being worked on

Ticket

The Ticket component can be used to track user-reported issues or larger epics of work

Report

The Report component is a visualization tool to view all aspects of the work

Incident

The incident component can be used to integrate with monitoring tools to report incidents and alerts

Build

The Build component is responsible for managing the build processes for your project

Events

Each component will define the spec specific to messages that component is responsible for emitting, so in this overview section we'll just cover common aspects. All events will follow the CloudEvent Schema. Within the CloudEvent payload, the following standards will be used, with all fields required even if the CloudEvent spec defines them as optional:

Data

The data property, and by extension the datacontenttype, will be application/json

Type

The type property should always match the pattern "io.metisyn.{component name}.{event type}"

Id

The Id property should be a UUID, but no specific version is required.

Time

The Time property should always be UTC

Source

The Source property should always be the name of the originating application, even if not a metisyn component.

Subject

The Subject property will be a component specific identifier related to the reason the event was triggered. For example, each Source component should be able to handle multiple repositories, the subject would be the unique id for the repository that generated the event.