Puncte:1

Cum să gestionați conductele în mai multe ramuri, în devops azure?

drapel cn

Să presupunem că am branch fetaure1, unde există fișierul pipeline.

Declanșatorul va fi așa.

declanșator:
   - caracteristica 1

În scopul dezvoltării, am creat o nouă ramură din ea, spune (feature1_deveoper1)

Dar, chiar dacă această nouă ramură are acest fișier pipeline, trebuie să îl modificați din nou pentru a activa declanșatorul.

declanșator:
   - caracteristica 1
   - feature1_developer1

Deci, după toată munca mea, să presupunem că vreau să fuzionez cu ramura feature1, din nou trebuie să elimin această nouă intrare de caracteristică și să o îmbin cu ramura.

O abordare mai bună pentru această situație?

Puncte:0
drapel cn

Ei bine, știu că toată lumea are fluxuri de lucru diferite, dar într-un model de utilizare git mai tradițional, cum ar fi gitflow, nu ați configura CI se bazează pe ramuri de caracteristici scurte.

Desigur, fiecare dezvoltator ar face o ramificare a unei caracteristici dintr-o ramură, cum ar fi să spunem dezvolta. Ei ar lucra la caracteristică local. Când termină, ei fac un PR, iar acesta este fuzionat înapoi în ramura ta mai mare -- să zicem develop or release sau main sau orice altceva.

În acest fel, secțiunea declanșatoare trebuie să aibă doar numele ramurilor principale (de lungă durată).

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.