Skip to content

Requirements

Jump to bottom
Abhideep Chakravarty edited this page Aug 8, 2020 · 3 revisions

Requirements

This page describes the requirement of the DFD Tool in brief.

Data Recording

System should be able to record the data from various DevOps tools. System should provide enough APIs for various tool, which can be called by DevOps tool in secure manner and the system would capture the data. Few such systems which can be sending data to it are:

Build tools

Build tools like Jenkins, GitHub Actions, Azure pipelines can make a call to the APIs to send the data about build details to be captured.

Version control system

Tools like GitHub, GitLab, Bitbucket etc. can use webhooks to make a call to the APIs to send data about various events like commit, merge, etc.

Quality analysis tool

Tools like SonarQube can be configured to make a call to APIs to send quality related information to the system.

Project management tool

Tools like Jira can be sending bug details to the system and its current status.

Data Display

All the collected data should be displayed in contextual format to make meaningful decision or observations. There can be few reports which can be good to start with:

  1. Build trend
  2. Build counts (individual and aggregated)
  3. Commit count
  4. Commit trend
  5. Quality snapshot
  6. Bug trend
  7. Deployment count

Configuration

This module is all about configuring various aspects.

  1. Project Configuration: Here we would be able to configure a new project. Under which we can add umber of components which are being developed in that project. Also, we should be able to configure the environments in that project with its details. Add a new new environment should be a matter of making a configuration here and all components should be ready to be deployed in the new environment.

  2. User Configuration: Here we can configure type of users from the system. Currently we can assume to have 3 roles - Admin, Manager and Viewer. Viewers wont have any edit access. Managers would have all the edit access except the administrative rights. Admins will have full rights.

  3. Tools Configuration: Here we need to register the tools so that the can communicate with the APIs in secure way. Each tool should get the Access Token with client credential grant from the OAuth server, as far as possible. In case few tools cant acquire the access token, they should be registered with an API key to make a call.

  4. System Configuration: This can be very high level configuration like integration with external aunthN system for user logins, etc.

Dynamic API

There should be some REST API which can be used for more than one resource for CURD operation. The API should be clear enough to understand and smart enough to work intelligently to work on different object in the backend.

Security

OAuth Server

System should have its own OAuth 2.0 server integrated in it. This will help the APIs to be called securely only by registered external components.

User authentication

Users should be able to login using one of the various ways:

  1. DB based credentials (Initial release)
  2. SAML based
  3. Atlassian Crowd

Non Functional Requriements

Deployment

Deployment should be very simple. One deployable. Should work in simple classical way. Should work in dockerized way and even in Kuberenets.

Scalability

In case of horizontal scaling, session externalization should work properly.

Material Design Based UI

We need to use MTL based UI for clean and clear experience.

OSS License

No OSS should be used which mandates this software mandated to be OSS under any other license than Apache 2.0

Clone this wiki locally