Development practices

Development workflow

1. Follow README.md instructions for setting up the dev environment.
2. Create a local feature branch off the latest develop and switch to it.

• Use the naming scheme <initials>/<short-kebab-case-description> (example: gg/hot-buttons). This reduces potential conflicts and signifies a responsible party for the branch so that it can be deleted when stale.
• If starting a collaborative or long-lived feature branch, use the naming scheme feature/<short-description>.

1. Run gulp.

• Fix any console errors (caused by merge conflicts, broken unit tests, failed linting, etc.) until the server starts successfully.

1. Go to the local LiveReload server at localhost:9000/packages/docs/dist/.
2. Write code.

• The dev server will hot-swap CSS changes.
• If you edit KSS markup or TypeScript code, you will need to refresh the page.
• Follow our Coding Guidelines.

1. Watch the gulp console output for compilation & linting errors; fix them.
2. Write unit tests for your change.
3. Commit your code with a descriptive message.

• If your change resolves an existing issue (usually, it should) include "Fixes #123" on a newline, where 123 is the issue number.

1. Push your feature branch to your fork of the blueprint repo and open a PR.

• If your change is visual (most Blueprint features are), include a screenshot or GIF demonstrating the change.
• If you have permissions, mark the PR with the label "PR: needs review" so we know it's ready for us. You can use the "Status: work in progress" label if you're not ready for full code review yet.

1. Get approval from the Blueprint team.

• When addressing feedback, push additional commits with just the revisions. Be descriptive in your commit messages: prefer "fix style nits" to "address CR feedback" every day because the former provides context at a glance.
• Each successful build will trigger a comment on the PR with a link to the compiled artifacts on Circle. This notification is usually enough to signal reviewers that there are new changes.

1. Squash & Merge

• We use GitHub's Squash & Merge feature to maintain clean history on develop. It's great.
• If you're not a core contributor, please let a team member merge your PR.

Running unit tests

gulp karma runs all the unit tests in PhantomJS. You may run a specific sub-project's tests via:

gulp karma-blueprint-angular
gulp karma-blueprint-components
...

Alternatively, gulp karma-unit-<project-name> runs tests in Chrome where you can debug them more easily.

Developer priorities

1. fix the build if you broke it
2. have lunch/dinner
3. fix P0 issues
4. leave the office
5. review others' pull requests
6. update an existing pull request based on the code reviewer's feedback
7. fix P1 issues
8. fix issues blocking others (in case they aren't already P1)
9. write new code (ERs, FRs, tasks)