[HN Gopher] Reverse Pull-Requests
       ___________________________________________________________________
        
       Reverse Pull-Requests
        
       Author : max-m
       Score  : 3 points
       Date   : 2022-09-02 21:32 UTC (1 hours ago)
        
 (HTM) web link (ideas.riverglide.com)
 (TXT) w3m dump (ideas.riverglide.com)
        
       | itslennysfault wrote:
       | This is the worst process I've probably ever seen. Only one
       | person (or pair) can work on the code (in main) at a time for
       | this to work. It's more effort than just making a branch and
       | merging it to main, and it buys literally nothing.
       | 
       | What is wrong with just creating feature branches and PRing them
       | to main? It's literally the default workflow.
       | 
       | Then when you merge to main you run the CI/CD just like this, but
       | without having to go back and create a "snapshot branch" of main
       | before you started. Also, as you scale you almost certainly have
       | commits from multiple people in main by the time you do this
       | breaking the whole "reverse PR" process.
        
         | wahnfrieden wrote:
         | You're misreading it, you review in batch and in retrospect
         | after it's been put into production (with associated
         | incremental/canary rollout, feature flag etc safety controls)
         | and trunk progresses freely
        
       | kcb wrote:
       | Do people really want to work in pairs all the time? I feel like
       | it would get tiring if not just an occasional thing. There's also
       | value in being able to be an "individual contributor"
        
         | mkl95 wrote:
         | I'm OK with pairing a significant amount of time if it's async.
         | I find traditional sync pairing draining after an hour or so.
         | If you are pairing all the time something has to be off, it's
         | not efficient at all.
        
           | merlincorey wrote:
           | How exactly is it still "pairing" if you are doing it
           | asynchronously?
           | 
           | My understanding and experience with "pairing" is that it
           | pretty much has to be synchronous because generally at least
           | two people should be looking at the same screen while
           | generally one is providing inputs (mouse, keyboard) and the
           | other is providing high level guidance and looking out for
           | low level mistakes.
           | 
           | Doing it asynchronously seemingly would not dispense with
           | sharing the screen and one person handling inputs which seems
           | like it would be even less efficient.
        
         | wahnfrieden wrote:
         | this branch strategy works pairing or not
        
       | max-m wrote:
       | I'm not entirely sure if I got this right, but this system sounds
       | a bit ... weird. Everything is "tested" in production and then,
       | at some arbitrary time, another team does a code review of the
       | code that's already in production and possibly broken? It just
       | seems completely backwards.
        
         | wahnfrieden wrote:
         | Sounds like real innovation toward actual continuous
         | integration and continuous deployment! Indisputably better for
         | the typical DORA DevOps metrics, the trick being relying on
         | other quality controls and not treating code review as a
         | quality control for regressions outside of feature flags.
         | 
         | We operated this way back in the day building Canv.as and
         | DrawQuest but without the snapshotting, that's a nice
         | development
         | 
         | Wish more teams would explore this type of development.
         | Everyone is stuck in the git kernel dev model practices. It
         | probably sounds weird because it's unusual, not because it's a
         | DevOps bad practice (it's quite on the leading edge).
        
           | [deleted]
        
       | Existenceblinks wrote:
       | You could merge PRs branches (not PRs itself) into a shadow-
       | master branch. Every push to any PR creates a fresh shadow-master
       | with selected (labeled) PRs's _branches_ merged. We call this an
       | acceptance branch. Each acceptance branch could have its
       | coresponding staging server.
       | 
       | You could have several acceptance branches with different PRs
       | merged. Each PR can be included/excluded (labeled/unlabeled) back
       | and forth from the acceptance branch (get a fresh one on every
       | label attach/detach)
       | 
       | That's what companies I worked with do. And I even built a SaaS
       | app for that, though they don't want to publicly advertise the
       | app.
        
         | kcb wrote:
         | Similarly gitlab supports merge results pipelines.
         | https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipel...
        
           | Existenceblinks wrote:
           | Yes, partly!
           | 
           | > Merged results pipelines can't run when the target branch
           | has changes that conflict with the changes in the source
           | branch.
           | 
           | Yeah, the app I built even use git's `rr-cache/` (rerere
           | feature) and have gui for resolving conflict and marking it
           | as resolutions. Pretty neat.
        
       ___________________________________________________________________
       (page generated 2022-09-02 23:01 UTC)