classification
The deployment of front-end projects can be divided into first deployment, regular deployment and optimized deployment according to the characteristics of the work.
First deployment
The first deployment refers to the process in which the production environment is just an operating system with public network services. On this basis, through deployment, the content can be accessed by entering the URL in the browser.
The feature of the first deployment is to start from scratch, so it involves a wide range of areas. The process often requires the collaborative work of system architects, system operation and maintenance engineers, and system R&D engineers. Judging from the characteristics of the front-end project, the core question is: What kind of service does the HTTP server provide for the project package that needs to be deployed? This determines the functions and related configurations of the HTTP server installed and deployed. This issue will be mentioned later.
Regular deployment
Regular deployment refers to the process of updating new features to a specific server after each development iteration.
The essence of conventional deployment is to "copy" the deployment package and "paste" it on the server. The process is simple to operate, but it is inefficient to repeat a large number of simple tasks with the same content. Therefore, there are many automated tools for conventional deployment. With the right tools, simple routine deployment can be changed from simple to simpler.
Optimize deployment
Optimizing deployment refers to the process in which system architects and R&D engineers conduct research and tests to improve the performance of the service, and then provide a set of solutions and make adjustments based on the solutions.
The characteristic of optimized deployment is strong purpose. Every explicit optimized deployment (if the optimized content has been fully realized in the developed code, this time is just a regular deployment for deployment, and can also be understood as implicitly optimized deployment) always has its purpose, Either to solve the problem, or to improve the performance of a certain aspect, it can always be measured. After optimization deployment, the effect should be tracked. If it fails to meet the expectations, the optimization must be followed up. If it is confirmed that there is no effect, the settings must be rolled back to facilitate adjustment again.
Physical URL and routing
In the daily conversations of developers, the words URL, routing, and API can be mixed. At this time, they only represent a specific string in the context. After the specific string is obtained, the data can be obtained by calling or When you see the page, you can start the next step. However, during deployment, URLs and routes should have their own strict meanings and boundaries.
URL
URL is a uniform resource locator, used to describe the location of a specific resource on the Internet.
Physical URL
Seeing the explanation of the URL, you can know that the URL can locate a specific resource, but it does not indicate whether the specific resource corresponds to a real physical file. This is due to the fact that Internet resources were static in the period when the URL concept emerged. Naturally, no special explanation is needed. With the development of the Internet, dynamic resources appear, and the meaning of URLs has been enlarged. Only in this article, the URL corresponding to the actual physical file is called the physical URL.
routing
As mentioned above, the meaning of URL has been enlarged, and URL can locate dynamic resources. This is actually the ability of routing in Web services. Specifically, it is a URL that finds the corresponding Web service through its host address, and then the Web service treats the following URL part as a string, looking for and providing a service that matches the string.
Going back to the core problem of the first deployment, it is clear whether the project is accessed by physical URL or routing, and it is clear whether the HTTP service provides static resource service or proxy service (processed by the Web server at the back end of the HTTP server).
Separate project before and after VS bundle project before and after
Now that it is becoming more and more popular to separate front-end and back-end projects, simply look at the advantages and disadvantages of the two and their impact on deployment.
Benefits of separation
- Independent projects, you can use more suitable tools to improve R&D efficiency
- Decoupling is conducive to teamwork
Disadvantages of separation
- Increased difficulty in using server-side rendering
The benefits of bundling
- Use server-side rendering to load faster and more convenient seo
- Conducive to overall thinking
Disadvantages of bundling
- The requirements for R&D personnel are high, and they must know everything
- low efficiency
influences
The problem of how to deploy the front-end project is the problem of how to deploy the front-end project before and after the separated project. On the contrary, the front-and-back bundled project is undoubtedly used by the HTTP server to provide the service through the proxy through the Web server. Therefore, the front-end deployment can be completed by deploying the corresponding back-end project. .
The directory of the deployment package
What does the deployment package look like? Is there a unified naming convention and hierarchical structure for the directory structure inside? First of all, think about the directory design of the development source package. Why does the source package look like that in the end? Obviously, in order to facilitate the storage of codes in blocks, the developers need to refer to each other. They are often related by relative paths. The path using the local file system is essentially the same as using the physical URL. Isn't the physical URL just some specific path in the server file system? Therefore, if the process of generating the code package does not modify the relative path code in the source code, the directory structure of the deployment package is equivalent to the source package. As more and more codes modify the relative path, the directory structure of the deployment package and the source package The bigger the gap (use webpack packaging, all resources will be placed in the same level directory by default).
Deployment tool
Thinking about the deployment package directory, the real meaning is to choose which tool to "copy and paste" during regular deployment. Tools are roughly divided into two categories, one is version control tools such as git, and the other is file system tools such as FTP and rsync. The advantage of the version control tool is automation, which can control the forward and rollback of the version. The advantage of the file system tool is to refine the file increment, and the process of copying files is completely controlled by yourself. If the file structure of the deployment package is more complex, the efficiency of manually copying and pasting files is extremely low. If incremental deployment cannot be used due to the complexity of the directory, then the significance of using file system tools is less, and the benefits of using version control tools are more obvious . Therefore, you can use version control tools to manage deployment packages. You only need to pull the data of the new version from the deployed directory to complete the replacement work, and it also has the version management capabilities.
Principles for deployment
Principle of independence
Any deployment should be independent. Even if there are multiple deployment tasks, you cannot start the next one after half of the task. Especially when doing overall construction or automation design, the independence of a single deployment should be maintained.
High efficiency principle
Any deployment should be developed in the direction of efficient deployment, the deployment process should be simplified, and automated means should be used as much as possible.
Principle of correctness
Any deployment means that there are new changes, and the new changes should be correct and should not affect the old functions (corresponding test work should be kept up in time)