Skip to content

Latest commit

 

History

History
349 lines (207 loc) · 13.9 KB

File metadata and controls

349 lines (207 loc) · 13.9 KB

DENIM Web

pipeline status

📣 Description

This application enables to download, reverse engineer, visualize, and analyze the evolution of a microservices architecture from a data perspective.

⭐ Features

Here is a summary of the features currently supported.

Downloading

Description

The downloading feature allows to download the entire codebase of a microservices architecture from GitLab or GitHub, even if it is spread across multiple repositories.

Implementation status

Feature Implementation status
Download GitHub 🌕
Download GitLab 🌕

How to?

Downloading

See Reverse Engineering Dynamic.

INPUT

The user is supposed to enter, on the Downloading page, the list of repositories to download, while respecting the following format: https://(github|gitlab).com/<user>/<repository>/tree/<hash>.

OUTPUT

The result of the downloading is a ZIP file containing the entire codebase. The ZIP file can be analyzed by the Reverse Engineering features.

Reverse Engineering

Description

The reverse engineering feature allows to analyze, statically or dynamically, the entire codebase of a microservices architecture from a data perspective.

Implementation status

Feature Implementation status
Static Analysis 🌕
Dynamic Analysis 🌕

How to?

Static Reverse Engineering

See Reverse Engineering Static.

INPUT

The user is supposed to upload, on the Static Reverse Engineering page, the ZIP file containing the downloaded codebase.

OUTPUT

The result of the static reverse engineering is a JSON file containing the static analysis report. This static analysis report can be visualized by the Visualizing features.

Dynamic Reverse Engineering

See Reverse Engineering Dynamic.

Visualizing

Description

The visualizing feature allows to visualize a high-level view of the microservices architecture under the data perspective. It proposes several visualization describe hereafter.

  • Treemap: This visualization represents a microservices architecture under the form of a treemap. It highlights the repositories, directories, and files where an API or data access is identified. The visualization is further enriched with interactive features, enabling developers to explore various levels of detail within the microservices architecture and its associated data accesses. For instance, the interactive treemap displays additional information on hover. It also supports what-if analyses, helping developers assess the impact of changes such as data concept modifications or technology switches. It also offers insights into the distribution or concentration of technologies, operations, code fragments, or data concepts. In that sense, it highlights the heterogeneity of technologies, either at macro (i.e., codebase-level) and micro perspectives (i.e., file-level). Furthermore, the treemap assists in evaluating the size of codebase components and identifying whether certain portions are data-related or not. In terms of quality assessment, it contributes to localizing potentially isolated and/or highly nested code fragments, important to consider in the case of an eventual refactoring phase. Finally, it is enriched with extra interactive features like the jump to a data access code fragment directly in the GitHub repository, the zooming in the treemap, etc.
  • Timeline: This visualization represents a microservices architecture usage under the form of a timeline. It represents the temporal call sequence and code fragment usage over time. The visualization is further enriched with interactive features, enabling developers to inspect various temporal phenomena in the microservices architecture and its associated data accesses. For instance, it allows to replay the call sequence, pause, fast-forward, zoom-in, zoom-out. Finally, it is enriched with extra interactive features like the jump to a data access code fragment directly in the GitHub repository.
  • Animated Heat Treemap: This visualization represents a microservices architecture usage under the form of an animated heat treemap. It extends the treemap with lines and heat colorization according to the temporal call sequence and code fragments usage over time. The visualization is further enriched with interactive features, enabling developers to inspect various temporal phenomena in the microservices architecture and its associated data accesses. For example, it allows to replay the call sequence, pause, and fast-forward.

Implementation status

Feature Implementation status
Treemap 🌕
Timeline 🌕
Animated Heat Treemap 🌕

How to?

See Visualizing.

Treemap

INPUT

The user is supposed to upload on the Treemap page a static analysis report.

OUTPUT

Treemap of the Overleaf's August 5th, 2021 AM version

Filtered Treemap of the Overleaf's May 8th, 2026 version

Timeline

INPUT

The user is supposed to upload on the Animated Heat Treemap page a dynamic analysis report.

OUTPUT

Animated Heat Treemap of the Overleaf's March 18th, 2025 version

Timeline

INPUT

The user is supposed to upload on the Timeline page a dynamic analysis report.

OUTPUT

Timeline of the Overleaf's March 18th, 2025 version

Evolving

Description

