Inner Source, spesso stilizzato come InnerSource, si riferisce all'adozione di processi e metodologie di sviluppo open source all'interno di un'organizzazione. Considerando che “open source” implica la creazione di strumenti disponibili pubblicamente, fonte interna significa che stai lavorando su progetti interni utilizzando approcci derivati aperti.
I flussi di lavoro open source facilitano la collaborazione facile e l'iterazione rapida. I problemi pubblicamente accessibili e le richieste di unione su piattaforme come GitHub consentono a chiunque di contribuire a un progetto. I bug vengono scoperti e corretti in modo rapido, sicuro e trasparente in un ambiente che favorisce discussioni regolari tra manutentori e utenti.
Questo modello è in netto contrasto con il modo in cui il software viene sviluppato all'interno delle grandi organizzazioni. In questi ambienti, gli strumenti sono sviluppati ad hoc dai singoli team. Le persone lavorano in silos, contribuendo alle proprie aree individuali, ignare del lavoro sovrapposto che sta svolgendo altrove.
Introduzione a Inner Source
Il movimento della fonte interna applica le lezioni apprese dallo sviluppo open source ai progetti interni di un'organizzazione. Sostiene di rendere tutto il codice visibile a tutti, creando una cultura più aperta in cui i team possono trovare progetti esistenti che potrebbero essere utili anche per il loro lavoro, quindi contribuire con i propri miglioramenti.
In molte organizzazioni, i nuovi repository di sorgenti saranno essere limitato alle sole persone che hanno bisogno di lavorarci. Adottare un modello sorgente interno significa rendere tutto visibile per impostazione predefinita. Ciò incoraggia i membri del team a esplorare l'intero corpus di codice dell'organizzazione e fornire input alle discussioni, anche se il progetto non è strettamente all'interno della loro area tematica.
Pubblicità
La sorgente interna non riguarda solo il codice. Può essere esteso per includere risorse e documentazione più ampie relative all'azienda, alle sue operazioni e al suo software. L'obiettivo è consentire alle persone di selezionare autonomamente le attività e contribuire con la propria esperienza laddove ritengono che possa avvantaggiare l'organizzazione, anche se vengono assunte in una specifica area di interesse.
Vantaggi della fonte interiore
I sostenitori della “fonte interna” Le architetture rilevano diversi vantaggi significativi dell'approccio, tra cui riduzione degli sprechi, tempi di avvio accelerati, meno tensione tra i team e migliore qualità del codice. Questi si combinano per migliorare la produttività dell'organizzazione e la cultura del posto di lavoro.
- Riduzione degli sprechi, migliore riutilizzo– Le grandi organizzazioni possono finire per duplicare codice simile su più progetti di proprietà di team diversi. Se i team non si parlano, il fatto che ora hai tre librerie di memorizzazione nella cache simili potrebbe passare inosservato. La pubblicazione di tutto il codice internamente avviserà gli altri della presenza di strumenti consueti, quindi incoraggerà l'iterazione condivisa su un'unica base di codice. La ruota smette di essere reinventata, mantenendo tutti al lavoro e accelerando i tempi di lancio.
- Miglioramento della qualità del codice– Il codice scritto allo scoperto è più esposto, quindi è probabile che i bug appaiano prima nel processo di sviluppo. Se una libreria condivisa viene adottata da un nuovo team, potrebbero emergere problemi che prima non erano stati notati. L'implementazione delle correzioni andrà a beneficio di tutti i progetti che utilizzano la libreria.
- Meno tensione tra i team– Sebbene all'inizio il passaggio a un modello aperto possa sembrare scomodo, lo sviluppo della fonte interna ha lo scopo di abbattere le barriere e migliorare la collaborazione. Lo sviluppo chiuso può creare situazioni difficili quando trovi che un team vicino ha creato una versione migliore di una libreria che stavi utilizzando. In un modello aperto, questo viene risolto iterando insieme su una base di codice condivisa che include le funzionalità necessarie per l'intero gruppo.
Il sorgente interno appiattisce la struttura organizzativa, offrendo a tutti gli sviluppatori la stessa visione lavori in corso. Accettare contributi dall'esterno del team che “possiede” un progetto fornisce l'accesso a occhi nuovi e un pool ampliato di soluzioni.
Implementazione di un flusso di lavoro di origine interna
Nella sua forma più semplice, la fonte interna viene implementata accedendo alla piattaforma di controllo della versione e modificando la visibilità dei progetti da Privato a Interno. In pratica, avrai bisogno di un piano più ponderato di questo se vuoi introdurre con successo il modello sorgente interno in un ambiente di squadra esistente.
Ci sono due aspetti fondamentali in ogni transizione: comunicazione e strumenti. Il primo si riferisce alla formazione dei membri del team su ciò che sta accadendo e su come potranno contribuire ai progetti aperti. “Impostare e dimenticare” i livelli di accesso saranno inefficaci in quanto le persone non saranno consapevoli delle loro nuove abilità e di quando potranno essere utilizzate.
Il secondo aspetto, gli strumenti, implica la selezione di utilità software appropriate per gestire il flusso di lavoro aperto. Un team di software funzionante probabilmente utilizzerà già una forma di controllo della versione, come GitOps, per gestire il proprio codice. Tuttavia, i modelli di utilizzo precisi potrebbero variare notevolmente all'interno dell'organizzazione.
Pubblicità
La fonte interna richiede un modello di sviluppo unificato che funzionerà in modo coerente in tutti i progetti. Ciò significa utilizzare al massimo le funzionalità di Git e della tua piattaforma di hosting, come GitHub o GitLab.
I contributori dovrebbero essere in grado di inviare modifiche in una richiesta pull che i manutentori poi esamineranno e uniranno. Le richieste pull devono essere integrate da una suite di test di superamento che viene eseguita in una pipeline CI. Ciò dà al team di manutenzione la certezza che la modifica è efficace e garantisce che tutto il codice soddisfi gli stessi standard. Rendere la base di codice auto-verifica attraverso test e controlli automatizzati aiuta a rimuovere l'attrito dall'esperienza.
Dovresti anche considerare come le risorse di supporto come la documentazione e gli elenchi di problemi vengono archiviate ed esposte. Creare un wiki del team aperto per documenti API e riferimenti all'architettura; assicurati che tutti i bug e le richieste di funzionalità siano tracciati in una posizione centrale. Ciò consentirà alle persone di tutta l'organizzazione di trovare le informazioni di cui hanno bisogno. Consente inoltre alle persone di fornire miglioramenti a progetti arbitrari in periodi più tranquilli – chiunque può trovare segnalazioni di bug e iniziare a risolverle, portando a miglioramenti in tutti i repository downstream.
Svantaggi da considerare
La fonte interna è già una realtà presso molte organizzazioni. I potenziali vantaggi sono allettanti in situazioni in cui si desidera maggiore efficienza e produttività. Come con qualsiasi approccio al lavoro, però, non è necessariamente adatto a tutti gli ambienti.
Una delle preoccupazioni più frequenti sulla fonte interna è il suo impatto sulla sicurezza e sulla divulgazione delle informazioni. Le somiglianze tra la sorgente interna e il più ampio ecosistema open source si estendono solo fino a questo punto: il codice in una libreria o framework aperto non contiene nulla di sensibile, mentre potresti avere a che fare con sistemi proprietari strettamente protetti nel tuo ruolo al lavoro.
È naturale che alcuni progetti debbano sempre essere bloccati, accessibili solo alle parti interessate e al team di implementazione direttamente responsabile. Tuttavia, possedere alcuni progetti ad alto rischio con una fonte sensibile, in cui non è sicuro renderli visibili in tutta l'organizzazione, non dovrebbe significare la fine di un'iniziativa di fonte interna.
Pubblicità
Vale ancora la pena aprire progetti che possono essere esposti in sicurezza. Potresti anche astrarre le parti non sensibili dei progetti privati in nuove librerie condivise accessibili pubblicamente. Ciò avvicina i vantaggi della fonte interna alle tue risorse sensibili senza rivelarle effettivamente.
Un'altra sfida della fonte interna è comunicare le aspettative agli sviluppatori. Gli sviluppatori potrebbero essere cauti nell'esplorare progetti aperti, specialmente se la fonte interna viene introdotta in un'organizzazione storicamente chiusa. Questo può essere affrontato in vari modi, ad esempio dedicando tempo agli sviluppatori per ispezionare il codice scritto da altri team.
Può anche essere utile iniziare da piccole, esponendo solo librerie di base che saranno utili a molti team diversi all'interno dell'organizzazione. Una buona scelta può essere un componente noto ma privato che ha la reputazione di essere inaffidabile o obsoleto – pensa “bug segnalato con ApiClient di nuovo.” L'apertura di quel componente consente agli sviluppatori di contribuire con le proprie correzioni quando ne hanno bisogno, migliorando la produttività e promuovendo la crescita organica della mentalità della fonte interna.
Se provi questa tecnica, fai attenzione ad avvertire prima gli autori del progetto originale – anche se porta a una maggiore efficienza a tutto tondo, alcuni individui potrebbero trattare altri contribuendo al codice che in precedenza era “loro” come un affronto. Comunicare il motivo per cui la fonte interna viene introdotta nell'organizzazione, nonché i motivi specifici per l'apertura di singoli progetti.
Conclusione
La fonte interna si riferisce al prendere metodi di sviluppo dalla comunità open source e applicarli a progetti e processi interni. Facilita l'accesso senza ostacoli a codice e documentazione utili, promuovendo al contempo la collaborazione e la comunicazione.
Implementata correttamente, la fonte interna può essere un punto di differenziazione per un'organizzazione che riduce la ridondanza, aumenta la produttività e promuove una cultura di sviluppo più equa. La scelta di lasciare i progetti aperti per impostazione predefinita consente agli autori originali di attingere al talento umano dell'intera organizzazione. Allo stesso modo in cui i principali framework e librerie open source raccolgono le capacità collettive della comunità, così interior source può creare strumenti interni che vanno oltre ciò che ogni singolo team potrebbe ottenere.
Pubblicità
Inner source può essere difficile da ottenere giusto. Può portare al respingimento da parte dei proprietari del codice e alla diffidenza da parte degli sviluppatori. Quando si introduce qualsiasi forma di sviluppo della fonte interna, mantenere le persone sulla stessa pagina documentando chiaramente le aspettative e le procedure di lavoro. Tutti hanno bisogno di sentirsi a proprio agio nel contribuire affinché tutti i benefici della fonte interiore diventino evidenti.