¶ A pure headless API Service
Some like bugs to eat, other to treat. Modern Organizations who produces Websites, head-less CMS or Software for its clients, have the requirement to have a track about issues, possibility for improvements or Bug solving, summarized as quality management.
¶ If you are looking for an UI enabled solution
There are many good bug trackers out there. And we also built-in a really simple but powerful issue tracker into our PVYbusines-OS, which can, if a Bug Report, Claim or Issue has been confirmed, pushed over PVYbugtrackers API Handler into favorite Coding Repositories like:
- Gitlab.com (or self hosted)
- Github.com
or utizing web-hooks or Rest-API call to any capable system, which is may already in use, but lacks such integrations.
¶ Possible Protocols for Bug Submitting
- Rest-API
- Web-hook
The aim of PVYbugtracker and the problem it is addressing. And there are other problems which can be addressed as well. The following given example is our own problem we faced and how we address it.
¶ How we utilize it
Depending on the Software Product, we built-in Feedback Forms. Those can be triggered from the user itself to give a valuable feedback, report a bug and optionally attach its log file (Mobile & Desktop Apps.)
¶ Use case 1
User triggers a feedback. Rest-API call based on Schemata and App Identifier for that product, informations are being pushed to our PVYbusiness-OS, and based on choosen Feedback Category, it will create an Issue with its classifications.
With this szenario, our first level support team can qualify the issue, and once qualified, its being pushed further over Rest-API to the GITLAB Project as a qualified issue, which reduce the clutter and time for the Developers.
¶ Use case 2
User triggers a feedback. Rest-API call based on Schemata and App Identifier for that specific product will be routed from the Bugtracker API straight into the responsible GitLab Server Project as an Unqualified Issue.
The Route are being always desiged based on standardized Schemata as known from Gitlab/Github Issue creation, over the Bug, either to one of associated routes based on the given configuration in a .yaml file like:
- AppName (mandatory)
- Gitlab/Github Project-ID (mandatory for Git)
- Routing URL:
- Gitlab/Github URL or PVYbusiness-Suite URL
with optional fields for:
- Hidden: Platform OS, DeviceModel
- Description Short (Mandatory)
- Description long
- how to reproduce
- attached logfile
¶ The choice of the Code Repository
If you concern about various aspects like security or other benefit using a GitLab Server in your Environment, then have there 4 Options to choose:
¶ Using Github
A really nice environment, started as Open-source, still maintain Open-source but owned by Microsoft. It is worth to the reading the terms.
¶ Using Gitlab
Gitlab.com also offers Hosted / SaaS Accounts, but also Self-hosted on your own Infrastructure. That’s our choice.
The Problem is their Feature Policies. We all agree, that Issuess related to Code Repository shall be managed within that Repository, with an Issue Tracker, which is also built-in the Open-source Free Version. But if you also concern about Stats, Pre-Qualifying submitted bugs, so you don’t clutter your devs with non-reproducable Issues they have to deal with, you are in a one-way-road, especially, if you need to maintain multiple Repositories, in our case above 130.
If you like to have nice Analytic Dashboards, which are not only project / repo specifiy, you have to buy a very expensive GitLab Premium or Ultimate Subscriptions. For Start ups, almost not affordable, for mid-side Businesses hardly.
¶ Utilizing PVYbusiness-OS and GitLab Server
How we address these two common Problems with a missing analytics per Project and Overall and also the requirement for pre-qualification or such submitted Issues, which is in our Case straight built-in into the Desktop Apps, Moblile and Web Apps ?
We built a very ease of use Issue Tracker into our PVYbusiness OS, which handles and classify Issues in following Issue-Types:
- Project Issues
- Product Issues
- Customer Claims
It looks like this:
Each of them has additional conditional classification, based on its parent. So for a few Apps, we utilize the PVYbugtracker as API Routing Service, which looks template based different for each Product/Project/App and send it first into our PVYbusiness-Suite where the submitted informations are being pre-set as an Product-Issue, and record is being created over API. Straigt as User Feedback from the App in Production itself.
That being said, our team can pre-qualify those issues submitted to us, and by the same time, separate the wheat from the chaff and ensure that only pre-qualified and reproducible bugs are created in Gitlab Enterprise Server.
So, if in PVYbusines OS, the Issue got qualified with Status “Confirmed”, we push that over API to its final stage, the Issue Tracker on the GIT Project itself. (Of course we also added a Product Management Feature in PVYbusiness Apps, which contains Project ID among other nice to have features.)
From this moment, the PVYbusiness Suite run’s its Flow BPM and utilize the required Template to create that issue with the original submitted Logs (if attached) from the Reporter Device, but also value added screenshots or videos, how to reproducde for the devloper, and send this again over the API to the GITLAB as new Issue, and assign it to the lead developer of that given project.
¶ Schemata
Once pushed from the Business-Suite into GitLab Enterprise, developer can work on it:
¶ Summary
PVYbugtracker is powerful API Service as Middleware to handle your Bug and Issue Reports straight from any App within a User Interacton to report a feature-request or bug report.
Since PVY stands for Privacy, we truly relay on bug reports, since we do not inlude other Analytic Softwares for Production Builds. The Bug Tracker can easely handle a few millions request per minute and is flexible how you like to define the targets. But you need a little Coding Skills, at least how to fill out a yaml.conf file.
¶ Some Sample Configuration
Let look on some common API routes for the most common use cases:
- Push Issues to Github.com
- Push Issuhes to GitLab self-hosted
¶ Pre-requisites
For the Notifcations you need to have either an SMTP Mail Server Account, or you define just to receive it somewhere else as a Message via Web hooks.
- Mail Server Settings for Notifications (What has been submitted, what did go wrong)
- Web-hooks into Slack or PVYmessenger
¶ Configration
To use the PVYbugtracker, you need to have it on your PVY@Cloud Subsription or add it over PVYappstore. Its deployed automatically under you main domain with bugtracker.mytld and the configuration you can make as PVY-ID Org Admin straight within PVYcentral. To do so, navigate to your «Applications» Menu, chose PVYbugtracker and there you can conifgure your salted API Key, and adding your Products/Apps where you can easy configure it for each product on the Web Gui, pretty self explaining, with fields and routes:
¶ Create new App
- AppName*
- AppStore SKU
- App Identifier
¶ Route Dropdown
- Gitlab Server
- GitHub.com
- PVYbusiness OS
¶ Form fields
Enable the Form Fields you like to inlcude in App and Destination Reporting. Save
For Phyton, Vue and React you see example code to integrate it to your project. Once compiled or deployed, the route works immediately as configured. Parameters are quite simple:
- Configure the Route (URL or IP) to your Destination per App/Project-ID, based on the Scheme and API available on the Target
- Integrate a Feedback form into your Web App or Mobile App