How to set-up Cubyts for the Pilot phase?

Integration: 

Start by integrating with Jira and the Version control system deployed in your enterprise (e.g. Github, Gitlab or Bitbucket).

References:

1. Refer to this article for Jira integration.
2. Refer to this article for Github integration.
3. Refer to this article for Gitlab integration.
4. Refer to this article for Bitbucket integration.

Basic set-up

Set-up your workspace name to represent your company/team and sync interval (Workspace -> Settings)

We recommend a daily sync closer to the end of the business day to ensure recommendations are available before the start of daily rituals.

Team

Invite team members using their email id (Reference article)

Flags:

Steps to enable/disable flags (Cubyts workspace -> Flags -> Settings to enable/disable flags)

(click on the gear icon to enable/disable flags)

(enable/disable flags based on the list mentioned below)

Enable the following flags in the first week of pilot: 

1. Technology flags -> Whilst you can keep all the flags on here, we recommend to start with a smaller set on day 1, experience the outcomes and expand the list on day 2, here is a prospective list for day 1: Branch/PR has risk of bugs, Branch/PR with regression issues, Branch/PR with knowledge gaps, Branch/PR with code smells, Branch/PR has broken access control, Branch/PR has cryptographic failures.
   1. Note: The platform has enabled this flag for PR analysis only (you can change the flag configuration to support branch and PR analysis).

(click on a flag to open the configuration)

(select PRs and Branches in limit settings, set the timespan to the lowest possible number to facilitate the platform to pick PRs/Branches with the most recent changes)

Enable the following flag configuration in the second week of pilot:

1. Process flags -> Aging build issues (this flag will ensure that the evidences generated by the platform is picked up by the SCRUM team based on the aging rule).
   1. Set the aging rule based on the urgency of resolving code base changes suggested in the Jira ticket (created as evidence by the platform).
   2. Select only the issue types that will be configured for generating evidence (see the second point).
      
2. Technology flags -> Enable auto-resolution for the technology flags in week 2.
3. Auto-resolution of flags -> The auto-resolution workflow will automatically resolve the entire flag or a sub-set of issues in the flag (depending on the configuration) and create evidences for the resolution in Jira (in the selected project and based on the selected issue type) based on the origin of the original issue (associated with the PR):
   1. In every run, the platform will auto-resolve flags and will either create new issues or update existing issues in Jira. Note:
      1. If the PR is open (and upated) and the platform discovers more issues then it will simply update the Jira ticket.
      2. A ticket is created for a PR/Feature branch per flag which is activated.
   2. The newly created issue will be auto-assigned to the engineer (who was responsible for the original Jira ticket associated with the PR). 
   3. The original Jira ticket will be automatically linked to the newly created issue in Jira.
   4. The new ticket will be created in the same project as the original Jira ticket associated with the PR.

(enable auto-resolution, select Jira reporting as an option and choose either "All issues" or "for each severity" as an option)

Trace: 

Steps to enable/disable trace reports (Cubyts workspace -> Trace -> Visibility settings):

(click on Visibility settings to enable/disable reports)

(enable/disable trace reports based on the list mentioned below)

Enable the following trace reports in the first week of pilot:

1. Team trace reports:
   1. PR/Branch assignments summary.
2. Delivery trace reports:
   1. Feature progress.
   2. Issue status.
   3. Sprint progress.
3. Code reports:
   1. Code branch summary.
   2. PR summary.
   3. PR status.
   4. Code review summary.
   5. Code review status.