Codice funzione + codice infrastruttura: come strutturare i problemi di commit / JIRA?

Nella mia esperienza, il modo migliore è assegnare i commit all'unico Jira-Ticket che ha causato la modifica. La ragione di ciò risiede nel modo in cui utilizzo la cronologia dei repository: ogni volta che non sono sicuro di un pezzo di codice, consulta la cronologia dei repository per scoprire perché questo cambiamento è stato fatto ), o chi era responsabile (autore) di chiedere a lui / lei f2f. Nel tuo esempio, sarebbe chiaro dalla cronologia dei repository e dal ticket Jira da solo perché è stato necessario introdurre l'anno.

Ho scritto 'commit (s)' perché per me è totalmente ammissibile fare diversi commit in base a un ticket. Per questo motivo uso il numero di ticket come prefisso del commit-comment.

Inoltre, per me il sovraccarico di creare nuove sottoattività e fare l'intero ciclo di vita di Jira con loro sarebbe troppo grande.

Dato che stai utilizzando JIRA, considera la guida autorevole fornita nella sua documentazione.

Il caso d'uso che descrivi è destinato ad essere indirizzato da sotto-attività, che lo scopo è descritto come segue :

Sub-task issues are useful for splitting up a parent issue into a number of smaller tasks that can be assigned and tracked separately. This can provide a better picture of the progress on the issue, and allows each person involved in resolving the issue to better understand what part of the process they are responsible for...

Ho usato molto questa funzione, per gli scopi come hai descritto (codifica il codice con diversi aspetti relativi ad alcune richieste di bugfix / funzionalità) e, secondo la mia esperienza, funzionavano molto bene.

Una complicazione relativamente minore che incontro spesso, e che potresti trovare anche da tenere a mente, è anche indicata nella documentazione delle sotto-attività di JIRA, insieme a una guida su come gestirla:

Sub-tasks cannot have sub-tasks of their own. However, if you need to break up a sub-task into smaller sub-tasks, you could achieve this by first converting the sub-task to a standard issue. You would then be able to create sub-tasks for it.

Per quanto riguarda i commit, quando usi sotto-attività hai bisogno di scoprire in che modo ti senti più comodo per tentativi ed errori. Non esiste una soluzione adatta a tutti qui. Tale sperimentazione con vari approcci potrebbe essere piuttosto indolore se l'integrazione VCS / JIRA consente di modificare il messaggio di commit e ricaricare il repository.

• ^{Nota a margine qualsiasi plugin VCS / JIRA decente dovrebbe consentirtelo. Se non lo fai, prova a passare a uno migliore, perché con esso avresti problemi molto più difficili dell'assegnazione ottimale, qualsiasi errore di digitazione nel messaggio di commit ( feature #12 invece di #123 , o mancante # ) romperebbe le cose male .}

Nella mia esperienza, la "mappatura naturale" dei commit alle rispettive sotto-attività è stata in genere conveniente.

Se la tua integrazione supporta più di un ID di problema nel messaggio di commit, questo ti offre ulteriori opzioni per sperimentare. Ad esempio, in alcuni casi era più conveniente fornire coppia / ID sotto-attività di ID nei messaggi di commit (ho usato Fisheye ), come

• commit per la prima attività secondaria vai come
  parent #123 sub-task #124
• commit per la seconda attività secondaria vai come
  parent #123 sub-task #125
• ecc ...

In questo modo, i commit specifici del sottoattività sono visibili nelle sottoattività, mentre il problema del genitore visualizza tutti i commit. Questo è stato utile raramente, tuttavia, nella maggior parte delle questioni trattate, la mappatura semplice delle sotto-attività era sufficiente.