migrator.net vs fluentmigrator vs migsharp

Question

Attualmente sto esaminando le possibili opzioni di un framework/strumento di migrazione. Mi piace l'idea delle migrazioni ruby ​​su cui si basano i framework di cui sopra.

Quindi sto chiedendo la tua esperienza, opinioni e forse un confronto tra di loro. Li stai usando in produzione?

---

grazie per le risposte. L'obiettivo di questa domanda era di capire quali strumenti sono maggiormente utilizzati nella comunità degli sviluppatori, ma sembra che le migrazioni non siano un argomento caldo qui.

In ogni caso, ho deciso di andare con MigSharp in quanto il codebase sembra essere abbastanza pulito ed è abbastanza facile da gestire e aveva il supporto per MS SQL CE. Secondo runner up sarebbe stato FluentMigrator, dove non ero in grado di produrre un esempio funzionante per l'edizione compatta.

Acclamazioni

Answer 1

che uso FluentMigrator nella produzione, e sono un collaboratore di lunga data di FM. Penso che la tua domanda sia generale; Sii più preciso. Inoltre, FM ha un gruppo google che è abbastanza attivo se vuoi informazioni FM.

FM è derivato da migrator.net, come ricordo. Utilizza una sintassi fluente e supporta più database. Abbiamo tratto ispirazione dalle migrazioni dei binari, ma non è sicuramente un porto. Vale la pena dare un'occhiata.

Una cosa che ho imparato è non mettere le migrazioni nello stesso assembly del codice dell'app. Separarli in un gruppo di migrazione e utilizzarli per la migrazione dei database.

Inoltre, si dovrebbe sempre lavorare su più ambienti per evitare problemi con le migrazioni eseguite direttamente sulla produzione. Ho sempre almeno un ambiente di sviluppo e produzione, e nella maggior parte dei casi esiste anche un ambiente di test.

Answer 2

Io uso MIG #.

Funziona bene, ma è necessario disporre di alcune linee guida per l'utilizzo, poiché le migrazioni possono complicarsi.

Utilizziamo il numero di sequenza alla fine delle migrazioni anziché un indicatore di data e ora. Questo perché non sappiamo quando è stato impostato il timestamp della data (quando hanno iniziato il set-set del codice sorgente, appena prima di impegnarsi, un po 'di tempo tra diversi sviluppatori potrebbero usare approcci diversi.

Nomi come Migration_0000034.cs offrono molto spazio.

Answer 3

A questo punto, vorrei rimanere con migrator.net. Mi piace la promessa di FluentMigrator, ma sembra non avere uno sviluppo attivo migliore di migrator.net (vedi i problemi e le richieste di pull che sono rimaste chiuse sul loro sito github).

Non esiste anche un modo semplice per eseguire un ExecuteScalar(). Lo aggiungerei, ma non voglio creare la mia forchetta e non vedo alcun motivo per cui una richiesta di pull verrebbe effettivamente trasferita nel master. (Execute.WithConnection è un'Azione in modo che sparerà su richiesta piuttosto che quando ne ho bisogno per sparare)

Quindi per me, sto tornando a migrator.net.