Come non correre rischi con i nuovi collaboratori?

2

Il mio team aggiungerà nuovi membri del team e il mio manager non vuole correre rischi. Non penso che sia un grosso problema, ma il mio manager è preoccupato che un nuovo programmatore possa sabotare e distruggere accidentalmente parti del codice o dei dati, ad es. causa disastro di dati. Dico che la probabilità non è molto alta, ma mi è stato comunque detto che è importante limitare i diritti di ciò che i nuovi collaboratori possono fare.

Ma questo non è pratico e non possiamo mangiare la torta e averla - aggiungendo un collaboratore al controllo del codice sorgente il nuovo collaboratore ha accesso a tutto il codice sorgente e anche se ci fosse un modo per lasciare solo un nuovo membro a parti del codice sorgente (stiamo usando bitbucket per il controllo del codice sorgente) non funzionerebbe ancora, dal momento che tecnicamente l'intero progetto è solitamente necessario per costruirlo, quindi non si può semplicemente prendere una parte del codice e aspettarsi che funzioni e in grado di costruire autonomamente.

Utilizziamo Google App Engine e non è nemmeno un'idea funzionante creare un clone dell'app su cui il mio collaboratore può costruire.

Ho detto che non siamo i primi con questo problema e che una soluzione che funziona per qualcun altro dovrebbe funzionare per noi, ma il mio manager non sembrava soddisfatto di quella risposta.

Puoi commentare la mia situazione o dare consigli concreti su cosa si potrebbe fare per il "problema" / scenario poiché è solo uno scenario che uno sviluppatore appena aggiunto cancella accidentalmente l'intero datastore, ma non vogliamo che sia possibile .

    
posta Niklas Rosencrantz 28.02.2012 - 14:52
fonte

4 risposte

7

L'utilizzo delle credenziali di rete è la prima linea di difesa: se la nuova persona non può accedere a una risorsa (server Web, server di database, servizio di autenticazione, ecc.) non può comprometterla.

Questo significa anche che non memorizzi le password per i tuoi database e altri server nel controllo del codice sorgente o in qualsiasi posto accessibile a una nuova persona.

In termini di controllo del codice sorgente: dal momento che lo stai utilizzando, sei protetto. Se la nuova persona cancella tutto il codice e si impegna, devi solo eseguire il rollback.

Come per i database - come ogni DBA ti dirà, avere una buona strategia di backup e ripristino è la tua protezione contro molti problemi.

Tuttavia, questi sono tutti mezzi tecnici per mitigare un problema sociale. Il fatto è che il tuo manager non dovrebbe assumere persone di cui non può fidarsi. Avere una clausola penale nel contratto di questa persona è la soluzione giusta per questo problema.

Aggiornamento: mi viene in mente che tutto quanto sopra non tutelerà la tua azienda da te o da uno dei tuoi colleghi esistenti con pieno accesso a tutto ciò che è necessario per la cancellazione del tuo archivio dati completo. Come ha mitigato il tuo manager contro questo ???

    
risposta data 28.02.2012 - 14:55
fonte
3

Limitare l'accesso al controllo del codice sorgente non ha senso - ecco perché hai il controllo del codice sorgente. Se la nuova persona commette un commit errato, ripristina una versione precedente.

Penso che i buoni test automatici e le frequenti revisioni del codice con i nuovi membri del team siano molto più preziosi. E se il tuo capo è preoccupato per la perdita di dati sui sistemi di produzione, non dovresti permettere agli sviluppatori di avere accesso diretto illimitato a questi comunque.

    
risposta data 28.02.2012 - 15:07
fonte
1

Avere una procedura per assicurarsi che siano accoppiati con un membro del team esperto per determinate operazioni le prime volte. Il controllo del codice sorgente e i backup ti proteggeranno, ma possono comunque costare parecchie ore di lavoro.

Per quanto riguarda le cose infrante, più alto è il tuo punteggio sul test di Joel, più facile dovrebbe essere per loro costruire e distribuire correttamente la prima volta che devono.

    
risposta data 28.02.2012 - 15:12
fonte
1

Piano di ripristino di emergenza . Nuovi assunti, vecchi assunti scontenti, errori innocenti e problemi con Google. Se potessimo evitare che gli errori si verifichino il 100% delle volte (i manager con la punta di una penna amano gli assoluti), non avremmo backup.

Controllo : il tuo sistema dovrebbe sapere chi ha cancellato tutti i dati.

Assumere persone di qualità - ottenere riferimenti e fare controlli in background. La maggior parte dei professionisti perde il sonno di notte preoccupandosi di perdere il codice e causando accidentalmente problemi con i propri dati e non trovando modi per rovinare la propria carriera. Il tuo capo dovrebbe concentrarsi sul fare meglio il suo lavoro durante l'assunzione.

Aree di test e di gestione temporanea : non conosco Google App Engine, ma ciò è inaccettabile e non comune. Se si tratta di un problema di costi, il tuo capo deve tornare a fare il suo lavoro e giustificarlo sulla base dei rischi evidenti. Non testare o codificare su sistemi e dati di produzione.

    
risposta data 28.02.2012 - 16:39
fonte

Leggi altre domande sui tag