Recently, the 11th Shenzhen Meetup hosted by CODING, a one-stop DevOps development platform under Tencent Cloud, and DevOps Community in China was successfully concluded. At the meeting, three experts shared their unique industry insights. Chen Xinzhou, product Manager of Tencent Cloud CODING DevOps, At the meeting, we released a wonderful speech entitled “WePack Product Team Test Practice Exploration”. Different from previous sessions, CODING added a closed-door session of fintech technology exchange, and invited dozens of industry giants such as Tencent, Ping An Bank, Shenzhen Rural Commercial Bank, OPPO Finance, Southern Fund, and DJI to participate in the DevOps banquet at Tencent Binhai Building.
The following are the highlights of the closed-door meeting
DevSecOps, a secure lock for DevOps software development
In the Internet era, network information security is an eternal topic. This closed-door meeting will start the discussion with “security”.
Among all industries, the financial industry has a higher demand for safety. Guests from financial enterprises attending the closed-door meeting took the lead in introducing their financial enterprises’ exploration in the field of security. With the implementation of DevOps in financial enterprises, its fast delivery capability is in sharp conflict with traditional security mode, making security the bottleneck of fast delivery. This forced the financial firm to accelerate the transition from DevOps to DevSecOps. Further improve delivery efficiency, enhance risk control, and reduce rework costs by gradually moving the application security mindset left to the development team.
In DevSecOps practice, one of the characteristics of financial firms is the purchase of specialized security tools in the market. Security permeates every stage and checkpoint of the DevOps process by integrating security scanning tools such as Fortify and Checkmarx into the DEVELOPMENT process. Secondly, cultural influence, through strengthening DevSecOps training and assessment, to build a supporting evaluation mechanism. To build a truly mature DevSecOps team.
How do you measure your team’s DevSecOps maturity? A financial company attending the conference mainly did the following work:
The maturity of DevSecOps is divided into several levels and a perfect Measurement model of DevSecOps maturity is constructed by developing measurement indexes such as training time and ability to repair security vulnerabilities. All developers on the team must be level 1; Security champions on the team, at least level 3 to level 5; And ensure that high-risk vulnerabilities scanned by the tool are solved in time before release into the product; Once approved, the DevSecOps team simplifies the security scanning and review process based on the maturity level, enabling the development team to deliver the product more quickly and safely.
Guests from other financial enterprises also expressed that they would embed security capabilities in the development process, implement strict process control and deploy professional application security teams to manage vulnerabilities.
Test or development, who should write test cases?
When it comes to testing, the biggest concern is where the test cases belong. Who writes them? Is it a tester, developer, or product manager? In the actual discussion, it was found that all three could play the role of writing test cases due to different products and projects of services. Due to the high complexity of business in financial enterprises, students often have a lack of in-depth understanding of business in development or testing. Test cases are often written by BA or business personnel. DevOps recommendations are written by developers for test cases. Developers, as implementers of requirements, explain their understanding of functional requirements by writing test cases, which are then reviewed by product and test students, so as to better present functional requirements and development logic in test cases. Of course, many guests present reflected that the current situation of most enterprises is that testers write test cases, because as the responsible person and professionals of this link, they can show the test context more clearly and grasp the test focus more quickly.
In addition, on the coverage of unit testing, the panellists also expressed their opinions. In general, compared with the Internet industry, the financial industry has slower business changes, higher requirements for business stability, and therefore higher requirements for unit test coverage. However, the Internet industry has fast business iteration and high maintenance cost for unit test. Therefore, compared with the financial industry, the Internet industry does not have high requirements on unit test coverage. However, the ultimate purpose of testing is to ensure product quality. It is the right choice to judge and optimize testing methods according to the actual business situation.
How can metrics be used properly in DevOps?
“How to clearly define the level of test defects, not clearly defined words will quarrel.”
“After the beta test, the developer found problems, and it was difficult to confirm positive and negative.”
“Measurement is an abyss, even if it is not considered as a performance measure, as a developer students will still mind, and even cheat.”
When it comes to measurement, everyone is full of bitterness. In the process of promoting DevOps, quality measurement is often regarded as a universal assessment method to ensure the quality of products or projects, and the composition of metrics varies depending on the product, project, development stage, industry attributes, and corporate culture. In this closed-door meeting, the guests also discussed the measurement quality construction of their enterprises and the problems they faced. Compared with theory, in practical work, on the one hand, many contents of products and projects are difficult to be quantified; on the other hand, even clearly defined indicators will be paid too much attention due to the participation of “people”; in addition, measurement is often associated with performance, which makes measurement more sensitive and complex.
At the meeting, we also shared some quality practices.
-
As each team has different ability levels, it is recommended to set a benchmark for team assessment indicators after the team runs normally for half a year. Promote self-vertical comparison, do not expose and criticize the poor team, encourage everyone to improve the overall product quality through fun, rewards and other ways.
-
In the process, it can be measured by escape and mass accident. In the research and development stage, mainly on the basis of low-level quality defects, and then through the test hit back rate, defect density, miss rate and other comprehensive indicators to evaluate the code quality.
-
Metrics should be prioritized based on key factors such as business value, testing, and requirements coverage. In order to avoid side effects, it is not recommended to take local indicators as the assessment standard, and the measurement indicators should be used as a whole.
In fact, the ultimate goal of measurement is to serve products, projects, and customers and bring about positive change across the board. Therefore, I hope you start with the end and do not blindly measure.
It turns out that every company has a different understanding of DevOps, and that’s why there’s a whole bunch of good practices around DevOps. We believe that with the power of DevOps, enterprises will achieve faster development and greater business value in the digital era.