Front-end infrastructure to promote collaboration

preface

As a wild front-end developer, I haven’t had any systematic learning since I started my career, and the teams I have worked with are also different in size:

• Either Daniel leads the team, but Daniel is the back end.
• Or AD hoc teams, constrained by the past, the front end is not free.
• Either from zero to project deployment, it’s agile for agile’s sake, rather non-standard.

Be that as it may, after 4 years of career destruction of the waste ape I, but also have their own experience.

1. Front end infrastructure from DevOps process

Many of those who focus on the cutest new front end of the graph see that this image is circled:

DevOpsWhat is? What are these tools? Where I am?

Many front ends get cold feet when it comes to front-end engineering and continuous building/integration. Others think it has nothing to do with business development and should be ignored.

But in the long run, you can’t live your whole life. No matter how good your business is, no matter how good your front-end code is, a full software production cycle can’t be completed without the help of the back-end o&M test masters.

It’s hard to be a full stack, let alone a full link developer.

Anyway, when you’re on a new team and the front end starts from zero, how do you improve team effectiveness from a DevOps perspective?

A simple DevOps process involves collaborating, building, testing, deploying, and running.

The front-end development specifications, code management, testing, build deployment and engineering are all in this system.

Of course, small and medium-sized teams want to play wellDevOpsThe whole process requires no less time and cost than a development project.

At its core, DevOps is about delivering value quickly and responding flexibly to change. Its basic principles are as follows:

• Effective collaboration and communication;

• Automated processes and tools;

• Fast and agile development;

• Continuous delivery and deployment;

• Keep learning and innovating.

I’m going to talk about how to quickly build front-end infrastructure for small and medium-sized teams from five aspects: collaboration, build, test, deploy, and run.

2. Promote collaboration within and outside the team

There is so much that can be written about front-end infrastructure collaboration that it can be roughly divided into: in-team and off-team.

Here are some of the most common front-end problems:

• Members have different levels and different styles of writing codes, which makes it difficult to manage projects uniformly.
• The ‘Webpack’ configuration varies greatly from project to project, with different base tool libraries and request wrappers.
• The project structure and technology stack jump up and down, obviously the same UI style, the basic components can not be reused, all rely on copy and paste.
• Code is uncommented, projects are undocumented, new people can’t take over, old projects can’t be maintained.

1. Three-tier code specification constraints

• Layer 1, ‘ESLint’ :

Common ESLint styles include: Airbnb, Google, and Standard.

Rules should not jump left and right across multiple projects. If the project cycle is tight, you can relax the rules to allow weak warnings of the Warning class to pass. And it is generally recommended that IDE and plug-in members should be unified to minimize the impact of objective factors.

• ‘Git Hooks’.

Git contains many hooks that trigger execution before and after commit, push, and other Git events.

Husky prevents non-standard code from being committed, pushed, merged, and so on.

Code submission is not standard, the entire group deployed two lines of tears.

npm install husky pre-commit  --save-dev
Copy the code

Take my previous projects as an example:

// package.json
  "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"
    }
  },
Copy the code

With simple setup and configuration, you need to pass strict verification whether you submit code from the command line or Sourcetree

It is recommended to note the submission specification in the root directory readme.md:

# # Git specification use [commitlint] (https://github.com/conventional-changelog/commitlint) tools, commonly used has the following several types: - feat: new features - fix: -refactor: code changes that neither fix bugs nor add new features -style: changes that do not affect the meaning of the code (e.g. Spaces, formatting, missing semicolons) -docs: Git commit -m 'feat: add list'Copy the code

• The third layer, ‘CI’ (continuous integration).

Front-end Code Specification Best Practices

The first two steps of validation can be skipped manually, but validation in CI is never circumvented because it is validated on the server. Using Gitlab CI for continuous integration, the configuration file.gitlab-ci.yaml is as follows:

lint:
  stage:lint
  only:
    -/^feature\/.*$/
  script:
    -npmlint
Copy the code

In a larger enterprise, the configuration group in the OPERATION and Maintenance department performs this verification.

2. Unify front-end materials

How to standardize common components, common UI, tool libraries, third party SDKS, etc.?

