How does Cubyts determine the release status of Features & Issues?

Modified on Thu, 13 Feb at 4:59 AM

This article comprehensively covers the released status of Features & Issues in trace reports. The release status of an artifact represents its final state, indicating deployment to a higher environment or the conclusion of underlying code changes after merging with a configured production branch. Users can use this status to determine the completion of the Feature, Issue or code’s journey. 


Configuration to compute the "Released" status for Features & Issues


The platform computes the released status of Features & Issues based on the deployment status of PRs which relies of one of the below specified conditions:

  1. (Condition 1) Has the PR been deployed in a production branch? This condition can be leveraged only if a CI/CD tool is integrated with the platform (with relevant job configuration). Check this article to integrate with Jenkins.
  2. (Condition 2) Has the PR been merged with the configured main branch or the master branch (with the check enabled to treat the merge with the branch as a release indicator)? Check these article to activate the configuration for Github, Bitbucket or Gitlab.
    1. Github integration.
    2. Bitbucket integration.
    3. Gitlab integration.


Important points to note:

  1. For most customers, the second configuration should be sufficient.
  2. Customers without access to CI/CD pipelines should also use the second configuration.
  3. Customers with access to CI/CD pipelines who need accurate release status determination based on deployments across environments should use the first configuration.
  4. If neither the first nor second configuration is set, the platform cannot compute the release status. In such cases, we recommend the following:
    1. Hide the "Released" column in the Feature Progress, Issue Status trace reports. 
    2. Hide the "Deployed (to Prod)" column in the PR Summary and Code review summary trace reports.
    3. If you have not integrated with the CI/CD tools (for Condition 1), then hide the "Deployment status", "Deployment summary" trace reports.
    4. If you have not integrated with the CI/CD tools (for Condition 1), then hide the "Deployment errors" widget in the "PR status" and "Code review status" trace reports.

Deployment status for PRs (in production)

(PR summary)


(Code review summary)


The deployment status of a PR is used by the platform to compute the released status of a build issue. The deployment status of a PR in production can be seen in the PR summary/Code review summary report (the user can apply appropriate filters to view PRs that are deployed in production or not).


The deployment status (in production) is computed for every PR  based on the above mentioned conditions i.e.:

  1. (Condition 1) If the PR deployed in the production environment via the configured production job then the released status is marked as "Yes".
  2. (Condition 2) If the PR is merged with the configured main branch or the master branch (with the check enabled to treat the merge with the branch as a release indicator), then the released status is marked as "Yes".
  3. If one of the conditions or both conditions result in a negative outcome then the deployment status is marked as "No".
  4. If neither configurations are done then the deployment status is marked as "N/A".
  5. If both configurations are done then condition 1 takes more priority compared to condition 2.



How does the platform compute the "Released" status for Features & Issues using the Deployment status (in production) of a PR?


Released status for Issues


The released status of an Issue can be seen in the Issue status report (the user can apply appropriate filters to view Issues that are released or not released).


There are a few considerations for the computation of Released status for Issues (in a project management tool like Jira):

  1. The released status is computed only for Build issues or Development issues.
  2. The released status is computed if and only if one of the above mentioned configurations are done in the workspace.
  3. The released status is computed if and only if the Build issue or a Development issue has PRs associated with the issue (or it's subtasks). 
  4. The released status of an issue will be shown as "No"  if: 
    1. The issue and it's subtasks have not reached the terminal state (e.g. "Done") OR
    2. One of the PRs associated directly with the issue or indirectly with an issue (through it's subtasks) is not deployed in production as per the conditions mentioned earlier in the "Deployment status for PRs" section.
  5. On the contrary, the released status of an issue will be shown as "Yes" only when: 
    1. The issue and it's subtasks have reached the terminal state (e.g. "Done") AND 
    2. When all the PRs associated directly with the issue or indirectly with an issue (through it's subtasks) is deployed in production as per the conditions mentioned earlier in the "Deployment status for PRs" section.


Released status for Features

The released status of build issues belonging to a Feature can be seen in the Feature progress report (check the column titled "Build issues, Released and Others).


The Feature progress charts showcases the released status of build issues based on issues associated with the features using the same logic mentioned in the earlier sections.


Conclusion


The released status of a Feature and Build issues is critical to understand the successful culmination of any job undertaken by the team, the Cubyts platform enables the Engineering lead/manager or a Project/Program manager or a Scrum manager to continuously monitor the conclusion of a job with simple configurations.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons

Feedback sent

We appreciate your effort and will try to fix the article