For
application research and development, if there is a platform that can provide two major functions of project collaboration and continuous delivery, and form a complete closed loop from demand to feedback, and ultimately provide a one-stop pipelined platform, how wonderful Things.
However, after all, dreams are dreams, and reality is reality. If platform providers are dreaming of dreams every day, who will solve the current pain points?
01 Why is the assembly line landing so difficult?
Well, let’s take a look at the beautiful blueprint we originally envisioned: use automation to put standardization on the ground.
This picture shows a common
new application development process. We first registered the relevant information in the version management system, and then pulled the master out of the development branch from the "pipeline system" for development, and submitted the relevant through the "configuration system" Apply configuration information, and then use automated testing to complete the test in the "test system", and finally merge into the release branch, submit to the "deploy system" to complete the release.
In order to standardize operations, improve collaboration efficiency, and avoid mistakes, we need a platform pipeline to carry all of this.
The above seemingly faultless story encountered some difficulties in the landing process, mainly manifested as the starting point of "platform user" is inconsistent with "platform provider":
1. Profit cycle: Limited resources must be given priority to ensure business realization, there are excess resources to meet technological improvements, every investment should have immediate benefits, if continuous investment can not see the effect, then I do not;
2. Efficiency is priority: it can be done with a bunch of tools, no interface, no flow or flow is not important, can not tolerate constructive waiting, can be used.
3. Resource cost: How can I use this platform to automate my humanization? If you use your platform, I need to pay extra costs, then I prefer to come by myself.
4. Dependency path: As testing and operation and maintenance enter FeatureTeam, platformization gradually loses the original source of demand, and FeatureTeam is more willing to solve the pain points immediately without relying on other teams.
For most financial companies, "efficiency first, result-oriented" is the basic principle. When we encounter so many difficulties, we start to think, what can we do before promoting the one-stop platform of the assembly line?
02 Improve efficiency with tools, and then talk about the assembly line
In fact, if you can solve things with a bunch of tools, you have to build a platform, and a whole bunch of interfaces can only achieve things, which has inherent disadvantages in the landing process.
Well, we temporarily forget that beautiful blueprint, through the pilot of a certain system, through a tool-based approach, first through continuous integration, let users quickly get revenue.
The pain points and needs of a system (continuous integration)
1. Each link of the test activity runs independently, it is impossible to make full use of the idle time at night, and it is not convenient to provide rapid feedback
services for R&D.
2. Due to the strong system dependence, the test environment needs to be deployed with multiple systems, but the deployment takes a long time, the deployment environment is prone to omissions, and it is difficult to create data.
3. The interface test needs to manually replace the dubbo package on the environment to increase the test environment preparation time. The online package is not equal to the test package.
The first stage: the tooling solution of a system (continuous integration):
Assemble CI scene directly with Jenkins
Use Jenkins scripts to implement data initialization, construction, deployment, and call automated test scripts (Python)
In the core interface, manually write two sets of APP, one for Mock and one for formal;
Configuration updates continue to stay in the manual stage;
The second stage: a system's pipeline solution (continuous integration):
Provide
CI pipeline and support Mock function:
1. Through Jenkins script, data initialization;
2. Deployment system (self-research): construction, deployment;
3. Automated testing and process (self-research): CI pipeline, mock test;
4. Service governance function (self-developed): Based on Dubbo, it supports dynamic routing function to satisfy Mock scene service;
5. Resource system (self-research):? (I haven't figured it out yet)
6. Configuration system (self-research):? (I haven't figured it out yet)
Of course, no matter from which point of view, this solution is no longer like
DevOps, just use "Jenkins + automation script + self-developed tools" to solve some human flesh work. But it doesn't matter. At least in this way, we can improve efficiency and release resources within a month.
Looking forward from the perspective of the future, who cares if the beautiful blueprint is finally completed? After all, the system or the platform is for human use.
