DevOps

Development Practices

• Break down work into the smallest incremental change possible
• Limit work in progress to 2-3 items per person
• Pull/get the latest code every day and before starting new development
  • When resolving merge conflicts and checking in new code:
    • Do not rely on auto-merge features
    • Carefully compare diffs of individual files to the latest version
    • Ensure any unintended changes are not included
• Continually test changes throughout the development cycle
  • Testing is not a single step that happens after 'dev complete'
  • Testing should happen through the entire development cycle: dev testing, QA testing, automated testing, accessibility testing, usability testing, performance testing, etc.
• Create frequent, small pull requests/changesets that touch as few files as possible
• Submit pull requests/changesets for code review
• Address code review feedback
• Perform peer code reviews on the latest pull requests/changesets

Definition of Done

• Feature complete
  • Matches mockups
  • Has accessibility attributes
  • Is responsive
  • Has input validation, e.g.: required
  • Has error handling (error states & messages)
  • Any tech debt is marked with // TODO: comment
• Code meets code standards
• Code is formatted consistently and cleanly
• Code has been linted
• Code has been reviewed
• Code review feedback has been remediated
• Passes accessibility testing
  • Keyboard
  • Screen reader
  • Browser extensions
• Passes cross-browser testing
• Passes automated testing, e.g.: Selenium, GitHub, Netlify, Sonar, etc.
• Application does not have console errors
• Documentation is complete

Acceptance Criteria

We recommend the follow acceptance criteria for front-end development:

• Show that code is reusable and uses global components
• Show that code does not contain custom CSS
• Show that code was tested across browsers and operating systems, and with assistive technology, and the UI looks and functions as intended based on the tier

Browser Support

This list will evolve as we receive more data. We recommend all products use Google Analytics. Contact Jamie Connor for more details.

Please note: All products should be tested across browsers and operating systems, and with assistive technology (e.g.: screen readers).

Tier 1

The interface looks and functions as intended in the mockups.

• Chrome
• Firefox

Tier 2

The interface doesn’t need to look perfect, but should function as intended. It must be readable and usable, and it should degrade gracefully.

• Edge
• Safari
• Opera
• Recent versions of Chrome, Firefox, Safari, Edge

Unsupported

• Internet Explorer
  • Microsoft says: Internet Explorer is a compatibility solution. We’re not supporting new web standards for it. ... If we continued our previous approach, you would end up in a scenario where, by optimizing for the things you have, you end up not being able to use new apps as they come out. As new apps are coming out with greater frequency, what we want to help you do is avoid having to miss out on a progressively larger portion of the web!
  • Epsilon sent out an email January 23, 2020: Microsoft has announced a vulnerability that impacts users who browse the internet using Internet Explorer... Use another supported browser, such as Chrome, Firefox, or Safari.

Analytics data

Harmony browser data as of January 2019:

Automated Code Quality Tooling

Automated code quality tools are not a replacement for human code review or manual testing, but they are a great supplement! Below is a list of automated code quality tools that we use and/or recommend.

Linters

We use ESLint and stylelint across our product suite. See Introduction for instructions on installing ESLint and stylelint, and using the custom configurations that align with our front-end code standards.

Benefits

Linters:

• provide real-time feedback
• automate code quality control
• reduce the amount of human code review needed, and allow code reviewers to focus on providing higher-level feedback
• help avoid errors
• enforce best practices and coding standards

ESLint

ESLint is a linter for JavaScript and JSX.

Stylelint

Stylelint is a linter for css and scss syntax.

There are stylelint extensions available for VS Code.

More automated code quality tools

pa11y

Pa11y runs automated accessibility tests.

Note: pa11y is not designed to be a complete replacement for regular accessibility testing. Think of it as being complementary to your existing workflow (which should include testing with actual users).

tota11y

tota11y is an accessibility visualization toolkit.

Deque

Deque's mission, vision, and passion is "digital equality." They offer several tools, trainings, and services to find and fix accessibility problems.

WorldSpace Attest

WorldSpace Attest incorporates automated accessibility testing into the development and implementation phase of web and native mobile development processes.

WorldSpace Assure

WorldSpace Assure is step-by-step manual accessibility testing and reporting tool that enables functional testers with minimal accessibility knowledge to create precise, comprehensive, and consistent accessibility issue reports for developers.

WorldSpace Comply

WorldSpace Comply helps ensure large websites become and remain accessible. It's used to dynamically scan, monitor, and report on the accessibility status of a site across business and development teams.

axe

axe is a free browser extension for automated accessibility testing.

axe for Web

axe for Web is an open source accessibility rules library for automated testing. It can be customized to include custom rules and to integrate with all modern browsers and testing frameworks.

ngA11y

ngA11y is an Angular accessibility module.

SonarLint

SonarLint is an IDE extension that detects issues in HTML, JavaScript, TypeScript, and other languages.

SonarQube

SonarQube is an automatic code review tool to detect bugs, vulnerabilities, and code smells in your code.