Sono impegnato a implementare un processo di gestione delle modifiche perché abbiamo un ambiente complesso e qui c'è troppa tradizione orale.
Come punto di partenza, voglio creare un elenco di elementi di configurazione. A quanto ho capito, un elemento di configurazione (software) è qualcosa che in seguito a una modifica attiverà la rigenerazione del software. Ad esempio, nel nostro caso, se un server desktop remoto o un server applicazioni viene spostato e il suo nome DNS cambia, è necessario aggiornare la nostra configurazione software. Pertanto, l'hardware del server fa parte dell'elenco degli elementi di configurazione.
Quale era il mio problema (e ora sto cercando ulteriori conferme) come rappresentare gli elementi di aggregazione aggregati. Ma suppongo che si inizi con gli elementi di base della configurazione, dando loro una designazione univoca, e poi costruendo elementi di aggregazione aggregati facendo riferimento a queste esclusive designazioni.
Quando vorresti aggiungere il controllo di versione ai CI? Per esempio. è probabilmente possibile descrivere un determinato sottoprogramma come composto (ambiente VS qui) o descritto da un file di soluzione, un file di progetto, i file di configurazione sottostanti e file C # (e possibilmente altri file). Ma aggiungere versioni (o commit, usando git) sarebbe probabilmente troppo dettagliato qui. D'altra parte, le parti usate (come la versione C # o la versione di SQL Server) verrebbero probabilmente specificate come versioni qui, poiché non cambiano spesso e, se cambiano, il sistema entra probabilmente in un nuovo stato.
E poi ci sono strumenti: questi sono aggiunti agli IC solo per completezza o no? Usiamo JIRA, Bitbucket, Bamboo e Confluence, ma durante l'aggiornamento non riesco a vedere questo cambiamento del software di attivazione, ma ovviamente potrebbe cambiare il processo CM. O gli strumenti sono stati aggiunti all'elenco AND degli elementi della configurazione? Hm, sarebbe importante semplicemente aggiungere uno strumento, dargli una designazione CI e quindi solo elencarlo come uno strumento utilizzato, anche se non fa parte di un CI aggregato?
Suppongo che l'attuale piano SCM debba anche essere interpretato come un elemento di configurazione aggregato e che un cambiamento ambientale di uno strumento (anche un aggiornamento non suscettibile) attiverà una nuova versione di questo documento, solo per assicurarsi che tale cambiamento è rappresentato.
Se questo sembra un po 'confuso, è perché è così. Sto cercando di fare head and tail di questo, e sto pensando mentre scrivo la domanda, e ci sono alcuni documenti sul processo CM, ma non veri e propri esempi pratici.