The current end infrastructure task falls to you, how can you promote collaboration?

The current end infrastructure task falls to you, how can you promote collaboration?


As a wild front-end developer, he hasn't learned any systematically since he started his career, and the teams that have been there are not sure about the size of the team:

  • Either the big cow leads the team, but the back end is big cow.
  • Either the improvised team is constrained by the past and the front end is not free.
  • Either from 0 to project deployment, they are all for agile and agile, rather irregular.

Having said that, after four years of devastation, I have my own experience.

1. Looking DevOpsat the front-end infrastructure from the process

Many new front-ends who focus on cutting pictures see this picture as a circle:

DevOpsWhat is it? What are these tools? where am I?

Many front-ends are confused when they come into contact with front-end engineering and continuous construction/integration of related knowledge. Some feel that this has nothing to do with business development and don't care about it.

But in the long run, it is impossible to cut pictures for a lifetime. No matter how powerful your business is, how good the front-end code is, without the help of back-end operation and maintenance testers, a complete software production cycle cannot be completed. .

And to become a full stack is difficult, let alone a full link developers.

Closer to home, when you enter a new team, the front end starts from 0. How DevOpsto improve team effectiveness from a perspective?

A set of simpleDevOps process includes collaboration, construction, testing, deployment, and operation.

The development specifications, code management, testing, construction and deployment, and engineering that the front-end often talks about are actually in this entire system.

Of course, if small and medium-sized teams want to play the DevOpsentire process well, the time and R&D costs required are no less than the development project.

DevOpsThe core idea is: "Deliver value quickly and respond flexibly to changes" . The basic principles are as follows:

  • Efficient collaboration and communication;
  • Automated processes and tools;
  • Fast and agile development;
  • Continuous delivery and deployment;
  • Continue to learn and innovate.

Next, I will cooperate, build, test, deployment, operation line five aspects to talk about, how to quickly build a front-end infrastructure for small teams.

2. Promote collaboration inside/outside the team

There are too many things that can be written in front-end infrastructure collaboration. For the time being, it can be roughly divided into: inside the team and outside the team.

The following may be problems that all front-ends can encounter:

  • Members are of different levels and coding styles are different, making it difficult to manage projects in a unified manner.
  • Different itemsWebpack configuration of is too different, and the basic tool function library and request package are different.
  • The project structure and the technology stack jump up and down, obviously the same UI style, the basic components can not be reused, all rely on copy and paste.
  • The code is not commented, the project is not documented, it is difficult for newcomers to take over, and the old project cannot be maintained.

1. Three-tier code specification constraints

  • The first layer ESLint:

Common ESLintstyles airbnb,google,standardare: .

Among multiple projects, the rules should not jump left and right. If the project cycle is tight, the rules can be relaxed appropriately so warningthat the weak warning can be passed. And it is generally recommended that the membership IDEand the plug-in should be unified to minimize the impact of objective factors.

  • A second Git Hookslayer .

gitItself contains many hooks, in commit, pushetc.git trigger the execution before and after the event.

And huskycapable of preventing irregular code commit, push, mergeand the like.

The code submission is not standardized, and the whole team deploys two lines of tears.

npm install husky pre-commit --save-dev

