Frontend workflow: Review

The following documentation on pull requests is specific to front end developers and lacks some of the more generic information regarding the topic. It is highly recommended that you read Submitting pull requests for approval and Pull request best practices in addition to this page.

Step 1: Submit pull request

Always pull main into your feature branch before creating a pull request.

1. Pull main and push feature branch to vets-website and/or content-build repositories.

   CODE

   git pull origin main
   git push origin feature/12345-issue-title

   If you are making changes in both repositories that are dependent on each other, you should give both branches in each repository the same name.

2. Create a pull request indicating that your code is ready for review.

3. Request peer review on Github by tagging a fellow team member who you feel is qualified to review the code (this prevents the pull request from just sitting). You may also want to tag developers on other teams if the changes cover more than one application.

   1. Depending on the type of work done, you may need a product person to review and / or a developer to review. See Submitting pull requests for approval for more information on how we do code reviews.

      1. If you do need approval from another team to merge your pull request, wait 24 hours after the pull request is submitted before requesting review in the #vfs-platform-support channel (unless the pull request is urgent and needs approval before the 24 hours mark)

4. Use Zenhub to connect pull request with a linked issue.
   If you use the Zenhub Chrome extension, there will be a "Connect this pull request with an existing issue" section at the bottom of Github's create pull request UI. You can click the "Connect with an issue" button to link the PR to the original issue in Zenhub.

   

5. Change status of the linked issue to validate.

Step 2: Run tests and compliance scans

• Github Actions automatically builds and runs all tests your feature branch:

  • when the pull request is created

  • after a pull request is created when the feature branch is updated

• Test results are displayed on the pull request page

  

See Frontend testing for information on running these tests locally.

Step 3: Test change manually

Manual testing can involve some separate things:

• Making sure the functionality works in the web browsers users are most likely to use

• Run the code on production-like environment. This could be done by spinning up a cloud instance that resembles production, or launching a container that is production like (such as a Docker image, etc.)

• See if there are there any bugs or unexpected nuisances that users might encounter

• Does it meet the requirements?

The person making the change is responsible for ensuring the change is adequately tested. Testing can include automated tests or manual testing by stakeholders on the review instance or staging build.

Review instance automatic creation

When a pull request is created, Jenkins automatically deploys a remote review instance of a feature branch that includes static pages and the VA.gov client application via the va-vfs-bot.

After a pull request is created, Jenkins will automatically rebuild this instance when feature branch changes are pushed.

To review dependent changes made in vets-website and content-build pull requests in the same review instance, verify both branches in each repository have the same name. The review instance deployment in both pull requests will share the same link. Changes made in either pull request will be deployed to that review instance. This branch pairing functionality will also work between vets-website and vets-api branches.

You will need your browser configured to access the vetsgov-internal domain via the SOCKS proxy. Please see Internal tools access via SOCKS proxy for detailed instructions.

Review instance manual creation

Jenkins can be manually triggered to build a review instance.

1. Visit the Jenkins Review Application Deploy job UI and log in.

2. Select Build with Parameters

3. Specify the branch names for api_branch, web_branch, and content_branch. These branches will be deployed together with the review instance.

4. When the process is completed, the URL for the review instance will be provided at the end of the output logs.

Note: A Jenkins job will run periodically and remove review instances for which the source branches no longer exist. To ensure that your instance is cleaned up appropriately, just delete the branch from the origin repository.

Peer review and merge

• Get at least one pull request approval from a peer.

  • If approval from another team is required, wait 24 hours after the pull request is submitted before requesting review in the #vfs-platform-support channel

    • Review may be requested before the 24 hour mark if the pull request is urgent

• It is recommended not to merge at the end of the day or right before the weekend unless necessary.

• Squash your commits and merge into main.

• Pull request branch should be automatically deleted.

See Submitting pull requests for approval for details on how code review work and what needs to be checked.

Help and feedback

• Suggest content changes to this page.

• Submit new Platform Website content.

• Get help from the Platform Support Team in Slack.

• Submit a feature idea to the Platform.