This article is excerpted from "The Definitive Guide to Software Development Effectiveness" - Chapter 9
core point of view
- Switching back and forth between multiple "point of sale" tool platforms for developers is time-consuming and labor-intensive.
- "One-stop" refers to the integration of software engineering capabilities in all aspects of research and development on a unified platform, which is friendly to newcomers and improves efficiency for the elderly.
- "One-click" means that R&D engineers only care about the work with creative value, and do not need to deal with things that can be automatically completed by the R&D platform.
- The "dual-stream" model can realize the two-way automatic linkage of the demand value stream and the R&D engineering stream.
Challenges faced by traditional single-point R&D efficiency tool platforms
A complete R&D efficiency tool platform needs to include functions such as requirements collaboration, code management, construction capabilities, testing capabilities, environment deployment capabilities, product management, configuration management, monitoring and alarming, and efficient operation and maintenance. It can be said that the performance tool platform is the carrier of R&D work, covering all aspects of the software R&D life cycle . If its design and user experience are well done, the fluency of the overall R&D process will be high, and the effective value of engineers will be better. to be played.
Each link in the software R&D life cycle has its own single-point tool in its own field. For example, Jira is commonly used as a requirement management tool, and GitHub and GitLab are commonly used as code management tools. Whether the single-point tool platform in these vertical fields is a commercial The product is still self-developed by the enterprise, and it basically provides services for engineers in the enterprise in the form of SaaS.
To complete a requirement development task, a development engineer often needs to switch back and forth between multiple single-point vertical tools. The stricter our software engineering discipline and process control, the more times the tools will be switched back and forth, and each switch may need to manually transfer information between various tool platforms, or even "translate" information.
For example, in a typical development task scenario, a development engineer first needs to access the requirements management tool, find the corresponding task item, and then change its status from "to be developed" to "under development", and then go to the code management tool Find the corresponding code warehouse in and download the code. At the same time, use the development task ID in the requirements management tool as the branch name to create a function branch, and then complete the local development and testing work on the function branch. During this period, in order to shift the quality to the left, the code rules in the remote static code scanning tool are often used in the development process to perform static code inspection locally, and the Mock capability is also used to complete local unit testing**. When the local development and testing meet the quality requirements, the code review will be submitted first through the code tool, and then the code review interaction will be completed with the support of the tool platform. After that, the CI platform will be used to execute the pipeline during the code integration process, and the pipeline will complete a series of Steps (such as unit testing, static code scanning, security scanning and compiling, etc.), and after meeting the requirements of quality access control, the generated products will be stored in the product library. Finally, the development engineer also needs to visit the requirements management platform again, find the previous task, and set the status of the task from "under development" to "to be tested".
I believe that many developers are already familiar with the above process. In this process, in addition to business code development and testing, you need to deal frequently with various tool platforms. You need to access the demand management platform to receive tasks, you need to access code management tools to pull code and create branches, and you need to call the static code scanning platform. , the ability to use the CI platform and product library is also required, and finally, the requirement management platform must be accessed again to update the task status.
In this process, there are multiple tool switches, which will take a lot of time on procedural matters, resulting in a waste of time and energy. You also need to be very clear about the usage methods and processes of each tool platform.
To make matters worse, the conceptual models of various tool platforms may not be completely consistent. For example, the concept of "project" on the code management platform and the "project" on the test platform may not be concepts under the same logic; for example, the concept of "application" may not have the same meaning on different tool platforms, which makes the development process The fluency of the software is greatly reduced, and the cost of understanding and learning for engineers is very high. At the same time, isolated islands of R&D data will be formed among various tool platforms, making it difficult to collect and measure unified R&D process data. Therefore, we urgently need a "one-stop" and "one-click" unified R&D efficiency platform to horizontally integrate and pull through various tool platforms , so as to improve the overall efficiency of the R&D process.
"One-stop" and "One-click"
"One-stop" concept
"One-stop" refers to the integration of software engineering capabilities in all aspects of R&D on a unified platform. R&D engineers no longer need to visit multiple tool platforms back and forth during the R&D process, and do not need to manually remember and follow the R&D process. There is no need to remember the access entrances of multiple tool platforms. This design is friendly to newbies and more efficient for old people.
Specifically, R&D engineers do not need to remember the domain name of each single-point tool platform (such as requirements management system, CI system, automated testing system, etc.), and complete all R&D tasks on a unified research platform, and The output of each stage can also flow more smoothly between various tool platforms . In this way, not only can the authority management system of each tool be unified, but also the measurement data collection of the R&D process can be automated without any human intervention, and the concept terms in each tool can also be unified under the one-stop concept. The various stages of each stage can realize seamless linking and collaboration, and realize the real R&D whole process pipeline.
"One-click" concept
With "one-stop" as the basis, "one-click" can be further realized on this basis. "One-click" is a sharp tool to truly improve R&D efficiency.
"One-click" means that R&D engineers only care about the work content of creating value, such as focusing on architecture design, writing code, writing unit test cases, conducting code review and other activities; instead of dealing with transactions that can be automatically completed by the tool platform Sexual work, such as requirement status flow, code branch creation, static code inspection, test environment setup, application deployment, test case execution, etc.
The most ideal effect of "one-click" is that after the user submits the code, he does not need to manually complete the follow-up transactional work, and does not need to stare at the entire process to wait for the next step, but can turn to other things to study the effect. The platform will automatically perform static code scanning and unit testing, determine quality access control, build products, deploy products to the test environment and perform interface testing, and then deploy products to the pre-release environment. After automated system testing, the final realization of the production environment In the process of official release, grayscale release and other mechanisms will be used to reduce risks. In the whole process, R&D engineers are required to intervene only when errors occur, which truly realizes "a shuttle".
"Double Stream" Model of R&D Efficiency Platform
The "Double Stream" model of R&D efficiency proposed in this book is the best interpretation of the concepts of "one-stop" and "one-click". The "Double Stream" model includes demand value flow and R&D engineering flow, in which demand value flow is the perspective that product managers and project managers focus on, reflecting the completion status of each requirement and the overall completion of the project; R&D engineering flow is the perspective that R&D engineers focus on , which reflects the completion status of the development task in the engineering dimension, and more from the engineering perspective of code, test and CI/CD to see the progress of the task.
The "dual-stream" model of R&D efficiency realizes the two-way automatic linkage of demand value flow and R&D engineering flow
Two-way automatic linkage between demand value flow and R&D engineering flow
In the "dual-stream" model, the two-way automatic linkage between demand value flow and R&D engineering flow can be realized. It is not necessary for R&D engineers to update the task status in the requirements management system after completing the development and testing tasks. The status update of requirements (for example, requirements The status changes from "under development" to "to be tested") and automatically flows after the code branch is merged into the trunk, without manual participation, so that R&D engineers can better focus on the work of creating value.
The "double stream" model is a reference for realizing the R&D efficiency platform, and it is worth learning from. The following will introduce the working principle and implementation of the "dual-stream" model through specific examples.
First, before the start of a R&D iteration cycle, we will select from the Backlog the list of requirements tasks that need to be completed for the iteration, and decompose each requirement into development tasks. Ideally, we try our best to control the granularity of each development task within the scope of a code warehouse. If the realization of a certain business requirement requires the modification of multiple service modules (such as multiple microservice modules) , it is recommended to create a development task for each module. That is to say, it is recommended to create multiple independent development tasks, arrange the iteration plan in units of development tasks, and each development task will determine the candidates for development engineers in advance.
In the traditional mode, after an iteration starts, the development engineer assigned the task will receive the system email notification, and then read and understand the requirement in the requirements management tool according to the link in the email, and manually set the status of the task to " "Under development", then go to the code platform to pull the corresponding code, create a development branch, and then start development and testing in the IDE. However, the performance tool platform realized by the "dual-stream" model will be much simpler. There is no need to switch between requirements management tools, code platform tools, and IDEs, and all work can be completed in the IDE. **The specific process is as follows:
After a development task is assigned to a development engineer, the IDE used by the engineer will receive the task assignment notification through the IDE plug-in of the research platform, and the engineer can directly read the requirement details in the IDE and receive the task with one click. This picking behavior will first automatically pull the code of the corresponding code warehouse to the IDE workspace, and then automatically create a functional branch of the code with the name of the required task ID, and ensure that the IDE has switched to this branch. At the same time, the API interface of the requirement management platform will be called automatically, and the status of the requirement task will be changed from "to be developed" to "under development". This series of behaviors are directly and automatically initiated by the IDE plug-in of the research platform, which is completely transparent to developers . All they have to do is to simply receive tasks in the IDE with one click, and then they can concentrate on local development and development. The test worked.
After the local development and testing tasks are completed, when the current functional branch reaches the deliverable state, the development engineer directly initiates a code merge request in the IDE, and the code merge request will be taken over by the CI subsystem in the research platform first, and then the CI subsystem The subsystem automatically initiates the code review process, and the interactive process of code review can be directly integrated in the IDE. At the same time, the research platform tool can automatically recommend the best reviewer according to the Code Diff of the code change. For example, it is a very economical choice to use an engineer who has changed the same logic in the recent period as a reviewer, because its cognitive cost is the lowest. Furthermore, the research efficiency platform tool will also mark the size of the code review change, so that the reviewer can choose the appropriate review content according to the size of their free time segment . After the code review is completed, the CI subsystem will automatically trigger the CI pipeline to complete routine unit testing, static code scanning, and judge the achievement of quality access control, and finally generate the product and upload it to the product library. Next, the research platform tool will automatically call the API interface of the requirements management platform again, and change the status of the requirement task from "under development" to "to be tested".
The follow-up link of the R&D process will also adopt a similar linkage design, using systematic tool capabilities to ensure the linkage between the demand status and the actual status of the code.
It can be seen that the R&D efficiency platform built with the concept of "dual-stream" model can allow engineers to focus on the most critical core tasks without the need for manual transactional work, making the value flow of the entire R&D process smoother, thereby improving The research and development efficiency of the team has once again verified that "a worker must first sharpen his tools if he wants to do his job well".
Efficient practices in all stages of software development
In addition, the "two-stream" model also clearly defines efficient practices at each stage of software development. For example, what are the best practices in the requirements phase that can ensure performance from the source, what practices can ensure quality and efficiency improvement in the local development and testing phase, and what efficient practices are in the code integration phase, etc. Efficiency practice is actually the specific practice and implementation of each stage of the "Double Stream" model, which will not be introduced in detail here.
The "Double Stream" model of R&D efficiency clearly defines the efficient practice of each stage of software R&D
Summarize
This part introduces the pain points of the traditional single-point R&D tool platform in the horizontal dimension, and on this basis, puts forward the concepts of "one-stop" and "one-click" R&D efficiency platforms. At the same time, it introduces the implementation case of this concept: the "dual-flow" model of R&D efficiency, and introduces the two-way linkage capability of demand value flow and R&D engineering flow in the "dual-flow" model.
