Reflections on the Implementation of front-end Project Deployment Mechanism (1)

scenario

It is necessary to specify the scenario, because the average r&d team will be in two extremes: one is that the front and back ends are not separated and depend on the release of the back end; the other is that the front and back ends are completely separated and the front end is completely packaged and deployed independently. In our case, front-end access and core variables (single package main file including JS + CSS) control the back-end part, and the packaging process was originally local packaging + CDN upload + modify back-end project configuration, such a set of methods. The rest of the discussion is about why this approach should be changed, and how the front-end can be packaged efficiently and independently without changing the original release deployment pattern.

Why change it

Question of historical background

Historically, we still have the process of deploying back-end projects in different environments, and then there will be corresponding operations, such as modifying variables, merging code, deployment restart. The backend differentiates between different environments, generally for the purpose of differentiating between 1 code and 2 data. The code generally belongs to two stages: 1 verification of the correctness of the newly added code 2 verification of the correctness of the merged code + pollution-free 3 code correctness of the data on the regression line. Data: In general, online and pre-send a library, just different control access users; Stable environment is an integrated test environment where different functional branches are merged at last. If conditions permit, it will synchronize some data irregularly with the online data, while ensuring that the data is free from contamination. Development environment, is the main test of the correctness of the development function, there will be a variety of new or modified library table development, there may be dirty, bad data caused by the current function. So for data generally existing in the operation is 2 1 add some data to support the new function data, including delete some data, reduction of the types of values or data correction data corresponding fields, correct the correlation data, etc But the front projects in general, not on the back end at different stages for different environment or version of the processing, It is also rare for multiple front-end versions to coexist. At least in our scenario, the same front-end code can be used in different environments without major modifications after the function acceptance is completed. This is mainly because front end 1 does not have associated supporting support, such as database and code association in the back end, and front end 2 does not have complex logic in the back end. The front end is usually page interaction or data presentation, and there is no complex verification scenario.

Deployment of multiple front-end applications in the same iteration

Core problem: a key deployment, the isolation deployment, deployment impact One-click deployment: one-time deployment of multiple front-end application, without iterative deployment, respectively Isolation deployment: a front-end deployment, will not affect the normal access to other applications, at present due to the historical background, of course, if managed in the same backend project, at present cannot avoid completely. At the same time, consider that some applications may only be launched for testing purposes, and allow some applications to go live and some not. Associated deployment: To reduce deployment times and improve deployment efficiency, properly design dependency relationships for applications that require release sequence (dependency requirements).