Dove memorizzi la tua libreria di script PowerShell?

Question

Non appena inizi a utilizzare PowerShell, è probabile che inizi a raccogliere script piccoli e utili. Gestirli bene è complicato.

• Dove mantieni gli script di PowerShell?
• Come si rintracciano le versioni & fare i backup?
• Come si sincronizza tra le macchine?
• Come si integrano le nuove versioni degli script di altri? (Compreso il fatto di dover affrontare modifiche irrisolte tra i propri script e il proprio)
• Vede PowerShell V2 che modifica l'immagine?

Answer 1

Trattiamo gli script di PowerShell come un altro codice. Sono archiviati in TFS proprio come tutto il resto. Gestisce archiviazione, backup, controllo delle versioni e fusione. Il nostro processo di distribuzione standard build & gestisce lo spostamento di questi script tra i server.

Answer 2

Metto tutto nel controllo del codice sorgente, inclusa la mia libreria PowerShell in continua espansione. Questa è la prima versione di I e diffonde gli script tra le macchine.

Answer 3

+1 per il controllo della sorgente. script PowerShell del nostro progetto di solito finiscono in uno dei:

• $/progetto/Tronco/build
• $/project/trunk/Test/bin
• $/progetto/trunk/tools/bin

Per gli script personali, al momento utilizzo due approcci. Per prima cosa creo un ~ \ Bin, lo metto nel percorso e metto i miei script PowerShell personali lì. Il secondo approccio è che utilizzo Live Mesh per sincronizzare una cartella PowerShell tra tutte le mie macchine. In esso sono presenti script, presentazioni, ecc. Probabilmente dovrei creare un sottodiruolo Bin nella cartella mesh e mettere quella cartella nel mio percorso.

V2 introduce il supporto del modulo, quindi tutti i moduli che creo andrebbero in ~ \ Documents \ WindowsPowerShell \ Modules.

Per quanto riguarda la domanda sull'utilizzo di script da altri e il controllo delle versioni, consultare i moduli e Module Manifests in V2. Penso che questa nuova funzionalità ti aiuterà.

Answer 4

Conservo il mio profilo PowerShell & script personalizzati in un repository mercurial. Cambio frequentemente tra la mia macchina di sviluppo a casa e l'ambiente di sviluppo al lavoro, quindi utilizzare VCS distribuito ha davvero i suoi vantaggi: ogni macchina è autonoma (non è necessario accedere a un server di controllo sorgente al lavoro da casa tramite una VPN che non esiste nel mio caso).

Applico/sposto le modifiche dal repository locale su ogni macchina a un repository "trasferimento" sulla penna USB e le cose continuano a funzionare correttamente.