Background:
The popular "test swimlane design" has been implemented in Ziru.com through the self-developed release system "Omega" developed by the Infrastructure Center, called "Feature Environment", but the actual effect is not satisfactory in the process of implementing the use of business lines. In order to solve this problem in depth, we will conduct research and practice.
01
Problem analysis
At the end of August 2022, sort out the current situation. It is divided into three question sections:
1. It is difficult to initialize a stable environment;
2. Poor ease of use in the characteristic environment;
3. Low reliability of the characteristic environment.
1.1. It is difficult to initialize a stable environment
1.1.1 骨干链路配套缺乏
The upstream application that depends on the stable environment for the current application deployment may not have a stable environment.
1.1.2 Conflicts in the original environment
The network conditions in the current stable environment are the same as those in the QA environment. The reasonableness of reusing MySQL needs to be evaluated. Some people avoid using the QA environment to avoid impacting the QA environment.
1.2. Poor ease of use in the characteristic environment
1.2.1 The process of creating an environment is cumbersome
It goes through four processes: environment creation, resource application, branch creation, and merge deployment. The link is long, and the front and rear connection is poor.
1.2.2 Understanding the concept of swimlanes is complex
The cost of lane design is high for education and R&D personnel, and it is difficult for personnel to define swimlane identification in actual operation.
1.2.3 Lack of best practices
After creating a feature environment, the deployment is successful, and there is a lack of best practices, so that it is not easy to use it after creation.
1.3. Low reliability of the characteristic environment
1.3.1 Middleware initialization conditions are strict
Currently, only RabbitMQ is supported. (The underlying layer is to use the AMQP proxy and create a new RoutingKey and Queue to implement the swimlane feature.) However, the preconditions for message queues are more stringent: the queue relationships associated with the Omega application must be saved correctly, otherwise the feature environment of the Omega application will not be created correctly.
The queue creation service itself may be unavailable. (There was an incident where the feature environment creation called the development API that created the queue, but the subsequent API failed to create the queue due to the addition of permission authentication).
1.3.2 Middleware does not natively support swimlanes
Dubbo uses the ZooKeeper Tag injection method to implement the implementation. However, in some versions of ZooKeeper, the tag may be missing.
1.3.3 Reuse middleware data is disordered
There is a lack of specifications for the use of persistent databases such as MySQL. There are cases where different environments process the same data.
02
Solution analysis
For three questions:
1. It is difficult to initialize a stable environment;
2. Poor ease of use in the characteristic environment;
3. Low reliability of the characteristic environment.
Customize the strategy in three aspects.
2.1. It is difficult to initialize a stable environment
2.1.1 Ignore environmental isolation issues
Daily, QA, and Stable are unified into the Test environment. Connect environments to access each other. Middleware configurations can be reused across environments.
2.2. Poor ease of use in the characteristic environment
2.2.1 Optimize the process of creating a feature environment
Condense the original steps such as "Feature Environment Creation", "Swimlane Logo Selection", "Environmental Resource Approval", "Build Parameter Configuration", "Enabling Platform Empowerment", and "Feature Branch Integration" into a "Add Feature Environment" button. Feature environments can be quickly created with just one form.
2.2.2 Deploy your own services for simulation practice
Based on Omega itself, new functions are tested using a characteristic environment. Discover, collect, and solve problems during the testing process of new features, and input your own thinking and best practices. Provide ideas and directions for subsequent iterative optimization.
2.3. Low reliability of the characteristic environment
2.3.1 Write test cases
Verify the reliability of existing functionality.
2.3.2 Fix existing anomalies
Based on the results of test cases, fix existing exceptions.
2.3.3 Write documentation for use
Write preconditions for using functions based on the current situation (for example, if the RabbitMQ feature function is enabled correctly, the Omega application must be correctly associated with the queue on the ZMS platform, otherwise the queue will not be created correctly)
03
Solution Practice
| serial number | Matters | Head | illustrate |
| 01 | Write test cases | Xiong Chao | Verify the reliability of existing functions in the feature environment: HTTP, Dubbo, SpringCloud (Eureka, Nacos), and RabbitMQ. |
| 02 | Fix swimlane anomalies | Xiong Chao | The issue that RabbitMQ instance cannot be created is fixed. Added and improved the preconditions for the correct creation of RabbitMQ. |
| 03 | Optimized swimlane creation | Huang Cheng | Added button to create a feature environment based on branches and associated Jira. Automatically initialize feature environment-related configurations, including but not limited to: enabling incremental code coverage collection (SuperJacoco), environment configuration initialization (memory and CPU), runtime variable inheritance (LinuxEnv and Hosts), and Maven build parameters (MavenRepo). |
| 4 | Verify feasibility | Huang Cheng | Based on Omega's own front-end and back-end verification of the creation of the feature environment and the application of the feature environment. |
4
Practical thinking precipitation
In the real practice, I encountered the following four problems:
1. What middleware should be connected to the stable environment deployment of Omega?
2. What are the prerequisites for the deployment of the Omega feature environment?
3. How should I use the Omega environment after it is created?
4. What are the advantages of the characteristic environment compared with the original environment?
I'm sure you'll all face the same problem when working with the Omega trait environment, so I've written about it here.
4.1. What middleware should be connected to a stable environment?
Due to historical reasons (no QA involvement), unlike the line of business, the vast majority of applications in the infrastructure center do not have a KQ environment. Therefore, Omega encountered the first problem when deploying a stable environment: does it need to notify the upstream system to deploy a stable environment when docking with the upstream system?
After a short period of reflection, I realized that it was neither possible nor necessary to interface with all stable environment applications and middleware.
Here's why:
1. When the application developer needs the feature environment, it is impossible to immediately promote all the upstream applications to access the stable environment, and even if they do not rely on the upstream stable environment applications and middleware, they can also connect the applications and middleware of the original environment for the development of the feature environment.
2. When multiple applications need to be connected to the characteristic environment in the future, it is too late to make modifications. This is because if multiple applications are in-house, they can also be deployed collaboratively across lines of business based on the same goals and technology foundations.
Therefore, based on this judgment:
I deployed the front-end and back-end (omega-ui and omega-api) of Omega to a stable environment, and only connected to the applications and middleware of the original environment.
Most of the applications and middleware connected to the omega-api are in the Daily (KT Daily) environment, such as Message, Opst, and SIA.
The omega-ui is also a service for the Daily (KT Daily) environment, such as private cloud login.
4.2. What are the requirements for the successful deployment of the feature environment?
In practice, the problems I encountered were divided into two parts: the back-end and the front-end.
Problems encountered in backend deployment:
1. Cross-environment access
a) It is necessary to access daily environmental services in a stable environment and a characteristic environment. Cross-environment access is performed through hosts configuration. This function is only available within the underlying platform. Most of the business lines are deployed in the KQ environment, and some of the stable environments are deployed.
Front-end deployment encounters:
1. Front-end compilation problems
a) To compile the stable environment, you need to add npm run build:stable. You'll need to add stable.env.js build profile to your index.js.
4.3. How can I use the feature environment after it is successfully deployed?
1. Analysis: There are three situations in total: 1. Only front-end development, 2. Only back-end development, 3. Both front-end and back-end development need to be developed. Since Omega only involves web development, it only explains the best implementation of web development, and the same goes for mobile replication.
2. Prerequisites: Both the front-end and back-end have been deployed in a stable environment. And use a stable environment for domain name access. The Omega front-end is accessed through omega.ks.ziroom.com and is connected to omega-api.ks.ziroom.com back-end.
3. Deployment logic of the feature environment: development is deployment, and no development is no need to deploy. If only the front-end is developed, only the front-end is deployed to a certain feature environment, and the backend is the same.
4. How to use: Rely on the Chrome plug-in ModHeader, which functions as adding KeyValue to the Header. In practice, add ziroom-env-tag and JiraID for swimlane identification.
Elaboration:
In principle, you just need to follow 2, 3, and 4. The detailed explanation of why this is done is as follows:
It is still divided into three types of scenarios based on 1: 1. Front-end development only, 2. Back-end development only, and 3. Front-end and back-end development.
1. Front-end development only: after deployment to the feature environment. Since the frontend is deployed, the front-end application that will automatically be FullBack to the feature environment is accessed through the omega.ks.ziroom.com tags, and since there is no feature environment backend, the request will be provided by the stable environment backend.
2. Back-end development only: In the same way, only the back-end of the feature environment is deployed. Since the front-end is not deployed, even if it is omega.ks.ziroom.com with tags, it will still return to the page through the front-end of the stable environment and access the back-end services of the feature environment at the same time.
3. Front-end and back-end development: both use characteristic environment applications to provide services.
4.4. What are the advantages of the characteristic environment compared with the original environment?
If it is only used for the sake of use, it is inevitable that there will be a suspicion of self-conformity, and the matter of holding a hammer to find a nail is undoubtedly a great waste of cost. So in my personal practice, what are the benefits that are more valuable to me for your reference?
1. Troubleshooting abnormalities is more independent.
a) Thanks to the code coverage scanning tool, incremental codes can be scanned. When an abnormal outage occurs, you can quickly locate which line of code broke so that the problem can be quickly located in the test environment.
2. Environmental isolation does not interfere with each other.
a) If there are multiple parallel tests, there will be no logical impact on each other due to parallel tests. For example, function A depends on a switch to be "on", but function B depends on a switch to be "off". Debugging tests can be performed in different environments through mocking.
3. Lane link debugging
a) If there is a need to cross multiple applications, there is no need to start the full application coverage test link, which is beneficial to reduce the cost of test link deployment for business line testing.
05
postscript
The reason why the title "Never know what to do" is actually a reference to the phrase "eat your own dog food" in software development. Although the primary audience of the feature environment is line-of-business R&D, we don't know what problems will be encountered in the real world without hands-on practice. Only after hands-on practice can we discover problems in practice and finally solve their existing difficulties.
Author: Internet platform - Huang Cheng
Source-WeChat public account: Ziru Technology
Source: https://mp.weixin.qq.com/s/oG7jqA3px8wqb2epPUraUw