Strutturazione repository e pipeline CI/CD per WebPart SPFx

Question

Strutturazione repository e pipeline CI/CD per WebPart SPFx

Rosamartina Milazzo 10

Buongiorno,

sto attualmente sviluppando WebPart SPFx per un unico sito SharePoint. Nel repository di sviluppo ho:

Una libreria SPFx condivisa
Sei WebPart distinte, ognuna in una propria soluzione, organizzate così:

- libreria
- webparts
   - webpart1
   - webpart2
   - webpart3
   ...

Per il momento, su Azure DevOps, tutto è gestito in un unico repository. Per buildare e deployare una WebPart, seguo il flusso: verifico le differenze su Git, buildo la WebPart e poi la deployo.

Sto valutando se, per la pipeline CI/CD, sia più efficiente adottare un repository separato per ogni WebPart, così da avere pipeline indipendenti per ciascuna soluzione.

In questo scenario, mi sorgono due domande principali:

È considerata una best practice separare le WebPart in repository distinti?
Come andrebbe gestita la libreria SPFx condivisa in questo caso? Presumo che debba avere un repository separato, ma vorrei conferma sulle modalità migliori di integrazione con le WebPart.

Grazie per il vostro supporto.

0 commenti

2 risposte

Risposta

Answer 1

Rosamartina Milazzo 10

@Teddie-D
Grazie per la risposta e per il riepilogo dei pro e contro del monorepo, che mi sono chiari.Il mio problema è nato nel momento in cui ho introdotto le pipeline CI/CD: avendo un unico repository con 6 WebPart diverse, per decidere quale buildare e rilasciare dovevo basarmi sulle differenze di Git, e questo approccio mi è risultato poco pratico. Da qui ho iniziato a considerare una struttura multi-repo, in cui ogni WebPart abbia la propria pipeline dedicata di build e release, in modo da semplificare il flusso.

In quest’ottica, quale sarebbe considerata la best practice? E aggiungo un secondo dubbio: attualmente la mia libreria SPFx condivisa è linkata nelle varie WebPart. Con una struttura a repository separati, temo che la gestione di questa dipendenza diventi più complicata. Qual è il modo consigliato di affrontare questo scenario?

Teddie-D 19,760 Punti di reputazione Personale Esterno Microsoft Moderatore

2025-09-18T14:50:54.5166667+00:00

Ciao @Rosamartina Milazzo
Grazie per la tua risposta tempestiva.
In base al tuo commento sulle difficoltà nel controllare manualmente le differenze in Git, suggerirei di considerare un'impostazione monorepo con filtri di percorso prima di passare a una struttura multi-repo. Questo approccio è generalmente più semplice e può aiutare a ridurre la complessità nella gestione delle librerie condivise tra i repository.

Tuttavia, questa raccomandazione si basa sulla mia ricerca personale piuttosto che su un’esperienza diretta. Per ottenere indicazioni più accurate e pratiche, ti consiglio di aprire una nuova discussione nella community degli sviluppatori SharePoint. Questo aiuterà a evitare ritardi e garantirà che la soluzione sia adatta al tuo caso specifico.

In definitiva, non esiste una risposta valida per tutti. Vale la pena sperimentare entrambe le strategie e perfezionare l’approccio man mano che il tuo codice e il tuo team evolvono.

Grazie per la comprensione.
Teddie-D 19,760 Punti di reputazione Personale Esterno Microsoft Moderatore

2025-09-22T02:49:46.7033333+00:00

Ciao @Rosamartina Milazzo
Posso sapere se ha avuto modo di controllare la mia risposta? Se ha bisogno di ulteriore assistenza, non esiti a farmelo sapere. Grazie!
Teddie-D 19,760 Punti di reputazione Personale Esterno Microsoft Moderatore

2025-09-24T09:49:18.0233333+00:00

Ciao @Rosamartina Milazzo
Ci sono aggiornamenti da parte vostra?
In caso affermativo, non esitate a farcelo sapere.
Rosamartina Milazzo 10 Punti di reputazione

2025-10-24T14:21:13.4833333+00:00

Buongiorno @Teddie-D , mi scusi se leggo solo ora la risposta.

Non mi è del tutto chiaro cosa intenda con “impostazione monorepo con filtri di percorso prima di passare a una struttura multi-repo”. Potrebbe gentilmente spiegarmelo meglio?

Nel mio caso la pipeline utilizza delle variabili per tutte le WebPart e, tramite un ciclo for, ognuna viene impacchettata a turno. Quello che vorrei ottenere, invece, è un comportamento più automatico: al commit e alla sincronizzazione, solo la WebPart effettivamente modificata dovrebbe essere impacchettata e poi distribuita.

Come accennavo in precedenza, al momento l’unico modo che ho trovato per ottenere questo risultato è verificando le differenze su Git oppure separando i progetti in più repository, così che ogni WebPart abbia la propria pipeline dedicata.

