2010-07-06 10 views
5

... o devi passare attraverso qualcun altro (una persona che gestisce i server) per far distribuire il tuo codice?Sei responsabile della distribuzione del codice in un ambiente live?

Comprendo la politica di non consentire a tutti di accedere a un server di produzione live ma vorrei poter accedere al mio codice, al database e ai file una volta che sono attivi.

Come è possibile per tutti gli altri?

+0

La persona che ho sostituito si sviluppava nell'ambiente live! –

+0

Per essere più specifico sul motivo per cui ho chiesto, ho un'app Web che utilizza un paio di file xml. Piuttosto che apportare modifiche a questi file tramite l'applicazione, preferisco semplicemente modificarli localmente e caricarli sul server. Non dovrebbero cambiare molto spesso. Lo stesso con alcune delle immagini del sito. Non cambieranno spesso, ma preferirei non lasciare che gli utenti li mantengano da soli. – JohnnyBizzle

+0

@Ed B. Ora non andrei così lontano! – JohnnyBizzle

risposta

0

Avere un gruppo di gestione della configurazione o qualcuno diverso dal gruppo di sviluppo che distribuisce il codice nell'ambiente di produzione ha i suoi vantaggi. La maggior parte dei quali aiuta a rafforzare il rigore e la pista di controllo delle uscite. Ideale il team di gestione della configurazione dovrebbe rilasciare il codice tramite script. Lo script preleva dal repository del codice per un determinato tag e viene rilasciato su un determinato server. In questo modo si minimizzano gli errori lungo la strada.

Penso che il team di sviluppo avrebbe dovuto leggere solo i diritti sui dati di produzione e la possibilità di vedere tutti i file di registro. Ciò consente un più facile debug dei problemi. Se una nuova versione di codice richiede anche aggiornamenti del database, il team di gestione della configurazione dovrebbe anche distribuire tali modifiche, ovviamente tramite script.

0

Tutto dipende da quali procedure l'azienda ha in atto. Alcuni sono più flessibili di altri. La nostra organizzazione si sta allontanando dagli sviluppatori che hanno accesso all'ambiente di produzione. Ora tutto deve seguire il processo di controllo qualità e quindi le operazioni (che si occupano della distribuzione e della manutenzione del codice). Penso che finirai con meno incidenti, ma un tempo di correzione degli errori più lungo.

+0

Penso che tu abbia più probabilità di finire con lo stesso numero di incidenti e un tempo di correzione dei bug più lungo. –

+0

@Brian: potrebbe o potrebbe non succedere. È ancora nuovo, quindi diamo il beneficio di un dubbio. È il sapore del giorno. –

+0

Suppongo che una piccola barriera tra decidere qualcosa sia una buona idea e provarla su un sito dal vivo è una buona cosa, dato il numero di errori idioti che faccio sempre. Ma piccola è probabilmente la parola chiave lì. –

0

All'ultimo posto per il quale ho stipulato un contratto, c'è un gruppo specifico di persone responsabili dell'implementazione e della configurazione sui server di produzione.

Tutto il codice doveva essere archiviato in vcs ed è qui che hanno ottenuto il codice da distribuire. Quindi non hai "accesso" per apportare modifiche al codice una volta che è attivo. Hanno distribuito il codice nuovo/modificato due volte a settimana, a meno che non si trattasse di uno spiegamento di emergenza.

+0

Immagino che nel tuo caso l'ambiente live rispecchi l'ambiente di test. Non sono sicuro che sia il nostro:/ – JohnnyBizzle

+0

Avevano diversi ambienti, due sviluppo, un qa e produzione. – buckbova

0

Ho appena distribuito qualcosa in un ambiente dal vivo oggi. Ho anche accesso al database live.

Questo è stato noto per causare alcuni errori epici in passato. A volte qualcuno ha abbandonato un tavolo nell'ambiente di produzione anziché in un ambiente di sviluppo. Tuttavia, vedo poco vantaggio in un'altra persona che sta rilasciando, specialmente quando non è a conoscenza del software.

+0

Eliminare una tabella dal vivo? Indovina, è per questo che prendi i backup! – JohnnyBizzle

+0

Ovviamente, ma ciò significa che il sistema è inattivo mentre qualcuno sta ripristinando la tabella da un backup. – Sjoerd

0

Il flusso ideale procedura di rilascio è la seguente (nel mio piccolo mondo):

  1. Sviluppo Env (dove si codifica su e fate la vostra prova)
  2. Testing Env (dove i tester prova con dati in tempo reale - potrebbe anche essere tu)
  3. In questa fase può andare direttamente a vivere, o rilasciare in un altro campo di prova dove è possibile far testare gli utenti.

A seconda della severità della tua azienda, lo sviluppatore può avere o meno accesso alla versione live, soprattutto se è una grande azienda.

+0

Sono simile. - Sviluppo sulla mia macchina. - Distribuire su un server interno/intranet e lasciare che il tester provi a farlo. - Quando è pronto viene inserito in un elenco di distribuzione (concezione recente) e distribuito per la vita. – JohnnyBizzle

1

Ogni ambiente è leggermente diverso. In confronto, devi decidere cosa funziona per te. Amazon, ad esempio, fa sì che i propri sviluppatori possiedano il proprio codice, che alcuni sviluppatori odiano, ma è una caratteristica di quell'ambiente che mantiene bassi i bug (quando è stata l'ultima volta che hai visto un bug su amazon.com?).

Altri vogliono un processo di QA più stretta in modo da creare un reparto operativo di badare dell'airbag, ma ho scoperto che tendono a creare un clima di negatività in azienda: sono ricompensati da giustificare il loro ruolo, che comporta sottolineando e sostenere le cose cattive nel mondo. Se gli sviluppatori sono bravi nel loro lavoro, il risentimento può insinuarsi se la loro retribuzione è in qualche modo correlata al rendimento.

Personalmente, preferisco occuparmi dell'intero stack, ma mi trasferisco sempre più a provider che mi consentono di preoccuparmi sempre meno dell'hardware (EC2, Heroku, ecc.) E di concentrarsi maggiormente sulla funzionalità nel app.Personalmente mi piace possedere il codice e gli errori, in quanto significa che sono motivato in modo dimostrabile a tenere bassi i bug ticket - ogni biglietto aperto è un ritardo rispetto alla nuova funzionalità su cui voglio lavorare.

Ognuno al proprio.

+0

Ci sono argomenti in entrambi i casi. Personalmente vorrei essere responsabile per il mio codice live e sapere che nulla è stato manomesso in precedenza (è già successo prima!) Anche avere gli ambienti specchiati sarebbe bello! – JohnnyBizzle

0

Risposte al suddetto ambiente di sviluppo e test. È anche molto importante avere un server di compilazione dedicato e separato che non viene utilizzato per lo sviluppo. Estrae il codice sorgente dal repository, compila e crea la distribuzione (nel file EAR o WAR di Java) che viene quindi distribuito nell'ambiente di testing ecc.

Questo server di build può anche ospitare l'ambiente CI ed eseguire regolarmente build giornaliere automatizzate.