How to quickly encapsulate the department UI component library?

First of all, thanks to the maintainers of the UI component libraries, we have saved a lot of development costs.

Looking back to the era of Jquery, looking around for plugins….

However, every new team has its own UI style orientation, and if you introduce ElementUI in a single way, the business is bound to be different and look different, and if you force changes on every project and pollute styles everywhere, you will be very tired.

While major component libraries provide a way to initialize variables, business-oriented components do not.

One solution is a popular open source library called StoryBook:

StorybookIs an open source tool for independent developmentThe React, VueandAngulartheUIComponents. It builds UI components in an organized and efficient way.

Storybook provides a sandbox for building UI components in isolation.

The official documentation is similar to the component library, but much more powerful. You can quickly view the usage of components through control and adjustment of input and output parameters. Testing can also verify the integrity of components.

The general recommended steps are:

1. Decouple business from common components.
2. Install ‘StoryBook’ in a project (separate for multiple projects)
3. Create ‘Stories’ according to official documentation standards and set parameters (it is also recommended to write the’ Jest ‘test script first) and write necessary comments.
4. Configure the StoryBook control for the different components and deploy it.

How to unify the tool function library used by the department with the third party SDK

In fact, this is more about communication. First of all, we need to make clear the following points:

• There should be prior communication within the department about the established tool base. We can’t have ‘MomentJs’ on one end and’ DayJS ‘on the other. The general principle is: lightweight their own writing, more than acceptable size to find a substitute, such as: ‘DayJS’ substitute ‘MomentJs’,’ ImmerJS ‘substitute’ immutableJS ‘and so on.
• There are login mechanism between departments, request library encapsulation protocol and so on. If SSO/scan login is used, only one protocol is used and the backend is not allowed to change arbitrarily. If it’s request library encapsulation, it has to have a consistent Restful style on the back end, and trust me, teams that don’t use Restful specifications are a disaster. It’s a hell of a front end.
• Mock, route management, and style writing should also be unified.

3. Promote collaboration outside the team

The core principle: “If you can document it, don’t document it.”

Despite the growing importance of the front end, we often encounter the following problems in project development:

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

First, the prototype:

1. Be sure to read the prototype documentation for the product!! Ask and communicate. It’s so important.
2. A good product will generally provide a detailed map of the project process, but the front end still needs to be based on the reality, do a page flow chart.
3. The product needs to provide definitions for specific field types, or it has to fight with the back end.

The second is the back end:

1. Restful interface specifications are executed. Interfaces that do not conform to the specifications are rejected.

• The former employer had a ‘JAVA’ architect who did not even know how to cross-domain and ‘Restful’. The specification was not standardized. A simple query interface returned five or six levels, which is called “structured data”.
• I have only one piece of advice for a backend who is too absorbed in his own world to listen to advice: get rid of him or run away.

3. Necessary interface documentation sites with API tests (e.g. ‘Swagger’, ‘Apidoc’), do not accept the interface in the form of file transfer.

• The early syndication was to inform each other of the standard of interface through Shouting. At the beginning, if you don’t know what to ask directly, but later, even the person who wrote the interface code forgot how to use the interface, the maintenance cost is very high.
• Before there was no interface documentation site, interface documentation appeared as’ word ‘document, supplemented by’ postman ‘, ‘HTTP’, ‘curl’ and other tools to test. But it’s still not intuitive and difficult to maintain.
• Web interactive ‘Swagger’ solves testing, maintenance and real-time problems. To some extent, it also avoids the problem of wrangle: if you don’t update the document at the back end, the latency should not be the front end’s responsibility.

Then there’s testing:

1. It is best to participate in the use-case review of your tests in advance in order to avoid testing that raises invalid bugs.
2. In actual development, if unreasonable features need to be modified, all changes must be updated by the product manager into the PRD and prototype design. Otherwise, the test will consider it a bug if it doesn’t know it.
3. Reduce code accidental bugs to a reasonable level by self-testing and writing ‘Jest’ unit tests.
4. Make fun of the backend interface specification with the test (funny).

Finally, operation and maintenance:

1. In addition to ‘CI/CD’ related, it is quite possible to write ‘nginx’ and plug-in development with operations.