È necessario utilizzare CruiseControl.NET per gestire attività che non sono correlate alla fonte di costruzione?

Question

Domanda strana, forse. Abbiamo una serie di semplici utility scritte in-house che devono essere eseguite su base automatizzata. Questi sono non creare lavori. Solo cose come l'esecuzione di SendOutHourlyEmailAlarms.exe, KeepFoldersInSynch.exe e così via. Normalmente impostare queste cose come semplici operazioni pianificate/comandi AT (o un servizio di Windows se è necessario un controllo più granulare sulla pianificazione), ma un collaboratore ha impostato un certo numero di queste attività come progetti di costruzione sul CruiseControl. Server NET. Gli ho chiesto perché li ha impostati in questo modo e la sua risposta è stata che le esecuzioni (e i loro registri, valori di ritorno, eccezioni generate) sono state tutte tracciate e registrate e che queste informazioni erano accessibili attraverso un'interfaccia organizzata sul sito Web del server di compilazione. Non potrei discutere con questo.

Ma questo ha solo un odore che non riesco a identificare. È un uso corretto di CruiseControl.NET? In caso contrario, quali sono i pericoli? Anche se potrebbe andare bene, non ci sono altri prodotti più adatti a questo tipo di cose?

Answer 1

Abbiamo tutti i tipi di attività non correlate alla build per la stessa identica ragione del tuo collega, voglio un punto per cercare tutti i lavori che ho bisogno di eseguire.

Alcuni esempi di nostri progetti CC.Net:

• installatori FTP a QA remoto

• Creazione Codice di documentazione di origine

• Create VM con gli installatori installate per QA nel mattina

• Installatori di archiviazione

Praticamente tutto quello che devo fare a mano più di una volta, diventa un progetto. IMHO è molto meglio di un compito programmato anche per un altro motivo. I nostri file di configurazione sono nel controllo del codice sorgente, quindi abbiamo 1 posto per apportare modifiche. Non dobbiamo accedere a più server e apportare modifiche o chiederci quale server ha fatto.

Answer 2

Solo perché uno strumento è progettato per risolvere un particolare problema non significa che non avrà la stessa facilità nel risolvere problemi simili al di fuori del campo di applicazione originariamente concepito dal creatore dello strumento. Se CruiseControl.NET risolve bene questi problemi, allora è assolutamente lo strumento appropriato da utilizzare.

Answer 3

Penso che il tuo collega abbia fatto una buona argomentazione. Se queste attività sono correlate al processo di sviluppo, quindi inserirle in CruesControl.Net come progetto sembra accettabile. Tuttavia, tracciare la linea utilizzando un server di sviluppo per eseguire i processi di produzione. Anche se è vero che "Se l'unico strumento che hai è un martello, tendi a vedere ogni problema come un chiodo", ciò non significa che il martello non sia in grado di risolvere molti problemi!