Qual è il modo giusto per gestire gli script degli sviluppatori?

Gli sviluppatori creano script per aiutare nel loro lavoro. Ad esempio, per eseguire Maven con determinati parametri, per eliminare le attività in background non necessarie che si presentano nello sviluppo o per connettersi a un determinato server. Gli script non sono script di build di base né vengono utilizzati nel nostro server di integrazione continua.

Qual è il modo migliore per gestirli? Per metterli in una directory (forse /scripts) e controllarli in Git? Per mantenerli separatamente in alcuni file server?

L'argomento per trattarli come codice sorgente è che sono fonte e possono cambiare. L'argomento per non farlo è che sono solo strumenti ausiliari e che non tutti gli sviluppatori hanno bisogno di un determinato script (ad esempio script specifici di Linux in cui alcuni sviluppatori lavorano su Windows).

Gli script per sviluppatori passano anche al controllo di versione, perché di solito questi script dipendono anche dagli elementi nel controllo di versione, ad esempio i percorsi dei file.

Se questi script hanno una versione, dovrebbero funzionare anche per tutti gli sviluppatori per evitare che ogni sviluppatore scriva il proprio set di script, che diventa un inferno di manutenzione.

Inoltre, correzioni di bug o miglioramenti di questi script vengono automaticamente distribuiti a tutti gli sviluppatori tramite il controllo della versione.

Oltre alla risposta di @ simon.

Nell'ingegneria del software non tutto riguarda la programmazione, la progettazione o la modellazione. Ci sono una miriade di compiti che eseguiamo continuamente durante la giornata lavorativa. Ne hai già menzionato uno: costruire il progetto al di fuori dell'IDE - ma ce ne sono molti altri.

Gli sviluppatori esperti / proattivi tendono ad automatizzare questi compiti. Alcuni, addirittura, creano strumenti quando questi compiti diventano parte dell'SDLC e sono noiosi - e inclini a errori - da fare a mano. I programmi sono bravi a fare lavori ripetitivi, non importa quanto noiosi siano. Noi - umani - non siamo così bravi.

Questi strumenti / script hanno altri effetti collaterali positivi

1. Produttività
2. Trasferimento di conoscenza
3. Autonomia (per i nuovi arrivati)

Quindi, sì, gli script dovrebbero essere in SCM e dovrebbero essere uno strumento in più nella casella degli strumenti dello sviluppatore.

Per quanto riguarda la cartella /scriptsdirei che non importa. Per semplicità, li lascio nella directory principale del progetto in modo che tutti i percorsi dichiarati negli script siano relativi alla cartella del progetto. Se ho bisogno di accedere a cartelle o file esterni, creo collegamenti soft .

Aspetti da considerare prima di controllare gli script in SCM.

• Per motivi di sicurezza, assicurati che gli script non abbiano credenziali codificate ( idealmente, gli script dovrebbero essere ben parametrizzati )

• Assicurati che gli script non facciano cose strane al sistema, come ad esempio per eseguire comandi che non possono essere annullati (il più tipico rm -rf).

• Dal momento che questi diventano parte della fonte del progetto, la documentazione è molto apprezzata.

• Lo scripting non è scienza missilistica. Rendi gli script concisi. Invece di uno per dominarli tutti ... e nell'oscurità li leghi , rendili più, più piccoli e concisi. Come se stessi applicando SRP.

Offrirò un'opinione un po 'più negativa. Da un lato, gli script per sviluppatori che sono generici, efficaci e utili dovrebbero ovviamente essere condivisi con altri sviluppatori e il modo migliore per farlo è di farli sedere con il codice nello stesso repository.

Tuttavia , impostarei una barra in alto per l'ingresso per il commit degli script. Gli script sono codice, proprio come il software stesso. Ciò significa che devono essere trattati in modo simile ad altri pezzi di codice:

• Passando attraverso la revisione del codice
• Testato e automatizzato se possibile
• Considerato quando si apportano modifiche alla base di codice (in particolare, se uno script viene utilizzato da molti sviluppatori, apportare una modifica che interrompe lo script causerà molti conflitti)
• Mantenuto (con tutto ciò che comporta - priorità, tempo, documentazione ecc.).

Esistono diverse ulteriori considerazioni che si applicano più agli script che al software stesso:

• Innanzitutto, è molto più difficile convincere la propria organizzazione e le parti interessate a investire nel mantenimento di script che semplificano la vita degli sviluppatori. Ciò significa che è più difficile trovare il tempo per soddisfare i criteri di cui sopra: è facile scrivere uno script che funzioni per te nel tuo ambiente, ma parametrizzarlo, renderlo stabile, documentare che richiede molto più tempo. Ciò significa che gli script possono e diventeranno codice morto a meno che uno sviluppatore non possa giustificare il mantenimento dello script corrente.
• È molto meno probabile che più sviluppatori abbiano familiarità con uno script complicato per mantenerlo, o che più sviluppatori sentano la proprietà del codice. Quando lo sviluppatore originale lascia, trovare qualcun altro da cui acquisire la proprietà può essere difficile (e trovare e giustificare il tempo per loro di imparare come funziona la sceneggiatura può essere ancora più difficile).
• È molto più probabile che uno script interagisca con la macchina degli sviluppatori e crei l'ambiente in qualche modo. È anche molto probabile che tu abbia più sviluppatori con più ambienti diversi. Se uno script incasina un ambiente perché non è stato gestito correttamente o non è stato preso in considerazione un caso angolare, non stai solo rompendo una build notturna del tuo software, stai potenzialmente costando uno sviluppatore un giorno o più di lavoro per ottenere il loro ambiente tornato alla normalità. Ciò può causare sangue di baad e perdita di fiducia.
• Poiché gli script sono spesso esterni al software stesso, mantenerli può essere una sfida. Se gli script non vengono eseguiti tramite automazioni, è facile che diventino stantii o dimenticati, a quel punto sono diventati codice morto e sono solo debiti tecnologici che qualcuno dovrà prendere tempo per ripulire.

Riassumendo, gli script possono essere molto utili per un singolo sviluppatore, ma condividerli come parte della base di codice stessa può essere un'attività molto più difficile e può potenzialmente causare più problemi di quanti ne vengano risolti.