Grazie ancora per il tempo e la disponibilità.
Teddie-D 19,760 Punti di reputazione Personale Esterno Microsoft Moderatore

2025-10-27T06:15:48.37+00:00

Questa risposta è stata tradotta automaticamente. Di conseguenza, potrebbero esserci errori grammaticali o espressioni strane.
Ciao @Rosamartina Milazzo
Utilizzare i filtri di percorso in una configurazione monorepo consente di semplificare le pipeline CI/CD attivando le build solo per i componenti che sono stati modificati. Questo elimina la necessità di una logica complessa di Git diff o della ricostruzione dell'intera soluzione ogni volta. In una monorepo SPFx tipica, tutte le WebPart e le librerie condivise risiedono in un unico repository. Invece di eseguire il ciclo su ogni WebPart per ogni commit, è possibile configurare la pipeline (ad esempio, in Azure DevOps o GitHub Actions) per rispondere solo alle modifiche in cartelle specifiche. Ad esempio, se un commit modifica i file sotto webparts/webpart3, verrà eseguita solo la pipeline per WebPart3, riducendo il tempo di build e l'utilizzo delle risorse. Allo stesso modo, le modifiche nella cartella libreria possono attivare una pipeline dedicata alla libreria condivisa.

Se il progetto in seguito evolve fino a richiedere team separati, cicli di rilascio differenti o controlli di accesso più rigorosi, allora la transizione a una struttura multi-repo con un pacchetto npm privato per la libreria condivisa diventa più appropriata. Questo garantisce pipeline e versioning indipendenti pur continuando a condividere funzionalità comuni tramite un pacchetto centralizzato.

Rosamartina Milazzo 10

Ciao @Teddie-D , scusami se leggo solo adesso la risposta.

Non mi è chiarissimo cosa intendi per “filtri di percorso”. Io al momento ho questa struttura di cartelle
📁 repository-root

│

├── 📁 source-custom-webparts

│ ├── 📁 allegati-fattura

│ ├── 📁 associazione-prescrizioni

│ ├── 📁 clienti

│ ├── 📁 contratti

│ ├── 📁 dashboard

│ ├── 📁 gestione-incarichi

│ ├── 📁 scheda-incarico

│ └── 📄 .yo-rc.json

│

└── 📁 source-shared-library

e la mia pipeline YAML è configurata così:

trigger:
- develop
- staging
- main

pool:
  vmImage: 'ubuntu-latest'

parameters:
  - name: webparts
    type: object
    default:
      - allegati-fattura
      - associazione-prescrizioni
      - clienti
      - contratti
      - dashboard
      - gestione-incarichi
      - scheda-incarico

# Stage di build 
stages:
- ${{ each webpart in parameters.webparts }}:
  - stage: Build_${{ replace(webpart, '-', '_') }}
    displayName: Build - ${{ webpart }}
    jobs:
    - job: Build
      steps:
      - task: NodeTool@0
        inputs:
          versionSpec: '8.17'

      - script: |
          cd source-shared-library
          npm install
          npm run build 
        displayName: 'Build library'

      - script: |
          cd source-shared-library
          npm link
          cd ../source-custom-webparts/${{ webpart }}
          npm install
          npm link source-shared-library
        displayName: 'Build webpart'

      - script: |
          cd source-custom-webparts/${{ webpart }}
          npx gulp build
        displayName: 'Execute gulp build task'

      - script: |
          cd source-custom-webparts/${{ webpart }}
          npx gulp bundle --ship --verbose
        displayName: 'Execute gulp bundle task'

      - script: |
          cd source-custom-webparts/${{ webpart }}
          npx gulp package-solution --ship
        displayName: 'Execute gulp package-solution task'

      - task: CopyFiles@2
        displayName: 'Copy sppkg-file to artifact staging directory'
        inputs:
          Contents: |
            source-custom-webparts/${{ webpart }}/sharepoint/**/*.sppkg          
          TargetFolder: '$(Build.ArtifactStagingDirectory)'
          flattenFolders: true

      - task: PublishBuildArtifacts@1
        displayName: 'Publish artifacts'
        inputs:
          artifactName: '${{ webpart }}'
          PathtoPublish: '$(Build.ArtifactStagingDirectory)'

Potresti spiegarmi meglio come funzionano e dove vanno configurati questi “filtri di percorso”?

Teddie-D 19,760 Punti di reputazione Personale Esterno Microsoft Moderatore

