3.27.0 • Published 4 years ago

webhelp-template v3.27.0

Weekly downloads
-
License
ISC
Repository
github
Last release
4 years ago

WebHelp

internal JetBrains project

Application for JetBrains products' web documentation.

Staging server

VCS: ssh://git@git.labs.intellij.net/sites/webhelp-template.git

Prerequisites

  • NodeJS >= 9.0.0
  • NPM >= 5.5.1

Installation

npm install

Tasks

  1. Start dev-server: npm start, go to http://localhost:3000/help/
  2. Build: npm run build

Run Tests

Run npm test to run all cypress tests.

Run npm run test:dev to run server and cypress for developing.

Run npm run test:visual to compare content on /help/webhelp-sandbox/1.0/all-in-one.html with base screenshots. Base screenshots are in test/visual/__image_snapshots__.

To update one screenshot do the following:

  • remove an old screenshot from the test/visual/__image_snapshots__ folder
  • run npm run collect:visual or npm run test:visual. New screenshot will be added automatically within the visual test run.

To update all screenshots do the following:

  • run npm run collect:visual.

Write Tests

To write unit / integration test:

  1. Create page /test/components/*your-page*/*your-page*.test.jsx, render components you need to test
  2. Create route for new page in file /test/test.jsx
  3. Create spec file /test/components/*your-page*/*your-page*.spec.js

\ Component

For unit testing in Cypress we've created helper component \

How to use:

  1. Wrap component with \
  2. Pass props you want to test into wrapped component
<TestRig>
  <YourComponent
    someProp=""
    someCallback={() => null}
  />
</TestRig>

TestRig will render the props as Inputs in UI, so you can pass the values in Cypress test run. Selector for props inputs: [data-test=props-yourProp].

WebHelp GitFlow Convention

main branch: master

Feature branches

Branch naming convention: task id-feature name (e.g. wh-170-add-button)

Working with branches

  1. Create a new branch from master and set a new name. For example, if you work with a new feature you should create a branch like this:
    *TASK_ID*-*FEATURE_NAME* (e.g. wh-170-add-button)

  2. Work with the branch till the task will be done

    tip: Rebase branches. Rebase your branch with the base-branch before the merger. Your commit will appear on the place after the last commit in base-branch.

    tip: Keep Up To Date. Rebase is the best way to keep your branches up to date. (Once a day, first thing in the morning, is a good rule of thumb)

  3. Merge your branch in master-branch

    tip: Squash commits before merge your branch. All the commits will be combined in one, it helps to keep clear commit history in the project. It will be “one commit” == “one feature”.

    tip: You can keep important commits unsquashed, but you should think about global project history. Is your commit really important for the whole project or it can be combined with the feature commit?

  4. Delete your branch after merge with master.

Release management

Release versioning convention: vMajor.Minor.Hotfix (e.g. v3.2.12)

Major Release

Major release is always based on changes which were scheduled and planned out in advance.

Major release must be published from master branch.

  1. Make sure that master has no issues and QA has been approved the release.
  2. Go to GitHub / Releases, push button "Draft a new release".
  3. Write a new tag version with the next major number in sequence. (e.g. v3.2.12 —> v4.0.0)
  4. Describe the release with notes and change logs.
  5. Push "Publish release" button, or "Save draft" button if you need an approval from teammates.

Minor Release

Minor release is published on the end of each Sprint.

Minor release must be published from master branch.

  1. Make sure that master has no issues and QA has been approved the release.
  2. Go to GitHub / Releases, push button "Draft a new release".
  3. Write a new tag version with the next minor number in sequence. (e.g. v3.2.12 —> v3.3.0)
  4. Describe the release with notes and change logs.
  5. Push "Publish release" button, or "Save draft" button if you need an approval from teammates.

Hotfix Release

Hotfix release can be published by demand. For example, if some bug has to be fixed urgently. Hotfix release must be published from hotfix branch.

  1. Make sure that your hotfix is merged to the master.
  2. Create new branch from the last tag. git checkout -b wh-xxx-hotfix-my-fix v3.2.12
  3. Cherry-pick the fix from master to new created branch. git cherry-pick commit-hash
  4. Go to GitHub / Releases, push button "Draft a new release".
  5. Write a new tag version with the next hotfix number in sequence. (e.g. v3.2.12 —> v3.2.13).
  6. Choose your hotfix branch as Target.
  7. Describe the release with notes and change logs.
  8. Push "Publish release" button, or "Save draft" button if you need an approval from teammates.

Module release

To release new version of modules, run npm run modules:version. Lerna will ask you which type of version you want to release (bugfix / minor / major). Then Lerna will bump version of every changed modules and will push a new tag to GitHub. After that, TeamCity should take these new tags and publish modules to NPM register.