With 8 years of product experience, I have summarized these practical experience of continuous and efficient research and development

Preface ：

In the whole link process of production and research , The biggest goal of collaboration is the transparency of team information , That is, carry out the daily research and development work of team information transparency under the guidance of clear goals , Supporting projects / The product was successfully released . Based on this , Whether the research and development process is effective has become another key element we pay attention to . Usually 「 R & D process 」 Refer to ： The whole link from code to product to deployment and launch , This process is the top priority of continuous integration .

This issue mainly focuses on 「 R & D process 」 Explore , Before sharing practice , I want to discuss with you first , In the whole process of software development , What kind of

product

and

characteristic

To support our continuous pursuit of efficient research and development （ This period mainly focuses on cost 、 Efficiency of the , The quality will be analyzed separately later ） The goal of , I thought about a few things （ Part of the content will be explained in detail in the practice sharing of the text ）, Let's throw a brick here and welcome everyone to discuss .

Think about a

 

Support the team to precipitate practice and culture through custom configuration .

All team members are using product functions , It will imperceptibly follow the practice route that the team hopes . One side , The research and development of the team is carried out according to the established route , R & D efficiency is predictable ; On the other hand , New team members can also quickly integrate into the team development mode , Quickly integrate into the team culture .

Think about the second

 

In the whole link of software development , Should have the ability of high automation .

Research and develop all nodes in the full link workflow , Through the ability of high automation , Can achieve the following goals ：

• In addition to code development and project management information entry , Try to reduce the manual operation of login platform ;

• Automatic accurate message push , With the help of the capabilities of the end , Let users view R & D and project management information by local asynchronous subscription .

Think of three

 

Powerful and rich end capabilities .

Enable R & D members to immerse in local development , Goals should be imperceptible  DevOps  When the platform exists , Use platform capabilities all the time .

Think about the four

 

Product capabilities and forms should be highly customizable .

It is unrealistic to support and cover all industries through a product form , One  DevOps  Platform R & D team , It is impossible to understand and be familiar with the R & D mode of all walks of life , It is even more impossible to define practice to lead R & D and improve efficiency in all industries . What the platform can and needs to do is ： Strengthen the underlying basic capabilities of the platform 、 Be flexible , Let the industry leaders , Guided by the theory of efficient and continuous delivery , Make use of the rich basic capabilities and highly customized configuration capabilities of the platform , To build a research and development practice model of their own industry , Finally, the replicability of the template is precipitated through the industry R & D practice mode , Help improve the overall R & D efficiency of the industry .

Think of five

 

The platform needs to be deeply combined with a low code development platform , Make application research and development easier .

Think six

 

With the help of  AI  The ability of , Help improve user code development 、 quality 、 Security 、 Problem location and other application R & D process efficiency .

Thinking seven

 

Combined with big data 、AI、 Technical features such as function calculation , Let R & D efficiency measure 、 Observation capabilities such as operation and maintenance monitoring have become stronger .

• Through public cloud or enterprise level big data 、AI  Docking with the underlying cloud computing capabilities , Let R & D efficiency measure 、 The cost of monitoring data statistics has become lower ;

• Through function calculation, users' flexible statistical demands for R & D efficiency and monitoring data are met in a low-cost way ;

• Through low code development platform  + DevOps  The bottom of the platform  Tracing、Logs、Metrics +  Function calculation  +  Data visualization , Allow users to quickly build a monitoring and operation and maintenance system based on industry best practices , Templates can be copied to users in other industries .

Get down to business , Next, I will mainly focus on 「 R & D full link 」 set out , Share it  Erda  The specific practice process of the team , I hope it can bring you new thinking .

Backbone based development mode

In terms of R & D mode ,Erda  The team adopts the trunk based development mode （Trunk Based Development）, Compared with the trunk development mode, there is also the feature branch development mode （Feature Branch Development）, Its typical representative is  gitflow  Pattern . Both are commonly used software branching patterns in the software industry , Each has its own advantages and disadvantages , The most important thing is to choose what suits you .Erda  The original intention of the team to choose the trunk based development mode , I want to release the version as soon as possible in the way of continuous integration , And hope to promote the team to become an elite performance team through the backbone development mode .

Erda  The goal of the team based on trunk development ：

• New code is integrated into the trunk every day , Complete continuous integration every day 、 Keep testing

• Available for release at any time , Features can be urgently released online on demand

• Product features can be verified quickly , Reduce trial and error costs

In order for the team to achieve the above goals through the trunk development mode , Yes

Two practical points

It's very important ：

• High requirements for project collaboration ： Task split （ Refer to the suggestion of task granularity in iterative event coordination , Try to split it into  1-2  God ） Need a small enough drive  mr  smaller , Thus, it can support the rapid realization of verification and trial and error of product features from the perspective of project management ;

