Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Bug management

This section describes how the bugs reported by our Customers, the Konverso QA, or any other party involved in the product, are tracked and managed.

The issues reported by the Customer or directly linked to a particular Customer project are tracked in a dedicated ticket, in one of the following portals:

In the event that a bug is reported to Konverso by Email, Phone, or another non-formal way, then the Konverso Consultant or Support member will create a ticket on the relevant portal, setting the reporting user as the reporter on the ticket.

If the bug has an Infrastructure cause, Konverso will create and link a dedicated DevOps ticket, assigned to a Consultant or Ops team member.

Suppose the bug has a kbot implementation root cause. In that case, Konverso will create and link a dedicated Kbot Developer ticket, assigned to a relevant engineer, and assigned to a particular sprint based on its criticality.

Once the solution is identified and implemented:

  • If a code change is involved, a dedicated pull request is created to obtain code reviews approvals

  • A QA will validate the change in a developer environment.

  • A Consultant will validate the change in a Customer pre-prod or dev environment.

Once approved by the Consultant, the customer ticket is updated with a comment explaining the correction. The Customer received a notification.

Following the customer notification, the change may then be deployed. Depending on its criticality, urgency, and impact, the change may be done on:

  • Production environment after notification to the customer

  • Pre-Production environment, with a notification to the customer, with typically a request for feedback / and confirmation of resolution. Once approved, then the change is deployed to production on a schedule agreed upon with the customer.

Note there is no rule on the deployment timeline. This may vary from as low as 10mn to several months, depending on the severity, impact, and complexity of the bug.

Infrastructure Changes

All infrastructure changes, typically on our Azure IAAS environment are done through a change request in the form of a ticket in our dedicated Jira project (DO). The tickets in this project have a clear definition of the target Azure resources, a list of reviewers and approvers, and some target delivery dates.

The changes made to the infrastructure are documented on the related ticket.

As a set of examples, the scope of Infrastructure Changes includes:

  • Network and an associated firewall.

  • VM resources and associated specifications (size)

  • Service objects such as Microsoft Bot Service, OAuth2 end points as Applications, etc.

  • IAM (permission) changes.

  • No labels