The evolving feature allows to analyze the versions of a microservices architecture under the data perspective. It proposes several visualizations and metrics describe hereafter.

  • Comparison Treemap: This visualization expands on the treemap by offering a mirrored view of the versions or interval of versions, and especially highlighting the intra-version and inter-version code fragment similarity coupling perspective.
  • Difference Treemap: This visualization expands on the comparison treemap by offering a mirrored view of the versions or interval of versions, and especially highlighting the inter-version evolutionary difference coupling perspective of code fragments, files, directories and repositories.
  • Evolutionary Treemap: This visualization expands on the treemap by offering a unified view of the versions history, and especially highlighting the extra-version evolutionary coupling perspective.

Implementation status

Feature Implementation status
Comparison Treemap 🌕
Difference Treemap 🌕
Evolutionary Treemap 🌕

How to?

See Evolving.

Comparison Treemap

INPUT

The user is supposed to upload on the Comparison Treemap page static analysis reports.

OUTPUT

Comparison Treemap of the Overleaf's August 5th 2021 AM and May 8th 2026 versions

Difference Treemap

INPUT

The user is supposed to upload on the Difference Treemap page a static analysis reports.

OUTPUT

Difference Treemap of the Overleaf's August 5th 2021 PM and May 8th 2026 versions

Evolutionary Treemap

INPUT

The user is supposed to upload on the Evolutionary Treemap page a static analysis reports.

OUTPUT

Evolutionary Treemap of the Overleaf's history

👩‍💻 Development details

Setup

See INSTALL file.

Test the app (manually)

  • Build the application.
    npm run build
  • Launch the application.
    npm run start
    The app runs at http://localhost:4173/.

Test the app (unit testing)

Unit test suites are set up thanks to the Vitest framework.

The tests are specified in the /tests/unit directory and are named following the *test.js pattern.

Launching the tests

  • Launch unit tests.

    npm run test_unit
  • Launch unit tests in development mode (continuously watching for new tests).

    npm run test_unit_dev

Test the app (UI unit testing)

UI unit test suites are set up thanks to the Cypress framework.

The tests are specified in the /tests/components directory and are named following the *cy.js pattern.

The configuration of Cypress is stated in the /cypress.config.js file. Some support files are stated in the /cypress directory.

Launching the tests

  • Build the application. ⚠️ WARNING! This step is very important to take into account the changes! ⚠️

    npm run build
  • Launch unit tests.

    npm run test_unit_ui
  • Launch UI unit tests in development mode (opening the Cypress tests console).

    npm run test_unit_ui_dev

Test the app (UI integration testing)

UI integration test suites are set up thanks to the Cypress and start-server-and-test frameworks.

The tests are specified in the /tests/e2e directory and are named following the *cy.js pattern.

The configuration of Cypress is stated in the /cypress.config.json file.

Preparing the environment

  • Build the application. WARNING! This step is important!
    npm run build

Launching the tests

  • Launch integration tests.

    npm run test_integration_ui
  • Launch UI integration tests in development mode (opening the Cypress tests console).

    npm run test_integration_ui_dev

Debug

  • Launching the debug mode to get access to developers tools. This mode is preferred when developing as it automatically rebuild and reload the app at any modification. It avoids to rebuild the app at any time.

    npm run start_dev

    The debugged app runs at http://localhost:5173/ and developers tools run at http://localhost:5173/devtools/.

Linting

  • Lint the application.

    npm run lint

Formatting

  • Formatting the application.

    npm run format

CI/CD

A CI/CD process is set up thanks to GitLab CI/CD. Learn more about GitLab CI/CD via this page.

This one is described in the .gitlab-ci.yml. Warning! Right privileges must be granted to Docker on the session on which the CI is executed.

🪛 Technical details

Technologies

  • JavaScript
  • Docker

Libraries

Project configuration

  • vue is a front-end JavaScript framework.
  • vue-router is used for the routing.
  • vite is used for bundling.
  • axios is used for HTTP calls.

Tests

Format

  • eslint is used for linting the code.
  • prettier is used for formatting the code.

Tools

🤝 Contributing

If you want to contribute to the project, please consider the following instructions:

  • Any contribution must be tested (unit, integration, and UI tests).
  • All the tests and the CI/CD pipeline must pass before definitively integrating the contribution.
  • Any contribution must be documented, especially by updating the README.md and the INSTALL.md file.
  • Any contribution must be approved via the pull request mechanism.
  • More generally, any contribution must follow the conventions and keep the shape of previous contributions.