In our project, we employ feature branches where each developer works on their own feature. From a quality perspective, we aim for each developer to be accountable for all pending validations within their branch.
Therefore, we seek to automatically assign all new validations within the branch to the developer of that branch if they are not already allocated. It would be practical to specify this on a per-branch basis, as there may be instances where multiple developers are working within a single branch.
Hi@Martin ,
Thank you for your input. Administratively, this approach seems logical.
However, could you provide further details on the process-related advantages it offers? Whether all validations are assigned to oneself or left unassigned, they are both immediately visible upon accessing the validation screen by default. Therefore, I'm questioning the additional functional value in this situation.
The function is that if you merge before all validations have been solved (you shouldn’t, but hey, sometimes it happens ), you can still see to whom these validations belong.
Currently, we have solved this by creating an additional validation step that is executed last and assigns all unassigned validations. For this validation we created a new validation group with the highest sequence no to make sure it is executed after all the other validations.
In the code we made an extra check to make sure the validations are only assigned to the developer that is executing the validation job. Not sure if this is the best way to deal with this, but it works for us.
To add here, the moment of assigning them to the developer is also up for debate. My suggestion would be: after executing validations, that any messages that come out are automatically assigned to the one executing the validation.
However, developers could opt to not validate at all and merge any changes to another branch, causing validation messages to appear in that branch and being assigned to a developer that does not know where these messages come from. How should the Software Factory deal with this situation in your opinion?
To add here, the moment of assigning them to the developer is also up for debate. My suggestion would be: after executing validations, that any messages that come out are automatically assigned to the one executing the validation.
However, developers could opt to not validate at all and merge any changes to another branch, causing validation messages to appear in that branch and being assigned to a developer that does not know where these messages come from. How should the Software Factory deal with this situation in your opinion?
I think part of the requirement for merging is having had a validation run. Or even run it as part of creating the merge session…
‘create-merge-session’ → start validating → warn if there are any and ask if user wants to continue → do the actual merge-stuff.
I mean, it does not make sense to not run your validations before merging. Make it mandatory.
What about automatically assigning the validation to the one that created or mutated the related object? I think that would make much more sense.
What about automatically assigning the validation to the one that created or mutated the related object? I think that would make much more sense.