revisione del codice a due livelli utilizzando la richiesta git pull in BitBucket

2

La seguente procedura: abbiamo il ramo Sviluppo e

  1. Lo sviluppatore crea un ramo di funzionalità da Sviluppo
  2. Lavorare e impegnarsi in questo ramo
  3. Rebase from Development
  4. Crea richiesta di pull
  5. Revisione del codice
  6. Unisci con lo sviluppo

Problema che dovremmo avere una revisione del codice a 2 livelli, eseguita da persone diverse. Dopo la prima verifica dell'approvazione, viene eseguita la seconda revisione e la fusione solo dopo questo.

Come si fa? Dovremmo aggiungere ulteriore succursale tra i rami Feature e Development? O qualche altro modo più semplice?

    
posta Alexan 23.08.2017 - 17:33
fonte

3 risposte

3

Lo faccio abbastanza spesso, per microservizi di proprietà di altri team o per modifiche alla documentazione dei pub tecnologici. Disponiamo di repository separati per i singoli microservizi, con solo un team di scrum o due che dispongono di autorizzazioni di unione per ciascuno. Voglio che il mio team riesamini accuratamente prima che sprechi il tempo del team proprietario.

Il modo più semplice che ho trovato è quello di inserire il repository nel mio profilo privato, quindi fare tutto il mio lavoro da un ramo sulla mia forcella. Faccio prima una richiesta pull con master sulla mia fork, poi quando viene approvata, esegui una richiesta pull rispetto a master sul repository "ufficiale".

Il motivo per cui ho iniziato a farlo in questo modo è che il nostro team è in qualche modo un innovatore fidato, quindi gli altri team spesso fondono semplicemente qualsiasi cosa li abbiamo inviati senza metterlo in discussione. Fare la prima richiesta di pull in un repository separato significava che non potevano unirlo prematuramente semplicemente facendo clic su un pulsante. Le autorizzazioni e la visibilità su entrambi i repository sono facilmente controllabili.

Non devi farlo con forchette personali, potresti creare repository per gruppi più grandi di lunga durata se questo funziona per il tuo caso d'uso. Forse un repo per ogni cosa da una certa ditta appaltatrice, per esempio.

    
risposta data 24.08.2017 - 02:36
fonte
5

Vedo due modi per gestirlo.

  1. Configura una seconda richiesta di pull dopo che il primo ha avuto successo, assicurandosi di non completare il primo PR e di unirlo. Qui sotto c'è la possibilità che il ramo venga accidentalmente unito.

  2. Aggiungi entrambe le persone (o gruppi) alla richiesta pull e richiedi a entrambi di firmarlo prima che possa essere completato. Una volta che entrambi hanno firmato, uniscilo. La seconda persona viene avvisata del PR prima che il primo si sia disconnesso, in modo che stiano guardando un PR che non è "pronto per loro". Se i tuoi PR sono solitamente rifiutati o richiedono molte modifiche, questo potrebbe essere un problema, ma non dovrebbe esserlo.

La seconda opzione ha più senso per me, in quanto non vi è alcuna possibilità che il ramo venga accidentalmente unito prima che entrambi i PR siano stati completati.

    
risposta data 23.08.2017 - 17:45
fonte
3

Bitbucket ha una funzione politica che può applicare due livelli di revisione senza modifiche al processo:

The easiest policy is to enforce that a few people look at the new feature or bug fix before it's merged. For example, many teams decide that a pull request can only be merged if at least two developers have reviewed and approved the code. Your team may want to set an upper limit on the number of reviewers to prevent slowing down the progress too much but it's often useful to invite more reviewers than the minimum approval limit so that the progress on the review is not stalled by busy team members

Questo può essere implementato aggiornando:

If your team has a Premium plan, repository admins can prevent pull requests that don't have a certain number of approvals from merging.

o installando un plug-in che convalida i commit:

Commit Policy Plugin checks the changes committed to Bitbucket Server repositories against a set of configurable rules (the commit policy). It does so by integrating the Commit Policy Plugin for Jira with Bitbucket Server. When the policy is not satisfied, the commit is rejected. Rejected commits can then be "fixed" and re-committed.

Riferimenti

risposta data 10.04.2018 - 18:50
fonte

Leggi altre domande sui tag