Take my previous project as an example:

  "scripts": {
    "lint": "node_modules/.bin/eslint'**/*.{js,jsx}' && node_modules/.bin/stylelint'**/*.{css,scss}'",
    "lint:fix": "node_modules/.bin/eslint'**/*.{js,jsx}' --fix && node_modules/.bin/stylelint'**/*.{css,scss}' --fix "
  "husky": {
    "hooks": {
      "pre-commit": "npm run lint",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"

Through a simple installation and configuration, whether you pass the command line or Sourcetreesubmit the code, you need to pass strict verification.

It is recommended to README.mdindicate the submission specification in the root directory :

## Git Specification

Use [commitlint]( tool, commonly used in the following types:

-feat: new feature
-fix: fix bugs
-chore: changes to build or auxiliary tools
-refactor: code changes that neither fix bugs nor add new features
-style: does not affect the changes in the meaning of the code (such as spaces, formatting, missing semicolons)
-docs: only changes to the documentation
-perf: Code changes to improve performance
-revert: Withdraw the submission
-test: add or modify test

For example
git commit -m'feat: add list'
  • The third layer, CI(continuous integration).

"Best Practices of Front-end Code Specification"

The first two steps of verification can be skipped manually (for scolding), but CIthe verification in is absolutely impossible, because it is verified on the server side. Use gitlab CIto do continuous integration, configuration files .gitlab-ci.yamlas follows:


This level of verification is generally done by the configuration group of the operation and maintenance department in larger enterprises.

2. Unify front-end materials

How to standardize public components, public UI, tool function libraries, third-party SDKs, etc.?

How to quickly encapsulate the departmental UI component library?

First of all, we have to thank the maintainers of major UI component libraries for saving us a lot of development costs.

Thinking back to the Jquerytimes, the days when looking for plug-ins everywhere...

But each new team has its own UI style orientation. If you cite one ElementUI, there will definitely be business inconsistencies and different perceptions. If you force magic changes in each project and pollute the style everywhere, it will be more heart-warming. Tired.

Although every major component library provides a way to initialize variables, there is no way for business-oriented components.

One of the solutions is an open source library that is very popular abroad StoryBook::

StorybookIt is an open source tool for independent development React、Vueand Angularthe UIcomponents. It can construct UI components organized and efficiently.

StorybookA sandbox is provided for building UI components in isolation.

Similar to the official documentation of the component library, but more powerful. You can quickly view the usage of the component through the control and adjustment of the access parameters, and the test can also verify the integrity of the component's function.

The general recommended steps are:

  1. Separate business from common components.
  2. Install in the project StoryBook(additional for multi-project)
  3. According to the official document standards, create storiesand set the parameters (at the same time it is recommended to write the Jesttest script first ), and write the necessary comments.
  4. Configure StoryBookcontrols for different components , and finally deploy.

How to unify the tool function library used by the department and the third partysdk

In fact, there are more communication issues here. First of all, we need to make clear a few points:

  • The department must communicate in advance with the customary tool library, and it is not possible to install one on this end and install MomentJsit on the other end DayJS. The general principle is: write lightly by yourself, and find alternatives that exceed the acceptable size, such as: DayJSsubstitution MomentJs, ImmerJSsubstitution, immutableJSetc.
  • There are login mechanisms between departments, request library encapsulation protocols, etc. If it is SSO/scan code login, etc., only one set of agreement is used, and the backend is not allowed to change at will. If it is a request library package, the back-end must have a unified Restfulstyle. Believe me, Restfula team that does not have a standard is a disaster. The front-end continuous tuning will be better than death.
  • MockWays, routing management, and style writing should also be unified.

3. Promote collaboration outside the team

The core principle is: "If you can solve it with documents, try not to BB."

Although the status of the front-end is becoming more and more important today, we often encounter the following problems in project development:

  • Different back-end interface specifications are different, and the front-end needs to spend a lot of time to do data cleaning and compatibility.
  • The front-end static page has been developed, and the back-end has been slow to provide an interface, because there is no interface document, you have to ask every day.
  • The feedback from the test was not reflected in the prototype.

The first is the prototype aspect:

  1. Be sure to read and understand the prototype documentation provided by the product! ! ! Ask and communicate more, this is too important.
  2. Good products generally provide detailed project flow diagrams, but the front-end still needs to make a page flow chart based on actual conditions.
  3. The product must provide definitions related to specific field types, otherwise it will have to wrestle with the backend. . .

Followed by the back end:

  1. Implement the Restfulinterface specification, and reject the interface that does not conform to the specification.
    • The persuasion teacher has experienced it. The former owner has an JAVAarchitect who Restfuldoesn't even know about cross-domain and the set specifications are not standardized. A simple query interface returns five or six levels, and its good name is "structured data".
    • When encountering such a backend who is immersed in his own world and does not listen to persuasion, I have only one persuasion: either get him away or run away.
  2. The necessary interfaces and API documentation site testing (eg Swagger, Apidoc), does not accept the file transfer in the form of interface.
    • The early joint debugging was to inform the other party of the interface standard through shouting. Just ask if there is anything unclear at the beginning, but later, even the person who wrote the interface code forgot how to use the interface, and the maintenance cost was huge.
    • In the absence of interface documentation site appears an interface document to worddocument appears, supplemented by postman, http, curland other tools to test. But it is still not intuitive enough and difficult to maintain.
    • It mainly Swaggersolves the problems of testing, maintenance and real-time performance based on web interaction . To a certain extent, the wrangling problem is also avoided: only if your back-end does not update the document, this joint debugging lag time should not be borne by the front-end.

Then there is the testing aspect:

  1. In order to avoid some invalid bugs raised by the test, it is best to participate in the test case review in advance.
  2. In actual development, if there are unreasonable functions that need to be modified, all modifications must require the product manager to update to the PRD and prototype design. Otherwise, if the test does not know, it will be considered a bug.
  3. Through self-testing and writing Jestunit tests, accidentally bugreduce the code to a reasonable level.
  4. Tucao the back-end interface specification together with the test (funny).

Finally, the operation and maintenance aspects:

  1. In addition to CI/CDrelated, it is actually possible to write nginxand plug-in development together with operation and maintenance .

3. Effective communication tools

Maybe everyone is more accustomed to using QQor WeChat to transfer files. Daily communication is okay, but it is not very friendly to developers.

How to communicate across regions is generally a combination of suggestions jira+ slack, but these two tools are a bit unacceptable.


project management

Enterprise WeChat




There is no big problem in choosing these four tools at will.

the end

Doing things like front-end infrastructure is much more tiring than writing code. .

Reference: The current end infrastructure task falls on you, how to promote collaboration? -Cloud + Community-Tencent Cloud