Use Gerrit + Zadig to realize trunk development and trunk publishing (including byte flying Book Practice)

A complete product delivery process involves branching strategy 、 Team collaboration process 、 Infrastructure construction and other aspects , Some teams deliver inefficiently , It is often because one of the links has a short board , Effective collaboration needs to be combined with the stage of the project 、 Frequency of product delivery 、 The habits and qualities of team members, etc. to formulate plans suitable for their own team .

In the daily cooperation of the team , Choosing an appropriate branching strategy is particularly important , On this basis, the collaborative process between team roles can be defined and executed , The production process can run efficiently , So that the product function can be delivered with high quality .

The mainstream branching strategies are ：

• The main development , Trunk release

• The main development , Branch release

• Branch Development , Trunk release

• GitFlow

• ...

This paper mainly introduces “ The main development 、 Trunk release ” The branching strategy is  Zadig  The practical process of . The following practical process is mainly based on  Gerrit  Take the source code as an example , Other types of code sources, such as  GitLab、GitHub、Gitee  The same applies .

What is backbone development 、 Trunk release

The development code is submitted directly to the trunk branch , After testing and verification , Use the trunk branch to print and go online .

advantage ：

• Branch management is simple

• It's easy to develop , It's easy to operate , It's not easy to make mistakes.

• Fewer code merge conflicts

• Suitable for high frequency delivery

The key to success ：

• The trunk and branch can be released at any time , Development self-test stage /CR  The process / The verification process of trunk and branch needs to be strictly controlled

• Undeveloped function code , It cannot be brought into the version to be released or realize the function switch , Hide unfinished functions

Detailed explanation of teamwork process

Local development & Self testing  ->  Submit  Pull Request  To   Main branches （main） ->  Code review  &  Merge code  ->  Manual verification function / Add automated test cases  ->  Backbone branch based delivery

Flying book based on  Zadig  The practical process of

The use of early flying books , One team has hundreds of microservices , The service definition uses native  K8s YAML  The way , Use  Gerrit  As a code management and manual audit tool to realize trunk development and trunk release . The specific process is as follows ：

• Submit code changes
  ： Modify the code , Submit  MR , Generate  change-id

• Manual review
  ： add to / Notify the code reviewer ; The reviewer can multiple times  submit  review , Through one  transection  Submit , Pass the review , Can give a score  -2  To  2;

• Machine review ：
  Non blocking automatic trigger  Zadig  Workflow execution validation ： structure -> Deploy -> test ;

• Backbone feedback ：
  After the workflow runs, it will send  IM  notice , And implement  Gerrit  Scoring and verification results  score +1-1

The system can configure review rules , For example, to achieve  2  Auto merge , The situation where there are many automated tests can be like this .

• Based on the backbone release online

Above

The process  3

  Depending on the test environment , It is easy to waste environmental resources and wait for the review process , The flying Book Team chooses to use  Zadig Webhook 

Dynamically allocate idle environment

  The ability of , It can make rational use of environmental resources without blocking the machine review process .

Different environment variables are extracted from the service configuration

Differentiate between integrated environments

 , According to the staffing situation , establish  4  An isomorphic environment , Daily development just needs to submit code and create  Gerrit change, Automatically trigger the workflow for code construction, deployment and automatic testing .

• Development  A 
  Submit an update  service-a  Of  PR1, Automatic triggering  Zadig  workflow  ->  structure  service-a -> to update  ENV1  Of  service-a ->  in the light of  ENV1  Execute test script

• Development  B
    Submit an update  service-b  Of  PR2, Automatic triggering  Zadig  workflow  ->  structure  service-b -> to update  ENV2  Of  service-b ->  in the light of  ENV2  Execute test script

• PR1、PR2  Merge  Master  After that, the workflow is triggered respectively  ->  structure  service-a、 structure  service-b ->  Update all environments , Ensure consistency of all environments and backbone .

Unable to copy content in load

Fly Book follow-up  GitLab  Management code , About  GitLab  The branching model and more practices can be found in the documentation ：

Why did you choose  Zadig  Realize trunk development 、 Trunk release  |  Blog

.

Demo  Demonstration practice

• The basic construction process of the project

Reference tutorial ：

How to use  Gerrit + Zadig  Achieve continuous product level delivery

• More configurations create multiple environments on demand , Specific reference  
  Configure multiple environments  | Zadig  file
  Workflow configuration  Webhook  trigger ：
  Load balancing of the environment  | Zadig  file
  Workflow configuration  IM  notice ：
  workflow  | Zadig  file
  Multiple services share and build ：
  structure  | Zadig  file

Daily R & D and use process

Development Engineer

• Code submission and automatic verification ： Submission code  ->  stay  Gerrit  To create a  Change ->  Automatic triggering  Zadig  Execution of workflow （ structure  ->  Dynamically select idle environment for deployment  ->  automated testing  ）

• Manual code review ：Reviewer  Use  Gerrit  As a code review tool and score , Judge whether the code can be merged according to the scoring results

The system can be configured  rules, For example, to achieve  2  Auto merge

Test Development Engineer

• stay  Zadig  Configure management test scripts on ： 
  test  | Zadig  file

• Verify the new features for the updated environment , Add test cases for new functions

Release Engineer

• Version release based on the verified code of the trunk

• After publishing, execute the workflow to keep the service version in all environments consistent with the trunk

project / Enterprise managers

View the overall health of the enterprise project ：

An overview of the data  | Zadig  file

Analyze the change process of each link of the project and the short board of efficiency ：

Efficiency insight  | Zadig  file

More practical articles on branching strategies and teamwork processes will be introduced later , Coming soon ...

Zadig, Let engineers focus more on creating ！ Welcome to join  

Make complaints about open source Tucao group

More best practices   Click on   Read the original