How-to: Deploy JackHenry.Dev

Things to know

There are 3 parts of what is considered to be “JackHenry.Dev” that our team manages (and other parts which we do not…more on that later).

Parts we manage

  1. JackHenry.Dev homepage
  2. Digital Toolkit docs
  3. Developer Dashboard

Parts we do not manage

Everything else.

  1. Anything in the Enterprise Solutions like jXchange/SymXchange
  2. Anything in the Payments area

Deploy: JackHenry.Dev homepage

URL: https://jackhenry.dev

GitHub repo: node-developer-portal (wiki entry)

(Adapted from Slack conversation in #proj-jackhenry-dev-authenticated-cred-mgmt.)

  1. (Optional) If needed, build a new version of the ux-developer-portal.
  2. Be sure to first merge the PR that includes your changes to the node-developer-portal repo.
    • If you forget this step, you’ll have to run through the entire deployment twice.
  3. Go to https://jenkins.banno-tools.com/view/Prism/job/node-developer-portal%20-%20release/
    • Click Build Now to create a new version.
  4. Go to https://jenkins.banno-tools.com/view/Prism/job/node-developer-portal/job/master/
    • Watch for a build labeled with the release version x.x.x (example 0.90.0).
    • This will take ~5 minutes.
  5. Once that build makes it to the Waiting for Approvals stage in the Jenkins pipeline, then you know it has sent out an email for approvals.
    • This is the list of managers who can approve the deployment: Approvers for Banno Deployments
    • This is by far the step that takes the longest.
    • Unless you can ping a manager who can do the approval for you. Otherwise you’re at the mercy of random chance of a manager from the list of approvers noticing the approval email.
  6. After a manager from the list of approvers has approved the deployment (which they do by responding to an automated email), go to the job details by clicking the version number (example 0.90.0).
    • Click Paused for Input in the sidebar (refresh the page if it isn’t there…you may have to wait up to 2 minutes from when the manager’s approval email was sent).
    • Check the box readyToDeploy.
    • Leave the canaryWeight input field blank.
    • Click Proceed. (It may take up to 2 minutes from when you click Proceed before the next step ‘Production’ starts.)
  7. This will now deploy to Production (which takes time).
  8. (Optional) After deploying to Production, the Jenkins job will pause again for 7 days. It does this to give you the option to rollback/revert the deployment.
    • If you need to rollback: click Paused for Input.
    • On the Rollback to previous version? screen (but only do this if you need to revert!): click Proceed.

If you run into a problem, see the “jackhenry.dev Deployment Issues Previously Encountered” section below to review issues we’ve run into in the past.

Deploy: Digital Toolkit docs

Public URL: https://jackhenry.dev/open-api-docs/

GitHub repo: open-api-docs (wiki entry)

The https://github.com/Banno/open-api-docs repo has a protected master branch which prevents direct commits to the master branch and therefore requires pull requests to be created for new changes.

When a PR has been approved by at least one reviewer, then it can be merged to the master branch.

Merging to the master branch automatically kicks off a GitHub Actions workflow which will deploy the latest docs. This only takes a few minutes. (See them here https://github.com/Banno/open-api-docs/actions)

The implication is that code changes and content changes can be deployed to the Digital Toolkit docs at any time 24 hours a day, 365 days a year. (Assuming that nothing is wrong with GitHub itself: https://www.githubstatus.com)

Deploy: Developer Dashboard

URL: https://jackhenry.dev/portal/dashboard

GitHub repo: ux-developer-portal (wiki entry)

Steps TBD.

  • It apparently involves some manual steps to be run locally, per the README.

jackhenry.dev Deployment Issues Previously Encountered

This section captures some of the odd deployment issues we’ve run into and the steps we took to resolve them.

In general, your best bet is to reach out to the Prism or Apollo teams for assistance when these deployments go sideways.

Failure in the “Waiting for Approvals” stage

On 2/4/2024 we attempted a simple deployment which failed in the “Waiting for Approvals” stage. One of the collateral build threads also failed in the Build stage.

Failure board

Jaime did receive the approval email and was able to approve that.

We reached out to org-prism for help. Erik Heikes from the Prism team said that since Jaime was able to see and approve the deployment email, that we could use a special link to manually start the deployment: https://jenkins.banno-tools.com/job/thread-pipeline/

I went to that link and saw a subset of the build threads that we typically see. Nothing was happening, so I clicked on one of the boxes and saw a popup asking about deployment.

Thread pipeline

I wasn’t 100% sure how to proceed, but this looked similar to some of the prompts we follow in the normal deployment process, so I left canaryWeight blank, clicked the readyToDeploy checkbox, and pressed the Proceed button.

The deployment ran for about 10 more minutes after which the site was sucessfully deployed.

When we asked, the Prism team offered this feedback on why this build failed:

In general, Dobby have been making a lot of changes to the infra scripts and such, so things have been breaking from time to time. Usually ignoring or retrying can get around it.

The error in the prod deploy is googleapi: Error 400: Precondition check failed. So that was either a mistake with an infra script or a problem with the Google API.

The error with the 662 build is An unexpected error occurred: “https://registry.yarnpkg.com/http2-wrapper/-/http2-wrapper-2.2.0.tgz: Request failed "500 Internal Server Error"”. which was probably a temporary glitch with the yarn/npm registry.

So it sounds like if this happens again, we should attempt to restart the process.