73 lines
8.2 KiB
Plaintext
73 lines
8.2 KiB
Plaintext
https://gitled.leonardocompany.com/git/ELEITA/Software/
|
|
└── S1001821_GRIFO-E/ (GRIFO-E REP SW Program Package)
|
|
├── S1001821_GRIFO-E.git (Codice sorgente comune/Dati di progetto - NON per i singoli tool, ma per dati trasversali)
|
|
├── S1001821_GRIFO-E_DOCS.git (Documentazione di progetto)
|
|
├── S1001823_GRIFO-E_REP_DSP_SW_CSCI.git (Codice sorgente CSCI "DSP")
|
|
├── S1001823_GRIFO-E_REP_DSP_SW_CSCI_DOCs.git (Documentazione CSCI "DSP")
|
|
├── S1001823_GRIFO-E_REP_DSP_SW_CSCI_TESTs.git (Verifica CSCI "DSP")
|
|
├── S1001824_GRIFO-E_REP_EIF_SW_CSCI.git (Codice sorgente CSCI "EIF")
|
|
├── S1001824_GRIFO-E_REP_EIF_SW_CSCI_DOCs.git (Documentazione CSCI "EIF")
|
|
├── S1001824_GRIFO-E_REP_EIF_SW_CSCI_TESTs.git (Verifica CSCI "EIF")
|
|
├── S1001825_GRIFO-E_REP_DFE_SW_CSCI.git (Codice sorgente CSCI "DFE")
|
|
├── S1001825_GRIFO-E_REP_DFE_SW_CSCI_DOCs.git (Documentazione CSCI "DFE")
|
|
├── S1001825_GRIFO-E_REP_DFE_SW_CSCI_TESTs.git (Verifica CSCI "DFE")
|
|
├── S100XXXXX_GRIFO-E_COMMON_LIB.git (Codice sorgente librerie)
|
|
|
|
https://gitled.leonardocompany.com/git/ELEITA/Software/
|
|
└── S1002726_PPS/ (GRIFO-E Primary Power Supply SW)
|
|
├── S1002726_PPS.git (Codice sorgente comune/Dati di progetto - NON per i singoli tool, ma per dati trasversali)
|
|
├── S1002726_PPS_DOCS.git (Documentazione di progetto)
|
|
├── S1003065_GRIFO-E_PPS_TX_BOARD_SW_CSCI.git (Codice sorgente CSCI "PPS_TX_BOARD_SW")
|
|
├── S1003065_GRIFO-E_PPS_TX_BOARD_SW_CSCI_DOCs.git (Documentazione CSCI "PPS_TX_BOARD_SW")
|
|
├── S1003065_GRIFO-E_PPS_TX_BOARD_SW_CSCI_TESTs.git (Verifica CSCI "PPS_TX_BOARD_SW")
|
|
├── S1002726_GRIFO-E_PPS_RX_BOARD_SW_CSCI.git (Codice sorgente CSCI "PPS_RX_BOARD_SW")
|
|
├── S1002726_GRIFO-E_PPS_RX_BOARD_SW_CSCI_DOCs.git (Documentazione CSCI "PPS_RX_BOARD_SW")
|
|
├── S1002726_GRIFO-E_PPS_RX_BOARD_SW_CSCI_TESTs.git (Verifica CSCI "PPS_RX_BOARD_SW")
|
|
├── S1003471_GRIFO-E_PPS Maintenance_Monitor_CSCI.git (Codice sorgente CSCI "PPS Maintenance_Monitor")
|
|
├── S1003471_GRIFO-E_PPS Maintenance_Monitor_CSCI_DOCs.git (Documentazione CSCI "PPS Maintenance_Monitor")
|
|
├── S1003471_GRIFO-E_PPS Maintenance_Monitor_CSCI_TESTs.git (Verifica CSCI "PPS Maintenance_Monitor")
|
|
|
|
https://gitled.leonardocompany.com/git/ELEITA/Software/
|
|
└── S1002725_PSM/ (GRIFO-E Power Supply SW)
|
|
├── S1002725_PPS.git (Codice sorgente comune/Dati di progetto - NON per i singoli tool, ma per dati trasversali)
|
|
├── S1002725_PPS_DOCS.git (Documentazione di progetto)
|
|
├── S1003612_GRIFO-E_PSM Monitor_CSCI.git (Codice sorgente CSCI "PSM Monitor")
|
|
├── S1003612_GRIFO-E_PSM_Monitor_CSCI_DOCs.git (Documentazione CSCI "PSM Monitor")
|
|
├── S1003612_GRIFO-E_PPS_Monitor_CSCI_TESTs.git (Verifica CSCI "PSM Monitor")
|
|
|
|
https://gitled.leonardocompany.com/git/ELEITA/Software/
|
|
└── S000<da decidere>_GRIFO-E-TOOLS/ IMPORTANTE - (CSCI - da mettere come placeholder che poi verrà usato per PLM quando sarà necessario)
|
|
├── S1006001_CPP_PYTHON_DEBUG.git (Codice sorgente CSCI "CPP_Python_Debug")
|
|
├── S1006001_CPP_PYTHON_DEBUG_DOCs.git (Documentazione CSCI "CPP_Python_Debug" - opzionale)
|
|
├── S1006001_CPP_PYTHON_DEBUG_TESTs.git (Verifica CSCI "CPP_Python_Debug" - opzionale)
|
|
├── S1006002_RADAR_DATA_READER.git (Codice sorgente CSCI "RADAR_DATA_READER")
|
|
├── S1006002_RADAR_DATA_READER_DOCs.git (Documentazione CSCI "RADAR_DATA_READER" - opzionale)
|
|
├── S1006002_RADAR_DATA_READER_TESTs.git (Verifica CSCI "RADAR_DATA_READER" - opzionale)
|
|
|
|
questa è la struttura che avevo pensato per dare un'organizzazionA
|
|
Per le particomuni come la famosa DEV che abbiamo su SVN si potrebbe risolvere con la funzionalità di submodules.
|
|
Qui una spiegazione abbastanza esaustiva su come dovrebbe funzionare:
|
|
|
|
2. Gestione delle Librerie Comuni con Git Submodules
|
|
Per le librerie comuni utilizzate dai tuoi CSCI (DSP, DFE, EIF) e la necessità di tracciare le modifiche in modo indipendente, la soluzione più indicata e supportata dalle linee guida aziendali è l'utilizzo dei Git Submodules.
|
|
• Creazione di un Repository Dedicato per la Libreria Comune:
|
|
◦ Invece di includere il codice della libreria comune direttamente in S1001821_GRIFO-E.git (che è più per dati trasversali), è fortemente consigliato creare un repository Git separato per la tua libreria comune. Questo la rende una componente autonoma e riutilizzabile, con la sua storia di versioni indipendente.
|
|
◦ Il nome del repository dovrebbe seguire le convenzioni, ad esempio: S100XXXXX_GRIFO-E_COMMON_LIB.git, dove S100XXXXX è un IBC (Base Code) dedicato alla libreria, e GRIFO-E_COMMON_LIB il nome mnemonico. Questo repository dovrebbe risiedere sotto la stessa URLroot (https://gitled.leonardocompany.com/git/ELEITA/Software/).
|
|
◦ La creazione e gestione di questo nuovo repository sarà di competenza dell'SCMAdmin .
|
|
• Integrazione come Submodule nei CSCI:
|
|
◦ Ogni repository CSCI (DSP, EIF, DFE) che utilizza questa libreria comune la includerà come un submodule. Questo significa che la libreria comune apparirà come una sottodirectory all'interno del repository di ciascun CSCI.
|
|
◦ I comandi base per gestire un submodule sono git submodule add [URL del repository della libreria] per aggiungerla, e git submodule init e git submodule update (o git clone --recurse-submodules in fase di clonazione iniziale) per inizializzare e scaricare il contenuto del submodule.
|
|
◦ Il file .gitmodules nel repository principale del CSCI terrà traccia dell'URL della libreria e del percorso locale.
|
|
3. Tracciabilità delle Modifiche e Versionamento Specifico
|
|
La esigenza di "tenere traccia che una determinata modifica della libreria è collegata ad una particolare versione della DFE, e non perdere il fatto che EIF e DSP continuano ad usare la versione precedente" è la caratteristica principale e il grande vantaggio dei Git Submodules in questo scenario:
|
|
• Referenziamento a un Tag Specifico: Le linee guida di Leonardo Electronics richiedono esplicitamente che i submodule siano basati unicamente su un TAG della libreria di riferimento ( "Submodule shall be done only from a TAG") . Questo è cruciale perché un tag in Git è una etichetta che identifica in modo univoco e immutabile un set di file a un determinato momento di commit.
|
|
• Workflow per le Modifiche alla Libreria:
|
|
1. Quando un team (ad esempio, quello della DFE) necessita di una nuova funzionalità o di una correzione nella libreria comune, un SCMOwner (o uno SCMUser che poi riceverà le modifiche per l'integrazione) lavorerà direttamente all'interno del repository della libreria comune.
|
|
2. Dopo aver sviluppato e testato le modifiche, queste verranno committate nel repository della libreria comune.
|
|
3. L'SCMOwner della libreria comune dovrà creare un nuovo tag annotato per questa versione modificata della libreria (es., LIB_COMMON_V1.1_DFE_FEATURE). Il messaggio del tag dovrebbe descrivere la ragione della modifica [99, 274, GIT-36].
|
|
4. Questo nuovo tag verrà poi pubblicato nel Remote Repository della libreria comune (operazione riservata all'SCMOwner) .
|
|
5. A questo punto, il team della DFE, nel proprio repository CSCI, aggiornerà il riferimento del submodule per puntare a questo nuovo tag LIB_COMMON_V1.1_DFE_FEATURE. Questo aggiornamento sarà un commit nel repository DFE stesso.
|
|
6. Il team della DFE potrà quindi spingere (push) le proprie modifiche, e il loro CSCI utilizzerà la nuova versione della libreria.
|
|
• Preservazione delle Versioni per altri CSCI:
|
|
◦ I team EIF e DSP, non avendo aggiornato il riferimento al submodule nei loro repository, continueranno a utilizzare la versione precedente della libreria comune a cui puntava il loro submodule.
|
|
◦ Quando i team EIF o DSP decideranno di integrare le nuove funzionalità della libreria comune, dovranno aggiornare manualmente il riferimento del loro submodule al tag più recente che desiderano utilizzare, e committare questo cambiamento nel loro rispettivo repository CSCI. |