• High requirements for R & D Quality ： Fast feature development , We cannot sacrifice quality fast , So in this fast premise , The requirements for the combined feature code will become higher , The key here is that development needs to ensure code quality , Don't think about handing over quality to the testing team  ( Build automated processes against rules 、 standard 、 The specification is automatically checked ; unit testing ; Database specification and so on ）.

After analyzing the key points of practice , Next, let's take a look at the specific practical steps and what we need  DevOps  Platform tools to support .

Code development based on trunk branches

Split requirements into tasks through project collaboration , After the R & D students claim the task, they enter the development work , The first job of development is to create a

Feature branch

（Feature/  Mission  ID） Code hosting for this feature .OK, For new members of the team, the first step may be the problem  

Feature  Who is the source branch of ？

The team adopts the development mode of trunk and branch , Nature is to branch from the trunk （Master） Here we go , For students who are familiar with team development mode , It's not a problem at all , New students only need to go through training or by themselves  google  Study it and you will understand .

Of course, the practice and culture of the team can be realized through the constraints of management norms , But the ancients also said “ Blocking is not as good as sparse. ”, Whether these practices can be defined in the product ？ Interact through product functions , Guide users to follow the predetermined practice route of the team .Erda  This is how teams practice , It's not bad ！

The overall process from code development to testing

Standard configuration based on trunk branch development

Erda  The R & D specification of the team is defined and configured in the R & D workflow of the product , The content involves the branch list 、 Branch policy and workflow configuration , The specific diagram is as follows ：

Erda  product - The schematic diagram of R & D workflow configuration is mainly based on the actual interaction of products

Specific configuration content of workflow ：

The specific configuration content of the branch policy ：

The specific process

• R & D students in the task details , Select apply and click Create workflow . After the workflow is created, the corresponding development branch will be automatically created （ Such as feature/XXXX, among  XXXX  Represents characteristics  ID）;

• Carry out self-test of temporary consolidation and deployment of the system with the same application, the same environment and different characteristics . adopt  Erda  The platform provides the function of temporary merging of systems with the same application and different feature branches in the development environment , Let all feature developers deploy and smoke test together , Greatly reduce the pressure on environmental resources without affecting efficiency ;

• After R & D self-test , Workflow can be initiated with one click  MR  Merge request , Research and development  TL  Related branches of merge request  Code Review  after （ Because the relationship between events and branches in task workflow is bound ,Code Review  You can clearly know the specific task content of this consolidation request ）, The feature branch is automatically merged into the trunk branch , Trunk branches pass through timing / Code change triggers for integrated deployment + test , So far, the feature task status of the R & D students will also be completed automatically .（ The above features are under development , At present, it is initiated manually  MR  Please give priority to ）.

Daily integration deployment based on trunk branches

adopt  Erda  Platform to support project level daily continuous integration deployment . Through the project pipeline , Build the latest products of various applications （ Based on the latest code of each application trunk ） And integrate the whole product of the project into a unified trunk test environment （Erda  It is called integrated environment ）.

The deployed strategy is daily  23  when , Timed trigger pipeline operation construction 、 Integrate 、 Deploy  ( Other projects can also set other deployment strategies according to the actual situation ).

Daily continuous testing based on trunk branches

automated testing

• Use case management

According to demand  deadline , The test will be based on the completion time of the characteristics of the R & D students , To arrange automated test cases （ Mainly based on  API  Interface testing ） And the completion of functional test cases . After the characteristic branches of R & D students are merged into the trunk branches , Test students will add automated test cases of new features to the original test plan , Existing automated test case regression ensures the availability of previous features .

• Automated test execution

How to trigger the daily continuous test ？ That is, by deploying  action, Trigger the execution of the automated test plan .

• Automated test result notification

The automated test results are synchronized to the R & D team through nails .

Manual function test

Automated testing does not cover 100% of all product features , For features that automation cannot cover , It needs to be done manually . Functional tests need to be covered manually again and again by the manpower of the test students , Not to mention the necessity , Labor costs may be intolerable to agile teams . For such a scene ,Erda  The team mainly adopts the following strategies in manual functional testing ：

• Manual functional test coverage is required for iterative new functions , It is mainly about the targeted testing of the requirements of the current iteration by the testing team ;

