What We Can Help With - Platform Support

Access requests

• Google Analytics: Learn how to request access to Google Analytics.

• Questions/problems related to SOCKS access: Accessing Internal Tools - SOCKS

• Sidekiq: Sidekiq UI Access

• Flipper: Flipper UI Access

• vets-api ArgoCD: Vets API on EKS Access

• TestRail: Guide to TestRail

We do not grant access to Datadog, GitHub, or Azure.

See #github-information for GitHub access questions.

App setup

• Being a partner and resource as you get the app running on your system.

• Front-end: See Run and build VA.gov locally.

We do not do the setup for you.

Automated tests

• Troubleshooting relating to PRs. Before you reach out, make sure your branch is up to date and that the failures are not related to your PR.

We do not provide assistance with writing new automated tests.

CI error

• Troubleshooting and enabling checks.

We do not do any type of revamp of a CI step or the CI process overall.

Collaboration Cycle

• Reviewing Collaboration Cycle GitHub tickets, addressing touch points.

We do not build projects or features for you.

Console UI

• We handle questions regarding Cypress tests, pull requests, out-of-band deploys, and the deploying to staging schedule.

Datadog

• Changing existing accounts from a “read only” role to a “standard role”, also known as “write access”.

We do not own Datadog and do not grant initial access. The Datadog monitoring tool is managed by the ECC team.

Design System

• PRs where the Design System team is a reviewer.

• If a developer is having trouble using the forms library or building a form.

• If a developer is using the Design System and encounters an issue.

We do not answer general Design System questions. All questions should be posted in the #platform-design-system or #design channel.

Environments

• Questions or failures in dev, staging, sandbox, prod, forward proxy, revproxy.

We do not grant direct access to prod; this is started by Support and submitted for approval by OCTO-DE.

Forms

• Behavior of forms in staging.

Google Analytics/Domo

• Granting access to Google Analytics and Domo via Analytics team.

Off-cycle deployment

• revproxy requires OCTO-DE approval

• For vets-api, vets-website, devops(including revproxy) deploys:

  • Notifying OCTO-DE via PagerDuty for approval.

  • Running the off-cycle deployment.

We do not create the off-cycle deployment GitHub issue with all the required information for OCTO-DE to review. (vets-api, vets-website, devopsdeploys)

Platform website content

• Intake of content update requests.

• Check for broken links.

We do not check for the following:

• Page appears incomplete or in draft state.

• Missing introductory/contextual content.

• Images lack captions or alt text.

• Missing “Help and feedback” footer.

• Title contains placeholder text (e.g., “Copy of”).

• Missing or incorrect “Last Updated” date.

Platform website deployment/publishing

• Updating support pages with current information and practices.

We do not manage content updates. If a content update is needed, it is the responsibility of the owner/team of content to make the necessary changes.

Pull request (PR) approvals

• Pull requests of a size that can be reviewed in an hour, which is <500 lines of code.

• Front-end: Reviewing PRs on vets-website and content-build where VA Platform CoP Front-end is a codeowner.

• Back-end: Reviewing PRs in vets-api, vets-json-schema, vsp-infra-application-manifests, and devops repos where backend-review-group or Platform-console-servicesis a codeowner.

• DevOps: Reviewing PRs in vets-api, vets-json-schema, vsp-infra-application-manifests, and devops repos where VA Platform CoP DevOps is a codeowner. Minor infrastructure related changes are okay.

PRs are evaluated based on their impact on the Platform as a whole, NOT your team-specific goals for behavior. You must test your proposed behavior with at least one new or changed test in the PR and a review from another engineer more familiar with the PR's intended goals.

Front-end/Back-end/DevOps:

Reviewing PRs where the reviewer is NOT one of the groups described to the left.

Review instance

• Issues with Jenkins and deployments.

Security

• Get your solution tested for potential technical security issues/vulnerabilities, focusing particularly on frontend-backend interactions, anything involving certificates or cookies, or any new interactions with dependent backends.

Slack

• Redirecting issues to the proper channel when #vfs-Platform-support is not the correct venue.

We on the Platform do not have administrative control of Slack. OCTO Slack request management is under AES and is handled in JIRA via the DevOps Tool Suite (DOTS) Team. To request Slack access for a new employee, follow these instructions.

If nobody in your company has access to OCTO Slack, coordinate with your Product Owner.

SOCKS

• Troubleshooting access issues.

Test accounts

• Questions pertaining to the Test User Dashboard (TUD). See Test User Dashboard Guide.

We do not create new test users.

Test failure

• Troubleshooting E2E failures on existing tests, re-running tests, inspecting failures.

We do not provide assistance writing new automated tests.