Just finished a project and get tough on line, with some experience of the entire project process and gitLab norms, to popularize the new student.
The first products will be to write a requirements document, we have to look at the project requirements document to have a general understanding, then shout back-end product, ui, together with the front end of the discussion - about the project, the project has a clear understanding, if the discussion we have not done during the function, we need research. Let's look at Figure unfinished ui think about the entire interaction flow diagram of the project can not feel what local logic and ui, product heads together to discuss when I remember to call on the back end, you do not have a good discussion of the back-end people do not change You know how it's going. If you look at some of the uncomfortable awkward layout, but you can talk to and ui ui-based, after all, people do this, as well as the company first came we certainly did not encounter psd diagram you can not regulate the amount but also need to comply with conditions three out of the way you ask ui psd diagram, there is to look up "web-side interaction norms" and let ui identify the pixels in the distance on the map. The third are generally, but because we have the component library are not usually measure the distance.
For projects with a clear awareness you can begin to draw class diagrams, class relationships to identify what the connection point with the open this link has detailed https://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html , or not draw class relationships do not understand can ask their teacher, the class diagram is the top priority really is time to start writing code to keep a class diagram to do. mock at this time can also be developed with the background.
Then, after completion of the ui map, we can begin to draw a timing diagram of the interaction, interactive timing diagram to reflect the operational processes and user interactivity, interactive timing to give complete picture ui look at the interaction which areas have the problem will ui and you said.
Complete picture so that the master or head of the check, and then you can start rehearsal, and rehearsal that you take these two figures, to explain to the rest of the team, especially the timing diagram of interaction and team members need to agree on ideas, considered preview success. After the rehearsal through, where their project needs to split issue in gitLab,
Of course, the first issue is the title of the project: the development of rehearsal Description: Such as: Exam v1.0 project milestones, preview the results - including class diagrams timing diagrams and interactive components, which send comments to interact timing diagrams and class diagrams, developers preview through the issue, and the head of the comments may be closed to develop a preview issue.
When you create an issue you need to review this issue in the estimated time as / estimate 2h, h when h, d is the number of days.
The actual time required to complete the review issue / spend 2h If the actual time exceeds the estimated time to review long beyond reason.
A complete issue of the process:
Create issue comment above figure ---- ---- Estimated completion time of the issue prepare a complete change issue mark, choose to push the issue when the branch target deadline for the completion of the code ----- ---- the comments on the issue real time - if timeouts in the comments timeout reason --- to the issue merge onto dev
Complete all ready mentioned test issue, mentioning the need for a code review before testing, code reviews to create a problem if the issue be examined out of which the description of each issue are written on each question and then create a separate issue, if there is no problem to find the person in charge of the review carried out by the comments, and then merge dev release
Dev needs to be configured before merging release good webpack, to the address you want to test the operation and maintenance of the project, to the back-end to back-end service test address.
Merge to release and run the project, even if success is measured mention, if you find a bug test for him will be created during the testing issue and the issue is assigned to you, if you find that your problem is in the back-end test and say let him appoint to the back end, after comments received issue issue estimated time, change the end time, we need to review the actual completion time after the completion of the branch name to create according to the following chart:
Then you put your fix / xxx branches merging to merge into the dev release and assigned to the test, and then close the issue.
After testing, the test will create a pre-online notification, we front-end checks in the pre on-line issue inside and check the check items, and then test the relase merged into the master assigned to the product, turn off the product after the merger on-line notification issue, on the line if found bug to create a product created when the RC milestone, pointing RC milestone online bug issue, create a branch in the master branch, bug completed branch hotfix / xxx merger dev, dev merge directly to the master.
After the last line of the project is no problem, master the merged back into dev and release. Finally, the project will open wrap-up meeting to remember when summarize a few points, and finally write the project summary written project wiki.
