Skip to main content

    Write

    We're moving our docs!

    Find the latest version of this page on the Platform website.

    Still can't find what you're looking for? Reach out to #vfs-platform-support on Slack.

    Choose an issue to work on

    • Work with your team to determine the right issue to work on

    The VA handbook has more information about the broader process for delivering services to Veterans on VA.gov. Developers work in an agile framework, where issues are assigned to sprints and developers work on this items over the two-week sprint period.

    Create feature branch

    • Checkout main branch and pull the latest
    git checkout main && git pull origin main
    • Create a new feature branch from main
    git checkout -b feature/12345-issue-title

    Since most new work derives from a GitHub Issue, it's recommended to prefix your branch name with the issue. For example, if you're working on a feature to collect a veteran's address as detailed in Issue #25, you might call your issue 25-address.

    Code new functionality

    • Write the code for the new feature! This is often the fun part. :-)

    It's very helpful if you restrict the scope of changes to only the issue/feature that you're working on. For example, you might see some code you can cleanup along the way and decide to change it. However, this increases the scope of your changes and increases risk if your commits/feature need to be rolled back (and the rollback pulls other things with it). It also helps your code reviewer, because they aren't left wondering how a tangential change impacts the feature promised by the pull request.

    As you code your changes, commit changes to your feature branch. Commit early. Commit often.

    Write tests for new functionality

    • Unit: Tests a specific method or very granular piece of the code base.
    • End to end: Tests how your code works when clicked through in a real browser.
    • Accessibility: Tests that run automated checks to catch some basic accessibility mistakes. Typically these are incorporated into end-to-end tests.

    These tests are automatically executed during review, but you should run them locally before moving on.

    The only way to quickly know if your new change breaks the existing functionality of the application is to have a suite of automated tests that execute whenever new stuff is added. When you add new functionality, new tests are required so that future developers know if they have broken your contributions.

    Manual Testing

    • Test new functionality on supported browsers