webhelp-template v3.27.0
WebHelp
Application for JetBrains products' web documentation.
VCS: ssh://git@git.labs.intellij.net/sites/webhelp-template.git
Prerequisites
- NodeJS >= 9.0.0
- NPM >= 5.5.1
Installation
npm install
Tasks
- Start dev-server:
npm start
, go to http://localhost:3000/help/ - 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
ornpm 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:
- Create page
/test/components/*your-page*/*your-page*.test.jsx
, render components you need to test - Create route for new page in file
/test/test.jsx
- 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:
- Wrap component with \
- 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
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)
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)
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?
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.
- Make sure that master has no issues and QA has been approved the release.
- Go to GitHub / Releases, push button "Draft a new release".
- Write a new tag version with the next major number in sequence. (e.g. v3.2.12 —> v4.0.0)
- Describe the release with notes and change logs.
- 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.
- Make sure that master has no issues and QA has been approved the release.
- Go to GitHub / Releases, push button "Draft a new release".
- Write a new tag version with the next minor number in sequence. (e.g. v3.2.12 —> v3.3.0)
- Describe the release with notes and change logs.
- 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.
- Make sure that your hotfix is merged to the master.
- Create new branch from the last tag.
git checkout -b wh-xxx-hotfix-my-fix v3.2.12
- Cherry-pick the fix from master to new created branch.
git cherry-pick commit-hash
- Go to GitHub / Releases, push button "Draft a new release".
- Write a new tag version with the next hotfix number in sequence. (e.g. v3.2.12 —> v3.2.13).
- Choose your hotfix branch as
Target
. - Describe the release with notes and change logs.
- 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.
4 years ago