How to Streamline the Software Development Life Cycle (SDLC) with Keypup’s Recommended Action Field

The challenges of software development are no secret. It's a complex, dynamic, and ever-changing process. Unpredictable factors and risks are inherent in the software development life cycle (SDLC) workflow. If an organization doesn’t have the right tools or processes in place, it can make things difficult for software engineering managers to identify SDLC bottlenecks before they become a bigger problem. This article dives into Keypup’s “recommended action” field, including:

1. The primary goal of the recommended action field
2. “Recommended action” field values for pull requests
3. “Recommended action” field values for issues 
4. Keypup’s recommended actions insight template and how to use it

The Primary Goal of Keypup’s Recommended Action Field

Keypup’s recommended action field provides a suggested course of action for each issue and pull request (PR) based on contextual information. It helps software engineering managers identify where all open pull requests and issues are in the SDLC process, and provides logical recommendations to help merge requests faster. For example, when a pull request is still missing reviews, Keypup will recommend reviewing that pull request. However, if the build is failing, it will recommend fixing the build first.

The recommended action varies for issues and pull requests. Let’s dive into the logic for each.

Recommended Actions on Pull Requests

The recommended action field is based on the following pull request lifecycle industry standards:

1. A pull request is open and actively being worked on.
2. If the PR is left for a few days and no reviewers have been assigned, it is likely that the author forgot to assign it.
3. To ensure reviewers are reviewing the final version of the pull request, the PR should be up to date with the base branch (i.e., no conflicts) and must have a green build. To be approved, a pull request must receive a minimum number of approvals, which is typically set in each repository system (GitHub, GitLab, Bitbucket). Keypup believes that each pull request should have at least one approving review.
4. A reviewer rejection means the author of the pull request must perform additional work and request an additional review. This returns the cycle to step one.
5. Once a pull request is green on all three required aspects (review, build and base branch), the PR can be merged.

Based on the above lifecycle, a pull request’s recommended action field includes the following values:

• Assign reviewer: This suggested value is calculated based on the PR that has not been updated in the last three days and has no reviewers assigned. The author may have finished their work and forgotten to assign reviewers.
• Assign missing reviewers: This value means that the PR has less reviewers assigned than the number of required approvals specified in the Git repository.
• Fix build: This value means the PR build is flagged as “failing.”
• Fix code: This value means the PR has one reviewer who requested changes to the code. 
• Merge: This value means the PR is approved, has a green build and is, therefore, ready to merge.
• None: This value means the PR or issue is merged or closed. It is also used as a fallback value when Keypup is unable to identify a recommendation. 
• Rebase: This value means the PR conflicts with the base branch and must be updated (rebased).
• Review: This value means the PR is currently waiting for reviewers to perform their reviews.

Recommended Actions on Issues

The recommended action on issues is closely tied to the pull requests. Keypup uses the following lifecycle to populate the issue’s recommended action:

• An issue must be implemented by at least one pull request. The relationship between the issue and its pull request is discovered via auto-closing keywords.
• When an issue is related to an open pull request, it is considered as being implemented.
• When all pull requests related to an issue have been closed or merged, Keypup recommends the issue get closed in the near future — typically following some QA and release process outside of the Git repository.

Based on the above lifecycle, the issue recommended action field includes the following values:

• Close: This value means the pull request(s) associated with the issue has been merged or closed. Therefore, after the completion of post-development tasks such as QA, release and product validation, the issue can also be closed.
• Implement: This value means the open issue has no resolving PR associated yet.
• Wait for implementation: This value means the issue is resolved by one or several pull requests which have not been merged or closed yet.

Keypup’s Recommended Actions Insight Template and How to Use It

Keypup’s recommended actions insight template provides a count of pull requests and issues created in the past twelve months and is organized by recommended action.

With this template, users can identify where all open PRs and issues are in the SDLC journey.

The template is fully customizable so users can adapt it to meet their unique needs and processes. 

How to Use Keypup’s Recommended Action Insight Template

There are several ways to use Keypup’s recommended actions insight template. Here are just a few used by our technical lead:

Drill Down to Specific Recommended Action by Priority

You can apply filters and modify the template to drill down to specific recommended actions. For example, you can filter on the recommended action field to only select “REVIEW” ones. Then, convert the bar chart to a table chart to dig into the details. You can add as many dimensions (fields) as needed. For instance, you can include the due date as well as the author. You can also add additional metrics such as the total number of lines changed (total of lines of codes added + total of lines of code deleted). This will help you prioritize the items and also discuss priorities based on due dates and PR complexity. Our tech lead also likes to add the formula: “AVG((NOW() - updated_at)/DAY())” which provides the time elapsed in days since the PR or issue has been last updated. This helps to identify those likely to be abandoned.

Drill Down to Specific Recommended Action by Project or Teams

You can also apply filters based on specific projects (names) or users (teams). For example, you can apply filters based on an item’s title or body text or even authors’ names. This helps to facilitate bigger teams focusing only on the projects they are in charge of.

If you need the help of our solution expert to adapt this template, book a demo with us.

‍