2025-10-28T07:45:28.7233333+00:00
Questa risposta è stata tradotta automaticamente. Di conseguenza, potrebbero esserci errori grammaticali o espressioni strane.
Ciao @Rosamartina Milazzo
I filtri di percorso nei sistemi CI/CD (Azure DevOps, GitHub Actions) permettono di attivare una pipeline solo quando vengono modificati file in cartelle specifiche.
Invece di eseguire tutte le fasi ad ogni commit, puoi definire regole come:
-Se ci sono modifiche in source-custom-webparts/attachments-invoice/** > esegui la pipeline per quel WebPart.
-Se ci sono modifiche in source-shared-library/** > esegui la pipeline per la shared library.
Questo approccio elimina la necessità di ciclare su tutti i WebPart o controllare manualmente i diff di Git.
In Azure DevOps, i filtri di percorso si definiscono nella sezione trigger del file YAML della pipeline, ad esempio:

trigger: branches: include: - develop - staging - main paths: include: - source-custom-webparts/attachments-invoice/**

Questa configurazione assicura che la pipeline venga eseguita solo quando vengono modificati file all'interno della cartella attachments-invoice nei branch specificati.

Answer 2

Ciao @Rosamartina Milazzo

Questa risposta è stata tradotta automaticamente. Di conseguenza, potrebbero esserci errori grammaticali o espressioni strane.

Grazie per aver pubblicato la tua domanda nel forum Microsoft Q&A.

Poiché il tuo problema riguarda SPFx, ti consiglio di contattare lo SharePoint Developer | Microsoft Community Hub, dove ci sono sviluppatori professionisti che possono affrontare e assisterti in modo più efficiente.

Tuttavia, farò del mio meglio per aiutarti in base a quanto hai condiviso. Ecco alcune informazioni che ho trovato, puoi prenderle come riferimento.

1.È considerata una best practice separare i WebPart in repository separati?

Quando si decide come scalare e gestire i WebPart, la scelta tra un approccio monorepo e multi-repo dipende dalla struttura del team, dalle esigenze di distribuzione e dalla manutenibilità:

Monorepo (repository singolo)

-Vantaggi:

Più facile mantenere script di build/config condivisi.
Più semplice gestire modifiche e revisioni tra WebPart.
Le librerie condivise possono essere collegate localmente.
Una singola pipeline può essere ottimizzata per costruire solo i WebPart interessati usando i filtri di percorso.

-Svantaggi:

Il repository cresce nel tempo e le pipeline possono rallentare senza un'adeguata ottimizzazione.

Multi-repo (repository separati per ciascun WebPart)

-Vantaggi:

Isolamento chiaro, con ogni WebPart che ha il proprio ciclo di vita e pipeline.
I team possono lavorare in modo indipendente.
Le pipeline CI/CD sono più veloci e semplici per ogni WebPart.

-Svantaggi:

Le dipendenze condivise devono essere versionate e pubblicate separatamente.
Le modifiche trasversali richiedono più tempo.
Maggiore overhead nella gestione di più repository.

Dal mio punto di vista, poiché tutti i tuoi WebPart sono destinati a un singolo sito SharePoint e il codice è già in un repository, un approccio monorepo è il più pratico. Si allinea con la tua configurazione attuale e minimizza la complessità mantenendo la collaborazione e l'automazione semplificate.

2.Come dovrebbe essere gestita la libreria SPFx condivisa in questo caso?

-Se scegli una struttura multi-repo, la libreria SPFx condivisa dovrebbe essere collocata in un proprio repository. Questo consente una corretta gestione delle versioni e delle dipendenze tramite pacchetti npm privati. Ciò consente il riutilizzo tra più WebPart senza costringerli tutti ad aggiornarsi contemporaneamente.
Riferimento: CI/CD with SharePoint Framework (SPFx) - Developer Support

-In una configurazione monorepo, puoi mantenere la libreria condivisa accanto ai tuoi WebPart e utilizzare npm workspaces per gestire le dipendenze. Questo evita la necessità di pubblicazione ma sacrifica i confini di versione rigorosi. Questo semplifica lo sviluppo e CI/CD, anche se sacrifica i confini di versione rigorosi.
Puoi fare riferimento a: Scaling SPFx Projects with NPM Workspaces - How to Manage Multiple Solutions Efficiently
Nota: Microsoft fornisce queste informazioni come comodità per l'utente. I siti non sono controllati da Microsoft. Microsoft non può fornire alcuna garanzia riguardo alla qualità, sicurezza o idoneità di qualsiasi software o informazione presente su tali siti. Assicurati di comprendere completamente i rischi prima di accettare qualsiasi suggerimento dal link sopra indicato.

Spero che questo ti aiuti a decidere la struttura giusta per le tue soluzioni SPFx!

Se la risposta è utile, fai clic su "Accetta risposta" e gentilmente votala positivamente. Se hai ulteriori domande su questa risposta, fai clic su "Commenta".

Nota: Segui i passaggi nella nostra documentazione per abilitare le notifiche e-mail se desideri ricevere la notifica e-mail relativa a questo thread.