@twexchangesolutions/hubot-jira-deployment

jira-deployment-hook

Ensures that all deployments are associated with a Deployment Task and that that Deployment Task has all the proper approvals per our Audit Requirements.

Requirements:

• Set of Hubot Scripts
  • @hubot deploy TW-123 where TW-123 is the Deployment Task to trigger
  • @hubot deploy TW-123 --dry-run which performs a Dry Run of deployment to ensure audit requirements are in check.
  • Help descriptions are output when running @hubot help
• 1 Deployment Task must be specified
• A Deployment Task must first go through a dry run operation before it can be deployed.
• Deployment Tasks must have one or more issues linked as relates to.
• During a dry run, the Deployment Task must be in the QA Approved state
  • The last change time on the Deployment Task must be the same as the last transition time, or hubot will move the Deployment Task back to Open and exit with an error.
  • If the two times are the same, it will transition to a Hubot Dry-Runned state.
• During an actual deployment, the same check above happens, but checks for Hubot Dry-Runned state instead of QA Approved.
• Each issue linked to a Deployment Task must be one of:
  • Story
  • Maintenance Task
  • Bug
• Each of the issues linked (or one of their children) in the Deployment Task must appear in the Git history range at least once.
• Each linked Story must:
  • In the 'Complete, Not Delivered' state
  • Linked to approved initiative
  • Have no open Sub-tasks or Feature Defects
• Each linked Maintenance Task must:
  • In the 'Complete, Not Delivered' state
  • Have no open Sub-tasks or Feature Defects
• Each linked Bug must:
  • In the 'Complete, Not Delivered' state
  • Have no open Sub-tasks or Feature Defects
• Story, Bug, or Maintenance Task issues that are mentioned in the Deployment Task Description do not have to pass the above restrictions.¹
• Every linked issue or one of its subtasks or feature defects must appear in the Git History since last deployment
• When all checks are valid (NOT DONE IN DRY RUN MODE):
  • Tag the production build number in the Deployment Task.
  • Transition each linked relates to issue that is not mentioned in the Deployment Task description to Deployed.
  • Need to authenticate to Jira in order to do these, that configuration should come from environment variables (preferrably preffixed with HUBOT_) using a Jira Auth Token.
• Detailed error output
  • Error output should list all offenses so they can all be easily addressed.
• Progress output will be helpful for QA to know that Hubot is triggering builds and waiting for them to complete.
• Should be fast, this will require a number of network requests so the work should be launched as parallel as possible.

Footnotes:

1. This is what will buy us the flexibility we should need as it allows QA to document exceptions of any kind without complex link relationship types.

s parallel as possible.

Deployment Tasks can be found at: http://jira.extendhealth.com/browse/TW-4384?jql=issuetype%20%3D%20%22Deployment%20Task%22

Production Publishers: http://teamcity.extendhealth.com/project.html?projectId=ProductionPublish&tab=projectOverview