Config di analisi statica e script di convenienza nel controllo del codice sorgente

Naviga le tue risposte
4

1) Lo strumento di analisi statica deve essere posizionato nel controllo sorgente? Questa configurazione non è necessaria per compilare / eseguire software e alcuni sviluppatori possono avere preferenze diverse (anche all'interno della convenzione di codifica). D'altra parte posizionare tale configurazione nel controllo del codice sorgente e dichiarare lo strumento di analisi statica come "parte ufficiale del progetto" può incoraggiare tutti a testare il suo codice e a mantenerlo molto coerente. Questa domanda riguarda principalmente l'open source, perché nei progetti commerciali si stabilirà comunque un flusso di lavoro rigoroso.

2) Gli script di convenienza (generare documentazione, eseguire analisi, eseguire test, distribuire, generare programmi di installazione) devono essere inseriti nel controllo del codice sorgente? Questi script devono essere multipiattaforma e potrebbero non funzionare bene su tutti i sistemi. Le persone possono semplicemente usare l'IDE per svolgere alcune di queste attività. Ma chiedere a tutti di scrivere la propria piastra di riscaldamento mi sembra un po 'stupido. Questa domanda riguarda principalmente i linguaggi interpretati, perché quando si lavora con i linguaggi compilati solitamente si ottiene utilizzando lo strumento di compilazione che non è necessario per creare programmi in linguaggi dinamici.

    
posta Anton Barkovsky 13.05.2011 - 23:56
fonte

3 risposte

3

Capisco la tua esitazione.

Anche se quegli script sono utili, non fanno parte del processo di compilazione e in quanto tali non sono necessari di per sé.

Tuttavia sono dell'opinione che qualsiasi file di configurazione / script su misura che viene eseguito sul codice dovrebbe essere nel repository di controllo del codice sorgente.

Perché?

Perché se eseguo il check out di una vecchia versione e i nuovi script non funzionano, come faccio a eseguire l'analisi statica? Come dovrei aggiornare la documentazione?

Tutto ciò che interagisce direttamente con il codice dovrebbe essere incorporato nel pacchetto di codice ... o referenziato.

Se si desidera mantenere gli script al di fuori del controllo del codice sorgente, ad esempio perché sono abbastanza grandi e influiscono sul checkout / tempo di aggiornamento, va bene, tuttavia è necessario consegnarli correttamente (versione) e un file nascosto con il codice che descrive quale versione dello script / strumento deve essere utilizzata (funziona).

In generale, i file di configurazione non sono mai abbastanza grandi da garantire la consegna (e la versione) separatamente, dalla mia esperienza.

    
risposta data 16.05.2011 - 18:42
fonte
2

C'è un motivo migliore per controllare TUTTE le configurazioni e gli script di supporto.

Le build dovrebbero essere riproducibili. Dovrei essere in grado di tornare alla fonte com'era 3 mesi fa ed essere in grado di produrre la stessa build (ad eccezione dei timbri data) di quella prodotta 3 mesi fa. Questa capacità di riprodurre con un delta minimo consente asserzioni più forti e maggiore sicurezza quando si fanno cose come correggere bug.

    
risposta data 14.05.2011 - 00:08
fonte
2

La teoria è che qualsiasi cosa usata nella produzione di una build dovrebbe essere sotto il controllo del codice sorgente. L'intento è che dovresti essere in grado di replicare l'intero processo di costruzione e generazione dal repository. È possibile prendere questo per quanto riguarda l'inserimento degli strumenti di sviluppo nel repository, ma a mio parere è un po 'eccessivo.

Per te questo significa che non solo il codice, ma anche tutto il resto, sia che costruisca script, script di test o configurazione. Quindi sì, la tua configurazione di analisi statica e lo script di convenienza vanno nel repository.

    
risposta data 16.05.2011 - 17:03
fonte

Leggi altre domande sui tag

Come calcolare il checksum? Pulizia dei bug nel bel mezzo di un progetto