Some and summary of the process of building a private deployment system
scenario
Let’s take a look at a scenario. A small and medium-sized company with “small scale” or “limited energy” has access to the efficiency tools of the third party company, such as IM tool (enterprise wechat), document collaboration system (Language Sparrow), questionnaire system (Questionnaire Star), performance system, etc. The mainstream access method of the three parties is SASS, which sells its own products through user classification (ordinary users, member users and enterprise users), which is easy for the three parties to maintain in a unified manner.
However, the examples I cited here are often related to sensitive information within the company, such as conversations between senior employees, core strategy documents, eNps research data, performance information, etc. If this data is stored on servers maintained by the three companies, there will be some security issues; In addition, the way of “user classification” is like package, which is difficult to meet the customized needs of various users. Therefore, more and more third-party companies support private deployment, deploying their own services on servers designated by customers, such as internal computer rooms, public clouds and private clouds (Ali Cloud and Huawei Cloud). At present, one of our external services is also facing such problems. When customers are not satisfied with our “user tier” package and are very sensitive to “data storage”, how can we quickly customize and privatize the deployment service?
The existing problems in
Can’t you just package your existing system and deploy it on a server that the customer has specified? It’s not that simple, and there are three key problems:
First, rely on the internal environment
Many capabilities of the systems that have been maintained internally for many years are strongly dependent on the infrastructure provided internally, such as CDN, database, cache service, dynamic configuration, user system, etc. These infrastructures may be inconsistent or even nonexistent on a user-specified server.
Second, lack of customization ability
When users’ ability to customize the system is opened, the existing system only supports the way of “user classification”, which is difficult to support the “unpredictable” customization needs of users. How to respond to the customization needs of users quickly needs a new set of “module organization”.
Three, parallel maintenance costs
If we support private deployment of users, we have to face a problem that when N companies are connected, we will maintain N systems at the same time, which involves a series of specifications that synchronize bugs and features between multiple systems, and multiple versions of the r&d process of “development, debugging, build and deploy” in parallel.
The solution
So how do you build a privatized deployment system for rapid customization? Still start from the above three questions:
Get rid of your internal environment
Configuration change
In order to get rid of the dependence on the internal environment, we need to configure the existing system to support the configuration of the involved infrastructure, which can be written manually in configuration files, generated at build time, and dynamically modified at run time. Finally, N deployment packages for N companies can be produced based on N configurations.
2. Customized ability to meet requirements
modular
Remove the function module and set the parameters in Switch and Configuration. How are modules broken down and maintained? Splitting can be considered from the “vertical” Angle, such as “putting functions”, “personal center”, etc. Or from a “horizontal” perspective, such as “login”, “permissions”, etc.
Third, reduce the cost of parallel maintenance
System integration
Merging existing systems and maintaining a “base release” of a baseline release serves two purposes:
- When a new enterprise needs access, you can use this “Basic version” for rapid customization development
- As the upstream code branch (master) of all parallel systems, the downstream code branch (each enterprise branch) periodically picks bugfix & feature from this branch
The process modification
Our service is special (see page-builder services), with a B-side for configuration and a C-side page generated by b-side. In this way, we have four projects, and each function development may involve the development, debugging, joint commissioning, construction and release of four projects, while the static resource version and service address of THE C-side are determined by themselves. Both of these undoubtedly add to the mental burden of developers.
First, put the front and back ends of the BC into a project for maintenance. Each release requires only two releases at most. At the same time, since the B end serves as the configuration side, not only the function of the page itself of the C end needs to be decided by the B end, but the configuration such as static resource version and service address can also be obtained and set by the B end.
Then, the application initialization, development, debugging, joint tuning, construction, release of the specification, specification is a convention, in order to better implement the specification, it is necessary to implement a set of command line tools or page flow as the carrier of the specification. Further, application concepts can be abstracted so that all processes revolve around such applications. Both ends of BC can be such applications, and the modules that are split can also be such applications. At this point, all our processes are centered around this application concept, that is, both ends of BC and the dozens or even hundreds of modules that are split share a set of initialization, development, debugging, debugging, construction, and release processes.
Configuration change
In addition, configuration also helps reduce the cost of parallel maintenance by maintaining the configuration rather than the various types of code logic. Avoid logic such as “If company A executes logic B” and focus on functions. For example, company A enables logic B in the configuration.
In addition to reducing costs, configuration is also used for future planning, since all current enterprise “customization needs” are manually assembled BC applications. In the future, when more and more enterprises are connected to us and a large number of “module” applications are deposited, we can explore how to get rid of manual assembly, that is, by building blocks through online pages. With the help of configuration, our design can well meet this demand.
conclusion
The process transformation in Step 3 involves a large number of front-end engineering related capabilities and needs to be further developed