Architecture Design
- Reporting WebPage - This component represents the user interface of CAS that runs on the web browser.
- CI Tool Configure WebPage - This component represents the user interface of a CI tool that runs on the web browser. The responsibility of CI Tool Configure WebPage is allowing the user to configure CAS authentication information on it.
- CAS Web Service - This component is the service/controller part of CAS, which uses Django framework.
- CAS Container - This represents the Docker Container that CAS Web Service runs in.
- PostgreS - This PostgreS database stores the users, projects, controllers that registered in CAS, and the data of parsed reporting result.
- Testing Tool - This component represent several testing tool that are integrated in Jenkins, such as SonarQube. The testing tools are supposed to generate testing reports.
- Testing Report - The testing reports are the testing result generated by the testing tools.
- CI Tool - This component represents Continuous Integration Tools, such as Jenkins.
- Plugin - This is plugin of CI tools. The responsibility of it is to transfer reports that are generated in Jenkins to CAS web service.
- DevOps Container - This component represents the Docker Container(s) that run the CI tool(s), CI plugin and testing tool(s).
- We decide to make CAS a web service. The reason is that our system is supposed to be deployed distributedly, and it will be running continuously. In this way, CAS can serve multiple users and integrate multiple CI tools at the same time. RESTful api can separate the functionalities of CIP and CAS. When CIP is modified or added new plugins for other CI tools, CAS will not be affected.
- We decide to use container because it is easy to deploy. Using container also makes our project scalable during the run time. Operator can add more containers to support more concurrent users.
- We decide to build a CI plugin (CIP). Since CAS is able to retrieve report from various CI tools, including Jenkins, Travis, etc. according to QA-M01. CIP is indented to integrate with different CI tools and send a standard form of static analysis report to CAS system.
- We decide to use PostgreS as our database because it is NoSQL. In addition, our major data form will be in document, which is also supported by PostgreS. Last but not least, PostgreS is one of our technical constraints brought up by our customers.
- An alternative DB is MySql + MongoDB. Mysql is RDBMS which does not support document format. So we added MongoDB which can store document with NoSql. We abandoned this design because it would cost more time, effort and resources to configure and develop on two databases.
- We decide to use https because it is easy to use and it provides desired security features for our connections.
- Reporting Service - This unit will maintain the content that will be shown on the dashboard. It will fetch data from DB connector, and then choose the desired content for the reporting webpage.
- Connection Service - Connection service will interact with CIP service, retrieving data from CIP and forward the report to the DB connector and the parser for further processing.
- DB connector - This component is responsible to connect with the database and fetch data and write data to database.
- Parser - parser will process raw report from connection service, and then parse it according to user’s requirements.
- Connection Service and Parser will run in separate threads with asynchronized call. The reason of this design is that the parsing process may take a long time, and in the meantime another project build will be finished and new testing reports will be generated.
- We decided to put the static analysis testing report parser on the CA server instead of the Jenkins plugin.
- An alternative is to put parser on the Jenkin plugin. It can help to decrease the data need to be transferred from Jenkins to CA server. However, it would increase the complexity of the Jenkins plugin. Future developers need to spend more time on developing plugins for other CI tools. It is against our quality attribute of modifiability (QA-M01 and QA-M02). So we decided to put parse on the CA server.
- CASWebService - This component is the web based service of CAS, which uses Django framework. The responsibility of this part is to parse the testing report, update data in database, visualize the parsed result mapped to the user-specified controller and so on.
- CIPlugin - This unit will be responsible for interacting with different CI tools. It will fetch report from CI tools, and then turn the data into a standard form required by CAS service (e.g., JSON file).
- CIPakage - This is used by CIP to support interactions with various CI tools.
- Django - A Python based web framework, which follows the model-view-template architectural pattern.
We choose Django as the framework of CAS web service. Django is a popular Python based web framework that is fast, fully loaded, scalable and secure. It provides a streamlined approach to developing. In addition, our clients also ask us to use Django because they Django is popular and is easy to use (TC-06).
- HTML Templates - This package contains HTML files of user interface of CAS web service.
- Models - This contains the Python classes that specify the fields in the database tables.
- Parser - This class is responsible to parse the testing reports and map the results to the controllers that specified by the user.
- Views - This Python class contains the logical code of controller/ service part of CAS web service.
We decided to make CIP to communicate with CAS web service Views via RESTful API. The reason is that different CI tools should have their own dedicated CIP. The implementation to add a new CIP should not affect much of CAS web service(QA-M01).
- ReportParser - The base class of Parser.
- SonarQubeParser - This component is dedicated component that parse the testing reports generated by SonarQube.
- VeracodeParser - This component is dedicated component that parse the testing reports generated by Veracode.
We decided to have ReportParser as a base class. Different testing tools will generate testing reports in different format, so Parser needs to take care each of them separately. Thus, abstract the common features of parsers will allows following developers to add more types of parsers for other reports easily (QA-M02).
- End User Machines - These nodes are users’ machines where they use web browser to visit the CAS service website.
- Container - The container may be deployed on cloud server(e.g. AWS Container) or on user’s private machine.
- DB Server Machine - Any machine that can run the PostgreS DB server and provide the PostgreS DB as a service. May be physical machine or virtual machine.
We decided to put PostgreS on a server machine instead of a container. Because database is critical service and the server machine is more reliable than containers.