CODEWITHSUNDEEP
gitsvnprocessgerrit
geroe
geroe

Reputation: 1

test system for ALL gerrit reviews

we are in the process of switching from svn to git. as our process relies a lot on reviews, we will probably introduce gerrit for that in the future. to better understand my question, let me tell you how we deal with svn nowadays (simplified):

  1. project manager has a bunch of requests from the customer. those requests are discussed with a lead developer who creates the technical specification
  2. the todos are then broken down to max. 2-days-of-work kanban cards
  3. the developer then works on each card individually (all commits have a reference to the kanban card)
  4. when the developer is finished, the project manager checks the card
  5. if that was ok, then the changes are code-reviewed and merged (cherry-picked, actually) and merged into the release branch

so far, so good. this is what can be done using gerrit. i have two problems now:

  1. one kanban card may not be enough for the project manager to test his use case. one card might only be "user interface changes" and the other one "change logic". there is no value in testing them separately (bad example, but still...)
  2. if i have no "branch" with all changes that are testable at the moment, every project manager would need his/her own test system, which will be a no-go for our sysadmins…

does anybody have a similar process? how did you solve this?

thx, georg.

Upvotes: 0

Views: 89

Answers (1)

Rasmus Østergaard Kjær Voss
Rasmus Østergaard Kjær Voss

Reputation: 1866

Seems to me you need some feature branches. Kanban card 1 feature branch (userinterface ) which is deriving from the latest release branch (in your example)

Developer 1 finishes the kanban card in 1 or several commits. If it is several commits i recommend them to be reviewed 1 by 1 on the feature branch

Kanban card 2 feature branch (Logic) which is deriving from the latest release branch as well (in your example)

Developer 2 finishes the kanban card in 1 or several commits. If it is several commits i recommend them to be reviewed 1 by 1 on the feature branch

If this can only be tested together you merge logic branch into userinterface branch and make the verification and testing. If it passed you merge userinterface branch into release branch and software should be ok

If release branch has been moving forward during the development process you should merge in the latest release branch into userinterface branch before testing.

I hope this helps

If those testsystems is anyway triggered and controlled by Jenkins then you can configure jenkins to "listen" to multiple branches and trigger test when you push for review on those branches

Upvotes: 1

Related Questions