• The test team is based on requirements 、 Determine the general content added every day based on the status of the task  (erda  The test team is even asked to pay attention to the development submission  MR/PR, The requirements for the test team are higher ）.

Product management strategy based on trunk branch

In the ordinary sense 「 Software products 」 Mainly a collection of source files or compiled products , It mainly includes

Binary package

and

Compressed package

Two forms . If based on  Erda  platform , The concept of products is a little difficult to distinguish , We mainly define it as including all the content required to deploy an application , Including images 、 Rely on the  Addon  And various configuration information , The ultimate goal is that products can be used in any set  Erda  Deploy at the environment level .

The definition and specific function points of products are not analyzed and discussed here for the time being （ If you are interested in the product management function, you can contact us to continue the discussion ）, Or return to the theme , To share  Erda  The team focuses on the practice of product management .

Semantic version management

First of all, in the management of product versions and types , The team mainly adopts 「 Semantic version 」 Management specification , It mainly involves the following version types ：

• alpha： Just pass the R & D self-test , Untested version , The unstable version

• beta： The phased test passed , Relatively stable version

• stable： After systematic testing , Stable release

The relationship between version and branch

secondly , Strong practice binding has been made on product versions and branches （ It is mainly completed through R & D workflow configuration ）. No matter how the product is defined , It must be based on code or compiled products , In other words, the product must come from the code . therefore  Erda  In practice, the team binds branches and artifact types , And precipitate this to  Erda  In the product , Of course, the product supports the custom configuration of R & D workflow to meet the association of other feature branches and product version types .

Erda  The R & D mode of the team is based on the backbone R & D mode , So the relationship between branch and version type is as follows ：

If the  Gitflow  You can refer to the following ：

Version and branch configuration

Configuration of branch and artifact versions ： Configure in the R & D workflow

Main process description ：

• R & D students are  feature  After development on the branch , And complete self-test in the development environment , Code merge to trunk branch （Master）;

• Main branches （Master） Execute the pipeline through the daily timing trigger , It will automatically build and generate 【 Version number  + alpha + Time stamp 】 The product of ;

• All feature codes in the iterative version are merged into the trunk branch （Master）, And after the automatic test cases and the manual function phased test of the test students , Test students will branch from the trunk （Master） Cut out the iterative version of  Release  Branch （ Branch name ：Release/ Version number -beta+ Increasing numbers ）, The frequency of time depends on the release frequency of the team （Erda  The release frequency of the team is weekly , So the time frequency here is weekly ）;

• When the iteration version reaches a certain period , Generally, a formal version of the product will be released （ This version can be the previous iteration version , It can also be composed of multiple iterative versions , This depends on the release plan of the product ,Erda  A big product  Rc  Version by  4  An iterative  beta  The features of the version consist of ）, Test students will branch from the trunk （Master） Cut out Release  Branch （ Branch name ：Release/ Version number ） Conduct a comprehensive test ;

• Students pass the test  Release/ The version number branch pipeline builds the  beta  products , After passing the test verification , Test students will manually put this  beta  The version artifact is switched to  stable  edition , And maintain the products in the products  ChangeLog  And product labels , Finally released to  Gallery  The provided delivery team downloads and uses .

Release the train

Concepts and rules

Release the train , It usually refers to setting a fixed publishing window , The specific time can be fixed by week or month , Publish regularly at this time , The product features will be released as soon as they can catch this train , Otherwise, you need to wait for the next train .

The rules for releasing trains seem very simple , Just publish it at a fixed time , It's not , The team cannot make the release efficient through a concept of release train , What can really drive the efficient release of the team also needs to start from the establishment of the release culture of the team , Culture also relies on the precipitation of Publishing Rules ：

• Scheduled departure . Train inequality , Reject untested new features ;

• Only release high-quality features . Only the features that pass the test are allowed to get on , Even when the R & D has completed the relevant features and it is required to go online , We must also resolutely refuse ;

• Release trains frequently , The feature split is small enough . Faster and smaller releases can improve the quality of products 、 A lower cost , Frequent releases make the features of each release smaller , When problems arise, positioning and solving will also become more clear and efficient , Of course, the frequency of release needs to be determined according to the overall quality of the team's R & D and management , Not blindly pursuing speed ;

• There is no perfect release in the world , Clear key performance indicators are needed to decide the release of controversial features .

Erda  Team practice

Based on the above rules ,Erda  The team's practice is as follows ：

Summary

No matter from project collaboration 、 The whole process of R & D and the final release train , Its essential goal is to support the continuous and rapid development of application software in an efficient way 、 High quality update release , For this purpose , Every company has its own practice and opinions , There is no right or wrong , As long as it is in line with the maximization of the current interests of the enterprise , It is enough to be able to lay out the future of the enterprise . This article just uses  Erda  A team perspective was shared , Welcome to share and discuss the practice of R & D and efficiency improvement , Jointly promote the improvement of the efficiency of the whole industry , thank you ！

For more technical dry goods, please pay attention to 【 Erda  Erda】 official account , Grow with many open source enthusiasts ～