Readme - Project structure

[drqc]

This documents the project structure for this repo:

The objective is to create a CLI to automate Dynatrace communication with third party tools. To organize the project we have:

Labels:

• SRG-automation: Everything related to SRG automation functionality
• Main-CLI: Everything related to main cli functionality including common features and libraries, CI/CD automation to compile and release and general documentation.

Other labels:

• architecture: Should be use to describe and document architecture decisions. This is an epic level task, that should result in the creation of smaller tasks with development, research or documentation tasks. Initially, use a single architecture issue per automation (i.e. one for SRG automation) so that we can collect all related info in a single ticket. (For specific development, or research information or progress use the child tickets created from this task).
• development: Should be use for actual development work (branches should be created based on this ticket level)
• documentation: For documentation related work.
• research: Should be use for research topics or tentative solutions for a problem. After the research is done, a development or documentation ticket should be created for the actual work.
• bug: To fix current functionalities already merged in dev

Projects:

To allow for ease of use of the multiple issues and features each automation should have it's own project.

• Main CLI: Tracks progress of tasks related to the general CLI architecture or documentation. i.e. cicd automation, security linting, logging, etc.
• SRG-Automation: Tracks the progress of SRG CLI tasks including configuration, execution and templating.

Milestones:

Milestones should be defined to stablish release dates and features to be included in the CLI. We will use the Github Milestones functionality for this. https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones.

How to add a Automation:

Automation definition: A automation should be a new main command added to the CLI. It should have a business purpose behind the requirement. Since this has to be defined case by case, please check with the team before creating a automation.

After defining the automation, create a new label and a new project and put the documentation here for the project structure. After that, create a feature ticket with the architecture tag to collect all the main business requirements and architecture details.

[tobigremmer-dt]

Great write up!

May I suggest that we use this as part of the contribution guide?

Also, a couple of quick notes:

• Would be great if our releases, milestones are semver compliant (https://semver.org), i.e. milestone 1.0 -> 1.0.0
• I like working with Github milestones! That being said, I wouldn't add the scope of milestones in the contribution guide rather prefer using Github native milestone functionality
• I'm missing a definition of "use case" (as in e.g. "how to add a new use case")
• "SRG-CLI" is currently listed as a project, however, it's actually "SRG automation"
• Can you help me understand the rationale behind calling the project "SRG automation" opposed to dynatrace-automation-tools or "default" project or just something more generic?

[drqc]

Agree with everything.

• semver compliant is more accurate
• Yes Github milestones are better.
• Including definition of use case. (might need some refinement)
• Updated to SRG automation
• The idea is that each use case should have it's own project to keep tickets organized since progress of each use case is independent.

[tobigremmer-dt]

As discussed:

• "Use case" really refers to specific type of automation, e.g. "SRG automation", "DQL automation", ... -> Rename "use case(s)" to "automation(s)"
• Each automation gets its own Github project where feature requests, bugs, etc. can be filed and organized -> "Default" project needed for non-automation related issues, e.g. main CLI