I have been working in my current company for more than 2 years. How time flies! In two years, the front end went from a single man to the current size of 10 men. If YOU ask me, what is the most important part of this process? I think it’s a down-to-earth r&d process.

When it comes to research and development processes, most people will definitely put the research and development processes of certain large factories first. Admittedly, the r&d process of big factories is perfect and meticulous, but in fact, it is not necessarily applicable to other companies or teams, such as QA, unit testing, automated testing, I think many companies do not have. Therefore, blindly applying the RESEARCH and development process of other companies or teams may not suit the environment, but it can provide us with a reference to make up for our own shortcomings.

The r&d process must not appear in a vacuum; it must be closely aligned with the actual project process. I take this very seriously, when I was “light rod commander”, I was preparing. I, the idea is that the group into a person’s time, I will not tell him holding each step of the project to do how to do it, but with the standardization of document copy down the whole process roughly, in addition is also want to tell my future colleagues, I have a thinking and precipitation, the team is worth grow together!

The r&d process is certainly not perfect, but it is certainly updated. I reviewed the document and revised it more than 100 times.

Next for the front-end research and development process to share our practice, hope to give friends in need a little help!

The whole process

The overall research and development process of the team is as follows:

Probably most of the companies in this area are the same, there is nothing to detail. In fact, may each link is implemented in place also need to play a question mark.

Front-end DEVELOPMENT process

System image

In order to facilitate new employees to get into the state quickly, we made a unified image of the front-end development system, to avoid problems arising from computer installation and various environmental configurations, resulting in unnecessary communication and waste of time.

At the earliest, or I out of a simple document, tell new colleagues to install what what software this way, but found a lot of problems, after using the mirror, worry a lot.

Front-end development flow chart

This diagram depicts the main day-to-day development process of the front end, so take a minute or two to look at it.

Research and development resources

  • Prototype design:axure
  • Visual design: Blue Lake,iconfont
  • The API documentation:swagger
  • Agile collaboration:TAPDDaily tasks, requirements, defects and so on are focused onTAPDOn the platform.
  • Source code warehouse: self-builtGitlab
  • Team documentation: Whisperbird

Handle IconFont ICONS

In the section of icon management, we use iconfont, which is useful for both font icon and vector icon, and encapsulates the corresponding components icon-font and ICon-SVG. At present, icon-FONT is mainly used for some projects.

After adjusting the icon on iconFont, you need to regenerate the link;

  • For the font icon component icon-font, generate an online font class link that replaces the corresponding link in the project’s index.html.

  • For the vector icon component icon-SVG, generate an online symbol link that replaces the JS link referenced in the ICon-SVG component.

Issue driven

Git Log does provide the ability to record queries, but it’s not easy or intuitive enough.

We use issue-driven development, and all code changes should be created in GitLab first, including but not limited to requirements, defects, self-testing, and optimization class changes.

Commit automatically associates and closes issues. This way, I can open each issue and know which code commit records are associated with it. In addition, this is a common way for many open source projects to collaborate.

For development tasks of requirements and defect types, you should attach TPAD related links when creating an issue for easy query.

An issue should be atomic and do only one thing.

The development process

VSCode extension

First, install the necessary VSCode extensions, combined with the Lint/Formatting capabilities configured in the project, to achieve an efficient development state.

Global reliance on

// Ensure the normal operation of YARN
npm install -g yarn
// Used to regulate commit
npm install -g commitizen
npm install -g conventional-changelog-cli
Copy the code

NPM/yarn agent

Sometimes the speed of the NPM source is too slow or a package cannot be downloaded at all, which may cause the install to fail or stop. Please use the Taobao agent.

NPM config set registry/https://registry.npm.taobao.org/part of the project using yarn yarn config set registry https://registry.npm.taobao.orgCopy the code

Nginx agent configuration

We use Nginx as an intermediary agent locally to the developer, adding a layer of local Nginx agents for the following purposes:

  • Unified service ports for project access to prevent missubmission of project configuration files and avoid unnecessary code conflicts.
  • It is easy to switch different environments in seconds without restarting the devServer. The latter part can be optimized. According to my observation, ant-design-pro implements the update proxy without restarting the devServer.
  • If you do not want to add the local Nginx layer, you can specify the back-end gateway address, but be careful not to submit the vue.config.js file to avoid conflicts!
  1. To download the Windows stable version of Nginx, go to nginx.org/en/download…

  1. Modify the nginx/conf/nginx. Conf

