Skip to content
master
Go to file
Code

Latest commit

The Dockerfile now uses the official Rust images and uses distroless image
as a runtime environment. Additionally, this commit updates crate dependencies.
26b90a7

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
api
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

README.md

Docker Image License

PREvant In a Nutshell

PREvant a is Docker container that serves as an abstraction layer between continuous integration pipelines and a container orchestration platform. This abstraction serves as a reviewing platform to ensure that developers have built the features that domain expert requested.

PREvant's name originates from this requirement: Preview servant (PREvant, prɪˈvɛnt, it's pronounced like prevent) serves developers to deploy previews of their application as simple as possible when their application consists of multiple microservices distributed across multiple source code repositories. These previews should PREvant to do mistakes in feature development because domain experts can review changes as soon as possible.

In a nutshell

Through PREvant's web interface domain experts, managers, developers, and sales experts can review and demonstrate the application development.

Access the application

Usage

Have a look at the examples directory. There you can find examples that deploy PREvant in different container environments:

If you want to customize PREvant's behaviour, you can mount a TOML file into the container at the path /app/config.toml. You will find more information about the configuration here.

Requirements for Your Services

PREvant is able to show the version of your service (build time, version string, and git commit hash) and also to integrate your API specification into the frontend through Swagger UI. In order to show the information, PREvant tries to resolve it by using the web-based protocol proposed by RFC 6415.

When you request the list of apps and services running through the frontend, PREvant makes a request for each service to the URL .well-known/host-meta.json and expects that the resource provides a host-meta document serialized as JSON:

{
  "properties": {
    "https://schema.org/softwareVersion": "0.9",
    "https://schema.org/dateModified": "2019-04-09T15:31:01.363+0200",
    "https://git-scm.com/docs/git-commit": "43de4c6edf3c7ed93cdf8983f1ea7d73115176cc"
  },
  "links": [
    {
      "rel": "https://github.com/OAI/OpenAPI-Specification",
      "href": "https://example.com/master/service-name/swagger.json"
    }
  ]
}

This sample document contains the relevant information displayed in the frontend (each information is optional):

  • The software version of the service (see https://schema.org/softwareVersion)
  • The build time of the service (see https://schema.org/dateModified)
  • The git commit id of the service (see https://git-scm.com/docs/git-commit)
  • The link to the API specification (see https://github.com/OAI/OpenAPI-Specification)

In order to generate the correct link the API specification PREvant adds following headers to each of these requests:

Further Readings

PREvant's concept has been published in the Joint Post-proceedings of the First and Second International Conference on Microservices (Microservices 2017/2019): PREvant (Preview Servant): Composing Microservices into Reviewable and Testable Applications. This paper is based on the abstract that has been published at the conference Microservices 2019 in Dortmund.

The talk is available on YouTube. Click on the image to start the playback:

Video “PREvant: Composing Microservices into Reviewable and Testable Applications” at Microservices 2019

About

Composing Microservices into Reviewable and Testable Applications

Resources

License

Releases

No releases published

Packages

No packages published
You can’t perform that action at this time.