RepoTools Configuration

Introduction

Explains how to add Repo Tool connections and configurations in PSknowHOW application and how different branching strategies needs to be reflected on repo tool KPIs.

Add Connection

To add a new Repo Tool connection:

• From the drop-down menu, select "Repo Tool," and then click on the "New Connection" button.
  
  

Open

• A pop-up window will open. Choose the connection type as "Repo Tool."

• Fill in all the required fields to save connection otherwise, a validation message will be shown below the mandatory field textbox.

• Save the connection by clicking on the "Save" button.

• Is Connection Private: To make the connection private, tick the checkbox labeled "Private" This ensures that the connection is only accessible and visible to authorized users,
  
  

Open

Repo Tool Connection Screen Description: Field for the connection screen should be entered considering the below description.

Setup Configuration

To setup, navigate to project settings and click 'Setup' under RepoTool tool

Setup Configuration Details

• Under RepoTool Configuration page, first section shall be 'Available Connection'. Recently created RepoTool Connections shall be displayed here. Select radio button for desired connection.

• Configured Tool section shall display existing configuration with RepoTool.

• Enter the following details

• Save.

Note: For the updated data to populate after user edit the configuration, tool processor needs to be run again by navigating Settings>Misc Setting.

Edit Configuration

Once RepoTool is configured, user can proceed with validating data populated on KPI. However In case, user anticipate any changes for tool configuration

• Navigate to the Settings> Project Name >Edit

• Under RepoTool , click Edit configuration

Note: For the updated data to populate after user edit the configuration, tool processor needs to be run again by navigating Settings>Misc Setting.

Configuring branches by branching strategies

1. Feature Branching: Preferred scanning branch - default(master)

   • Number of Check-ins and Merge Requests: In this strategy multiple feature branches are merged into the master branch, hence it will have all the commit and merge information.

   • Mean Time to Merge:

     • This metric calculates the average duration required to merge a feature pull request into the master branch.

     • If master is configured it will show the average time required for a feature branch pr to be merged in master.

   • Pickup Time:

     • It measures the time elapsed from the creation of a pull request till its picked for a review.

     • The branch to be configured depends on the code review process of the team.

     • The target branch of the pull request is considered for analysis which in this strategy is master.

   • PR Size:

     • Evaluates the size of features to merge or merged through a pull request.

     • The default branch being the one where all features are merged, this will provide the size of code developed and merged into master.

   • Rework Rate: Since commits from all feature branch gets merged to master, by analyzing all these commits, it assesses the extent of code reworked.

2. Git Flow: Preferred scanning branch - development

   • Number of Check-ins:

     • Given that merges occur on the master branch during releases and hotfixes, so if only master is configured the data for recent dates will show 0 if there is an adequate gap between releases.

     • The develop branch remains the active branch, witnessing continuous commit and merge activities.

   • Mean Time to Merge:

     • This is calculated the average time between a pr is created and closed.

     • A pr to development branch is created on regular basis as and merged on completion. This will generate metrics for feature prs.

     • A pr to default is created on release and hotfix.

     • This metric for development branch will provide a better evaluation of teams operational efficiency and collaborative dynamics.

   • Pickup Time:

     • This KPI relies on the code review process.

     • If code is reviewed when merging a feature to develop branch, the development should be configured.

   • PR Size:

     • Size of pull request size dictates the efficiency of the code review process.

     • Since development branch is merged to master during release the volume will always be more and that data won’t relate to the code review process.

     • If code is reviewed when merging a feature to develop branch, the development should be the one that is configured.

   • Rework Rate:

     • This KPI is calculated by the commits on a branch.

     • Both development and master branches will include same commits.

3. Trunk-Based Development: For trunk based all the merge request and commits take place in the single main branch, hence configuring it for analysis is preferred.

4. GitHub Flow: Since this branching strategy is similar to git flow, same configuration is preferred to be followed.

5. GitLab Flow: GitLab Flow is a similar workflow to GitHub Flow but with additional emphasis on environments and review apps, facilitating continuous delivery and deployment. Configuration same as git flow is preferred to be followed.