Working process
For tracking our SDLC we use Project board in GitHub. We have 6 columns: Backlog, To Do, In progress, Design review, In testing and Ready to release.
Backlog column: all the created tasks that have the UUI project appear here. It happens automatically after creating a new task.
To Do column: when a task is scheduled for execution, it falls into this column.
In progress column: tasks get here after they are taken into work.
Design review column: if the task needs to be reviewed by designers, it should turn out in this column after the "In progress" column.
In testing column: after the end of the development process, developer creates a PR, the code is merged into the Dev branch, and the task is moved to this column. Testing on the project occurs only according to the Black box method, therefore, only those tasks that the tester can check get into this column. If the tester cannot check the task using the Black box method, developer moves it immediately from the "In process" column to the "Ready to release" column.
Ready to release column: when the task is verified, the tester moves it in this column. The task also gets here bypassing the column "In testing", if the tester cannot check it using the Black box method.
After release, all tasks from the column Ready to release are closed with "Released in ver. X.Y.Z" comment and archived.
- Task should be merged to the Dev branch (need GlobalProtect);
- If the task hasn't been completely implemented or if there are differences from the description → Add a comment directly to the task;
- If you have fixed a bug or added code that should be tested → Add tests;
- Check that the test suite has passed (yarn test), update the snapshots if necessary;
- If you make Api changes or add New Functionality → Add example(s) to the component Documentation and update Property Explorer page;
- Add a short description of your changes (fix, new functionality, etc.) to the changelog.md.
More details on developing and creating a PRs can be found here.
At the moment we use three main types of issues: bugs, features, and improvements.
A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways (from Wikipedia). We use the label bug for this type of issues. Also we can add additional labels, e.g. RTE, Promo, Loveship, etc. More information on how to report a bug you can find here.
Any new characteristic of our library, e.g. new component, changing an existing component, adding properties, etc. We use label feature for this type of issues. Also we can add additional labels as well as for bugs.
If a part of a component or functionality can be improved, we use the label improvement.
These are tasks that we are use only in the project team.
There are two ways to move tasks around the board:
