Situazione: il dba è un appaltatore esterno che mantiene l'intero codice DAL verificato in TFS. Sarebbe bello come lo sviluppatore front-end essere in grado di aggiungere colonne e modificare procs e quant'altro, senza dover contare sull'attesa che questo tizio risponda alle e-mail per fare il lavoro.
Domanda: quale sarebbe la soluzione / processo raccomandata che consentirebbe uno sviluppo più rapido / agile, mantenendo l'integrità dei dati e l'amore e la felicità della pace tra la squadra?
Martin Fowler e Pramod Sadalage hanno scritto un articolo eccellente su questo argomento.
Ogni sviluppatore ha il proprio database a cui possono essere apportate modifiche. Queste modifiche vengono quindi comunicate (come un changeset) al DBA che le implementa nel database master, quindi è ancora coinvolto nel processo, probabilmente conosce meglio le strutture e le esigenze del database. Penso che sia l'approccio migliore in quanto è soddisfacente per tutte le persone coinvolte nel processo ed è anche molto agile.
È possibile modificare il DAL in modo simile. Apporta le modifiche e crea un changeset per DBA quando pensi di aver terminato, in modo che possa esaminarlo e unirlo al suo master.
Bene, quando sto facendo la cosa DBA, sono stato conosciuto per bloccare tutto così i programmatori maledettamente sporchi non riescono a ottenere il loro mits su di esso. Tutti pensano di sapere come farlo meglio e "modificano" le cose per renderle più facili per se stesse e causano un disastro irragionevole.
L'altra alternativa è di spalancarla, e lasciare che i programmatori si scontrino per un po ', poi saltare dentro e imporre l'ordine mentre le cose cominciano a chiudersi ... Questo è sicuramente più "agile", ma può essere un vero incubo a seconda di ciò che deve essere tagliato o modificato ... Gli amministratori di database spesso hanno una migliore comprensione del progetto nel suo insieme e alcuni cambiamenti che sembrano innocui possono essere problematici.
Se sarà il solo portiere, dovrà avere una specifica fissa, o essere in grado di "vendere" la sua visione al resto degli sviluppatori.
C'è un grosso problema che supera qualsiasi altro problema:
Perché è autorizzato a farlo? Nessuno dovrebbe avere un file estratto a meno che non stia facendo delle modifiche. Ci dovrebbe essere una politica di squadra sui checkout.
L'appaltatore (che a loro piaccia o no) lavora come parte di una squadra, ea volte altri membri del team potrebbero aver bisogno di apportare modifiche. Questo è un problema di comunicazione. Sfortunatamente non esiste un modo automatico per risolvere questo problema di comunicazione.
Al posto dei livelli orizzontali, preferisco lavorare in silo su più livelli.
In questo modo nessuna persona / squadra può bloccare in questo modo.
Significa anche che gli sviluppatori sono multi-esperti e in grado di spostarsi tra le funzionalità molto più facilmente.
Naturalmente, ci sono sezioni (progettazione dell'interfaccia utente e progettazione di DB) che potrebbero richiedere più lavoro di specialità, ma ti viene l'idea.
Semplice, se non lo fai già, dovresti avere 3 ambienti:
L'ambiente di sviluppo deve essere amministrato dai tuoi sviluppatori.
Potresti anche voler aggiungere un ambiente RC.
Un'altra risposta, se non sono possibili più ambienti, potresti svilupparti contro un repository fittizio ... In questo modo costruisci i tuoi modelli e quindi il tuo appaltatore è responsabile per far corrispondere i tuoi modelli al DB. In un certo senso è meglio perché libera gli sviluppatori dal preoccuparsi del database.
Il tuo problema mi sembra essere una mano d'opera. È appropriato e necessario che tutte le potenziali modifiche di daatbase siano approvate da uno specialista di database. Se la persona attuale non riesce a tenere il passo con il lavoro in modo tempestivo, hai bisogno di più specialisti di database.
Questo è un problema di gestione tanto quanto tecnico.
Esistono sicuramente validi motivi per un DBA (indipendentemente dal fatto che sia presente o meno, un appaltatore o un dipendente) per impedire agli sviluppatori di apportare qualsiasi tipo di modifica al database.
Tuttavia, il problema principale che hai definito è quello della disponibilità. Il tuo manager sa che tempo / denaro è sprecato in attesa di questa persona? Altrimenti, potresti voler far apparire come stanno tutti seduti.
Leggi altre domande sui tag teamwork asp.net team-foundation-server configuration team-building