Front-end Engineering-deployment

Front-end Engineering-deployment

Use scaffolding to create initial projects and build development servers locally for project development. Once the encoding is complete, all of the work done at this stage is part of the development process, after building the code that is available to build the target environment. The next step is to deploy the code into the specified environment to facilitate further joint testing.

When you deploy a project for a personal project or a small team, you may be using tools such as the FTP upload tool to upload files to a designated server, and then hand it over to the OPS staff for launch. This is a quick and easy way to publish, and is suitable for individual projects or small-scale teams. But for a large number of users of products and a variety of development systems of technical teams, project deployment must consider the collaboration, speed, security and other factors, a complete set of processes to achieve project deployment.

Take a look at three scenarios and consider what the front-end deployment needs to be aware of from a real-world scenario.

1, the developer uses the FTP tool to upload the code to the server. During the testing phase, the tester made a bug for the development classmate, the developer will need to open the FTP tool, navigate to the specified directory and upload the code after the completion of the repair. This process needs to be repeated for each bug fix.

2, multi-person collaboration projects, if a classmate after fixing a bug did not submit code to the Code warehouse, other development in the old code based on the changes, after deployment found a fixed bug appeared.

3, the development of classmate mistakes to deploy code to other applications in the directory, resulting in other application functionality failure.

The above three scenarios correspond to the 3 factors that need to be considered in the deployment process: speed, collaboration, and security. Teams of different structures and sizes have different priorities, small teams focus on speed, and large teams focus on collaboration and security.

Deployment Tools

For the speed problem in scenario 1, we need an automated deployment tool that must be configurable and simple to operate.

• Configurable: The target server, path information for the deployment corresponds to project one by one, which can be deployed by the OPS staff.
• Operational simplification: Deployment operations should be automated, and developers deploy projects through command lines or visual pages. The platform should be highly automated, and developers only need to apply for a test environment and then click on the deployment project to test it. The server resource allocation, project build, and project resource deployment behind the scenes need no attention from the developer.

Deployment process

For the writing problem in scenario 2, we need a complete deployment process. There are two issues in Scenario 2: communication is not timely causing code to be out of sync, and control is not strictly causing the deployment content to be overwritten incorrectly.

First we need to improve the branch management mechanism, multi-human development projects using version control system git, local projects can not be directly deployed to the server, server deployment is to pull the branch code from the Git repository, to deploy on the server must push the code into the Git repository.

Developers can apply for multiple daily environments to deploy their own project branches, but ensure that there can be only one or two branches in the pre-deployment environment for each project. The publication must be published as a queue, and there can be only one project branch in the publication queue, ensuring that the project content is not overwritten by errors and is the latest code. In Git, for example, a multi-person collaboration project is created from the master branch to develop the feature, in the daily environment can deploy its own feature branch, but in the pre-deployment, you must merge master code, or pre-compile error, the publication must be released from the pre-send queue.

Simply put, the deployment queue is the order in which all deployment requests are queued, which must be published sequentially, and the process is stuck before each release. You must ensure that the pre-function verification pass, code security scan passed, and review pass, otherwise the project release will not be allowed.

Permission System

For security issues in scenario 3, we need to establish a permission system. Developers only retain the permissions of the requested deployment, the server to which the project is deployed, the specific path, and the deployed environment are transparent to the developer, so the developer only needs to focus on the business. The process of deploying a project to the target server and destination address should be done using code or scripting Automation to reduce the number of errors caused by human factors.

Front-end Static resource deployment

When designing the deployment process, it is important to consider that the biggest difference between the front-end and other areas is that the front-end resources are static resources, the most special of which is the HTML file.

An HTML file is the only portal for a Web site, and all other resources must be referenced directly or by an introduction to the HTML file to be clipped. The particularity of HTML determines that it can only use the negotiation cache, other resources (Js, CSS, etc.) should use strong cache. This caching policy ensures that every time the user accesses the Web site to obtain the latest HTML resources, other static resources updates can be directly reflected in the HTML, as long as the HTML is updated in a timely manner to ensure that the entire site resources update. You can set different cache policies for different static resources in the server.

HTML and other static resources should be deployed under different domain names, with two benefits:

• If deployed under the unified domain name, requests the static resources (Js, CSS) also carries the cookie, wastes the resources, deploys these static resources under another domain name, solves this problem.
• Js, CSS and other files can be deployed in the CDN, optimize the site performance.

Summarize

These are some of the basic issues that need to be considered in front-end engineering deployment, and there are a lot of details to consider, such as code rollback, deployment queue prioritization, and black-and-white list policies in the permissions system, but there are three factors to consider for speed, collaboration, and security when designing a deployment scenario. Then design the specific plan that best suits your team.

Resources

• How do you develop and deploy front-end code in large companies?

The article starts with my github: the front-end knowledge system

Front-end Engineering-deployment