A basic proxy configuration is as follows:

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    #gzip on;
    server {
        listen       8090;
        server_name  127.0.0.1;

        location / {
            proxy_pass http://xxx.xxx.tech;
            proxy_http_version 1.1;
            proxy_set_header   Upgrade          $http_upgrade;
            proxy_set_header   Connection       "upgrade";
            # proxy_set_header Host $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}}}Copy the code

Nginx listens to 127.0.0.1:port and sends proxy requests to the back-end gateway. You only need to change proxy_pass when you need to switch environments.

  1. By default, the target of the front-end proxy is set to http://127.0.0.1:port. Do not change this parameter when the proxy is used with Nginx.

  2. Common command

Nginx = nginx = nginx = nginx = nginx = nginx = nginx = nginx = nginx Nginx.exe -s reload/nginx.exe -s reload/nginx.exe -s reload/nginx.exe -s reload/nginx.exe -s reload/nginx.exe You can simply open task Manager to find all nginx processes and then terminate them. Finally, open nginx.exe directly to start.Copy the code

About this link, I have previously written a “front-end must see” this Nginx reverse proxy skills, to help you get off work on time to accompany the goddess, want to know more about friends can open to see.

Project Dependent Installation

Currently, some projects use NPM to manage their dependencies, while others use YARN. When entering the project, check the lock file. If yarn.lock exists in the root directory of the project, yarn is used. If the project has package-lock-json, use NPM.

To install dependencies, run the following commands based on the situation:

  • npm
npm install
Copy the code
  • yarn
yarn
Copy the code

Requirements/defect allocation

The TL is responsible for task assignment, assigning requirements on the TPAD, and assigning development responsibility.

After the TAPD requirements are distributed to individuals, developers are required to split the front terminal requirements (not limited to one), assess the development time scale according to their own capabilities and complexity of requirements, and fill in the estimated start time and end time according to their own schedule. The project manager will follow up on this and take responsibility for the individual. If there is a risk of overdue, inform TL or your mentor of the reason in advance, and do not expose the problem until the last day.

In principle, the development time scale should be determined during requirements review, but considering the actual situation of the team, this authority is delegated to the developers themselves to evaluate, but TL needs to play a supervisory role. You can think about it in terms of the actual situation.

Create issue

In principle by the developer to create, create requirements and bug class issue, should be attached to the TAPD link, easy to query related matters! The issue is also a basis for branch naming. I’m going to talk about that.

In some cases, the TL or the project Owner will arrange some tasks within the group that are not managed by TAPD, which will be directly referred to the developer in the form of issue. After receiving the issue, the developer does not have to create the issue again, but just create a local branch based on the created issue.

Branch Permission Control

In our team, there are three important branches, which are:

  • Develop: Develop a branch
  • Release: Test branch
  • Master: Production branch

These three Branches are set as Protected Branches, usually associated with the CI/CD configuration of the corresponding environment. Maintainer has the Merge permission, but no one has the push permission.

In practice, a basic Merge direction is:

Depending on the situation, you can also introduce branches such as pre-release branches.

If branch permissions are not controlled, people can push at will, which means potential disaster can happen at any time. So this is very noteworthy!

Create a branch

I’ve tried branching semantically before, but have found that it’s always a false proposition to use a limited number of words to describe a complex meaning. We may create a branch named feature/ XXX when creating a new feature, and then create a branch like feature/ XXx-optimization when there is a need for an optimization class. However, often a feature will be optimized, changed or bugged again and again, and adopting such naming strategy will always expose you to soul questioning!

And when tracing the problem, this branch naming method is often exhausting!

So what kind of name would solve a problem like this? I used the following strategy!

The issue itself has a number, or ID, which makes it easy to name branches. Given that the number of an issue is 1, when we create a branch locally, we just need to name the branch Issue /1. According to this number, I can find out which issue this branch is dealing with, and open the Issue interface of Gitlab, I can know what requirement or defect this issue is related to. You can also visually see the code commit record associated with the issue. This not only brings convenience to developers, but also makes it easier for managers!

Okay, let’s do it in practice. Take developing new features as an example:

  • Local switch todevelopBranch, pull up to datedevelopBranch code
git checkout develop
git pull
Copy the code
  • Based on thedevelopBranch Creates a new feature branch that is used to develop new features and is currently namedissue/xxx, includingxxxAre you ingitlabCreated onissueNumber, as shown below:
git checkout -b issue/1
Copy the code

That is, the Issue /1 branch is used to solve the problem mentioned in Issue 1 on GitLab.

Some projects are simple or in the early stages, in which case the Develop branch will not be set, and the master branch will be used for rapid development. If this is the case, in the above operation, you can simply interpret master as develop and follow the same example.

Submit code

Feature/defect branches should be atomic, with one branch solving only one problem (referring to an issue), otherwise in principle they are not allowed to join other branches. This is key to agile iterations!

After development, it should be submitted to the remote repository branch of the same name.

git add .
git cz // Make the cz interactive named line submission
git push origin HEAD // Commit to the remote repository branch of the same name
Copy the code

Submit part of the code

If you want to commit some files (but not all modified files) at a commit, don’t use git add. instead, you can use it in conjunction with the GUI (such as the git panel in VSCode). Files that are staged are the ones you want to commit.

➕ is into staged, ➖ is out of staged, and staged Changes are what you hope to see in this commit.

When submitting part of the code, pay attention to take good care of their own unsubmitted code, not in the library will be lost, this point to be clear!

Git cz process

Git Cz is a capability provided by Commitizen, which I’ve written about briefly before. See the specification Commit Message for more details. The main purpose of using Git Cz is to standardize code commit.

  1. Select the type of submission, feat for requirement, Fix for bug fix, docs for document class change, style for code style (not style…) , refactor refers to code refactoring, perf is about optimization (including performance/experience, etc.), test is about unit tests, build is about build tools, CI is about continuous integration, chore is interpreted in various ways, and according to Commitizen, chore is about other non-SRC or test changes. Revert stands for code fallback…

  2. Please select the correct change type!

  1. scope

[Fill in according to the situation, if not too meticulous details, most of the time can not fill in]

What is the scope of this change (e.g. component or file name): (press enter to skip)
Copy the code
  1. Change the description

[Required] The description of this code change can be taken from the issue title, or the tapD requirement or defect title, or can be summarized by yourself.

Write a Short, Imperative Tense Description of the Change (Max 94 Chars): Login function developmentCopy the code
  1. A detailed description

[Fill in according to the situation, if not too detailed, most of the time can not fill in] provide detailed description

Provide a longer description of the change: (press enter to skip)
Copy the code
  1. Are there any major changes?

In general, only changes at the architecture level will enter y

Are there any breaking changes? (y/N)
Copy the code
  1. Does it affect the issue?

In general, a commit should have an issue associated with it. Enter y to close the issue. This is very common.

Does this change affect any open issues? (y/N)
Copy the code

If the associated issue is already closed, you can add a message to the commit.

If issues are closed, the commit requires a body. Please enter a longer description of the commit itself:
 (-)
Copy the code
  1. Close the issue?
? Add issue references (e.g. "fix #123", "re #123".) :Copy the code

Assuming you want to close issue#1, type:

fix #1
Copy the code

To close multiple issues, type:

fix #1 #2 #3
Copy the code
  1. Commit to the remote branch of the same name
Git push origin HEAD // Commit to remote repository branch with the same nameCopy the code

Commit to check

Implement commit checks with Husky and Git hooks.

  1. Prevent the submission of nonconforming code.
  2. To preventcommit messageNo specification.

The following dependencies are needed:

  • husky
  • commitlint
  • commitizen
  • conventional-changelog-cli
  • lint-staged

Initiate the Merge Request

Git push to a remote branch of the same name does not mean that your code goes to the main branch, and then you need to go through the code merge process.

The developer initiates a Merge Request in GitLab to Merge code into the Develop branch.

TL or a person with Merge permission is responsible for Code Review, and after approval, the Code can be incorporated.

Obtain the latest Develop branch locally

Once the code is in, you can develop other functions based on the Develop branch.

Git checkout develop git pull // Do other feature development or bug fixingCopy the code

Continue with unfinished requirements

If the submitted code is merged and it is found that this requirement has not been completed, you can not create another issue at this time, you should continue to modify based on the same issue; Use issue number 1 as an example.

First, it was needed to reopen issue#1 on the gitlab. Then branch locally.

git checkout develop
git pull
git branch -d issue/1
git checkout -b issue/1
Copy the code

Continue to develop…

In the middle of development, you want to pull other people’s code

If you are working on the Issue /1 branch and someone else has submitted code that has been merged into the Develop branch, you want to use this part of their code. You need to perform the following steps.

Git checkout develop // If this step is not possible, see the next section git pull Git checkout issue/1 Git merge DevelopCopy the code

When you try to switch out and plug in the latest code someone else has submitted, you find a git Checkout Develop error

This is because your issue branch code is behind or in conflict with the latest Develop branch.

If you still want to incorporate the latest code into your issue branch, you need to perform the following steps and use git Stash to create a temporary storage.

Git stash branch git checkout develop git pull git checkout issue/1 git merge git stash popCopy the code

In this case, a conflict may occur, with an exclamation mark or C (for conflict) in the VSCode Git area.

The conflict needs to be resolved before the development continues and the code is submitted as normal.

other

The above is an example of new feature development.

In fact, for fixing defects, the entire operation process is basically the same.

If it is a bug that exists in both the test environment and the production environment, it is usually fixed to verify the effect of the test environment, and then cherry-pick is used for emergency release in the production environment. In an emergency, repair the production environment as a priority.

Issue and Merge Request specifications

Issue specification

When you create an issue, it should be clear what the issue is used for.

  1. If it is clear that the issue deals with a requirement or defect on a TAPD, you must insert a TAPD link in the description so that you or your colleagues can refer to the trace. The selected Label should be a requirement or Bug.

  1. If it does not come from a TAPD, briefly state the subject in the title and (optional) specify the details in the description, and select the appropriate Label based on the actual situation.

The Merge Request specification

  1. When you submit a Merge Request, you should identify the target branch. For example, we created the Issue/XXX branch based on the Develop branch, so after submitting to the remote branch with the same name, we need to request to join the Develop branch.

  2. For bugs, first identify the environment in which the bug occurs. As for the bugs in the production environment, we created the issue/ XXX branch based on the master branch. After solving the problems, we requested to merge them into the master branch. The way to deal with bugs in the test environment is analogous; If a bug occurs in the development environment, test environment, and production environment, create a new branch based on the Develop branch. After the bug is processed, first launch MR to the Develop branch and then cherry-pick to the Release or Master branch.

Some people may think that it is not appropriate for the code related to bugs in production environment to be directly incorporated into the master branch. I think this can be analyzed according to the specific situation. If the team controls the risk more strictly, it can consider arranging a pre-release branch, corresponding to a pre-release environment, to simulate the production environment as much as possible.

  1. Assignee selects the auditor, typically a Mentor or other colleague (cross-review).

  1. Also attach Labels to indicate what type of problem you solved this time. If more than one class is involved at the same time, multiple choices are made. For example, if I solved both the bug and the requirement, I would check both boxes, but this is not recommended because we recommend that an issue only do one thing, so Merge requests also means that only one problem is solved.

  2. If release branches (such as release and Master) are involved, it is recommended to check the environment options (such as test environment, production environment) to give a clear impression.

The Merge Request fails. Procedure

With Code Review, there may be a variety of cases, such as improper business organization, non-compliance with specifications, unfinished functions, and so on.

If the Code Review is not valid, I will directly annotate the problem Code in the form of Comment. These Review opinions will be notified to the responsible person by email.

In case Code Review is not approved, it is not necessary to create another issue, but to directly cut to the branch corresponding to the issue and continue to modify the Code and push. Push to remote will be automatically reflected in MR. You can also see what Changes you have made in MR Changes.

The Merge Request can only be passed when all Review comments have been Resolved.

Release process

Since our team has adopted CI/CD, the release process is closely related to the code merging of related branches, and the project Owner is responsible for the release.

According to our current process, the release trigger action is to execute the Merge Request, then the corresponding Pipeline will automatically execute, according to the CI/CD environment configuration, deployed to the corresponding server.

Normally, a Merge direction is:

Develop -> release

Production release: Release -> master

Normal release

Normal is one production release per iteration. On the day of production environment release, the relevant responsible person should be present to support!

The test environment may be released a little more frequently, generally at least one release per day, to facilitate rapid regression testing.

Partial distribution

Sometimes, when a production environment is ready for release, it is suddenly discovered that there is a defect in a feature in the test environment that prevents the full release from being executed. But you can’t say I’m not going to send it, so send the rest of the available features.

Instead of releasing -> master, we can only select the code that can go online. This is where cherry-pick is used. We can find the record of the code that is available to Merge into the Develop branch, and then cherry-pick into the Master branch to achieve a partial online effect.

This is why I emphasized that an issue should only do one thing, and a commit should do as much as possible, so that we can carry out cherry-pick in special cases. If a lot of code is mixed together, it can be a pain to get a release online once some functionality is unavailable.

Release of successful judgment basis

At present, Pipeline email reminder has been configured. After successful release, there will be email reminder to all members of the project team!

Pay attention to the branch and environment mappings, and you’ll know which environment has a new release!

After considering docking enterprise wechat dialogue robot, it will be more intuitive.

TAPD management

The code commit process has been described above, and the other thing to do is the state flow of the TAPD.

Development priority

  1. First follow the product planning level priorities.

  2. On this basis, the front terminal requirements should be disassembled, and the priority of each sub-requirement should be adjusted according to the actual situation (such as the completion of the back-end interface).

  3. According to the three levels of high, middle and low, it should be ensured that after the sub-requirements are allocated to individuals, there are only 1-3 high-priority tasks on the individual workbench, that is, 1-3 requirements that may be developed in parallel, and the rest of the requirements should be included in the middle or low priority depending on the situation. After the development of high-priority sub-requirements is completed and transferred to test, the project Owner shall be notified, and then the Owner shall adjust the priority of the remaining tasks according to the actual situation to ensure the minimum size of the high-priority tasks, so that the developers can focus on the high-priority tasks.

The development of scheduling

  1. There is a rough schedule for the iteration level, but it is still not enough to be a development schedule.

  2. After the sub-requirements are disassembled, the handler should immediately assess the estimated development time to facilitate the scheduling of iterative requirements. According to the priority, estimated time and their own task scheduling, the development start and end time of each requirement should be arranged.

  3. If there is an unexpected situation without team cooperation, the requirement transfer should be completed before the development end time of each requirement, otherwise the cause should be traced back.

  4. When priority conflicts occur among multiple projects in parallel iterations, the project manager should organize and coordinate the scheduling and priorities according to the actual situation.

The development of

Before preparing development requirements, change the state of the related requirements on the TAPD to under development

The status of the associated defect on the TAPD should be changed to Accept/handle before the defect is resolved

Has been completed

After the completion of the development, the developer should fully self-test, if the transfer test does not pass, need to bear the corresponding responsibility.

When the automatic release of CI/CD is complete, the developer will receive an email notification, at which point status will flow in the TPAD:

  • The status of related requirements is changed to test
  • The status of the associated defect changed to Resolved

summary

Above is my own practice in the front-end research and development process, I hope to bring a little help to friends in need. Overall, having the process documented saved me a lot of time, and I didn’t have to answer some of the repeated questions. Of course, the above documents only describe the process of the main link in the development process, play a supporting role, there are many details also need to do more communication in daily.

I always believe that effective communication and feedback is the first task of a team. Only when this part is done well, can we make efforts to work together and produce results efficiently!

If you think this article is good, welcome to click a like, add a concern, sincerely thank you for your support. Also welcome to communicate with me directly, I am Tusi (public account: Front-end Sinan), looking forward to making progress with you!