Samba / git Flusso di lavoro troppo complicato

2

Sono uno sviluppatore principale per una piccola azienda e di recente ho trovato un modo per implementare il controllo della versione (git) sul nostro flusso di lavoro perché la società sta crescendo. In termini di infrastruttura abbiamo un paio di server "di produzione", un server di sviluppo (accessibile tramite Internet) e un server di sviluppo interno con accesso a Internet ma bloccato da un firewall hardware. Il nostro flusso di lavoro corrente è composto da:

  1. avviare un repository all'interno del server di produzione con il corretto .gitignore per quel progetto e eseguire il commit iniziale
  2. push che si impegnano in un repository nudo all'interno del server di sviluppo
  3. clona il repository dal server di sviluppo al server di sviluppo interno
  4. crea una condivisione di rete su samba sul server interno di developlemt in modo che altri computer di rete (tutti in esecuzione Windows) possano collegarsi ad esso.

So per certo che questo è un po 'troppo complicato, ma vogliamo provare git e rendere il flusso di lavoro il più semplice possibile.

Ho letto di git-flow e roba ma finora non sono riuscito a ottenere il flusso di lavoro corretto, penso che avere i due server di sviluppo aggiunga una certa ridondanza.

Qualcuno può condividere qualche suggerimento su come migliorare questo flusso di lavoro?

    
posta ddrjm 07.04.2015 - 18:22
fonte

1 risposta

0

Sebbene non abbia utilizzato questo metodo in produzione, ho cercato di utilizzare git per distribuire il codice sul nostro server prod. Le basi sono che si imposta un repository git nudo su qualsiasi server a cui si desidera eseguire la distribuzione, quindi aggiungerlo come remoto a un altro repository. Quando sei pronto per la distribuzione, basta inserire il codice nel repository remoto. Dalla mia ricerca, sto cercando di creare un repository git su un server per gli sviluppatori per spingere e quindi utilizzare git git su master e svilupparlo per spingere ai miei server prod e dev (in base al ramo).

La chiave per capire è che i flussi di lavoro "di base" per git sono più mirati agli sviluppatori che alla distribuzione poiché git è principalmente un sistema SCM.

Il processo su cui sto lavorando utilizza un server git centrale con un hook post-ricezione per inviare i remoti su ogni server dev o prod. Quindi sul server prod si usa un hook post-receive per controllare il codice più recente nella directory corretta.

Per ulteriori informazioni e alcune indicazioni dettagliate link è stato piuttosto utile per l'impostazione dei server di sviluppo e di sviluppo nonché buone informazioni sugli hook di post-ricezione (che sono semplici script di bash eseguiti dopo il completamento di un push).

EDIT: espansione per i commenti. In quanto sopra non sto spingendo dal server di sviluppo alla produzione. Ho un server git centrale a cui tutti i miei sviluppatori spingono. Su quel server git ho un hook git da inviare ai miei server di sviluppo (i remoti vengono configurati solo sul server centrale) quando viene effettuata una push al mio ramo di sviluppo e i server di produzione quando viene eseguito un push to master (ramo di produzione). / p>

Per lo sviluppo utilizziamo il flusso di lavoro git-flow e tutti gli sviluppatori hanno un locale ( sulla loro macchina di sviluppo) istanza del software del server Web che usiamo. Eventuali modifiche apportate sono solo sulle loro sezioni di funzionalità e non vengono unite e sviluppate per lo sviluppo (il nostro ramo di sviluppo) fino al completamento della modifica. I test iniziali vengono eseguiti sul loro computer locale per garantire che il codice sia pronto e quindi in base al cambiamento sulla macchina dei revisori del codice dopo l'unione di un test con lo sviluppo (creare un nuovo ramo da sviluppare e unire il ramo di funzionalità. Se non ci sono problemi quindi unire il nuovo ramo di integrazione in sviluppo e inviare al server)

    
risposta data 08.04.2015 - 17:28
fonte

Leggi altre domande sui tag