Suggerimenti per migliorare il flusso di lavoro di piccoli gruppi (CI / Distribuzione)

Question

Suggerimenti per migliorare il flusso di lavoro di piccoli gruppi (CI / Distribuzione)

#1 da (3 voti)

5

Mi piacerebbe migliorare il flusso di lavoro e l'architettura del mio team.

In questo momento abbiamo un server di sviluppo LAMP su cui ogni membro del team ha una sottodirectory. Lavoriamo direttamente in questa directory via LAN. C'è anche una directory "release" per quando siamo pronti per caricare tramite FTP sul server di produzione.

Usiamo un repository privato github che funge da repo centralizzato.

Esempio di flusso di lavoro giornaliero corrente di un programmatore:

Scegli una storia utente su cui lavorare dopo una rapida riunione giornaliera Apri un ramo git che prende il nome dalla storia dell'utente Lavora, commetti alcuni cambiamenti Premi su Github Quando decido di implementare, apporto le modifiche, eseguo una revisione del codice, cambio le variabili necessarie per la produzione e il caricamento via FTP. Se sono state apportate modifiche al database di sviluppo, anch'io le replica sul database del server di produzione.

Qualche idea in cui dovrei iniziare a migliorare questa situazione? Problemi attuali:

I membri del team non possono facilmente lavorare da casa poiché devono modificare direttamente sul server di sviluppo (problemi di lag)
Il processo di distribuzione è terribile (modifica manuale delle variabili e FTP alla produzione)

MODIFICA: Proverò ad aggiungere domande migliori.

Impostazione di sottodirectory per ogni sviluppatore su un server di sviluppo comune: buona idea o no? Alternativa possibile: ogni sviluppatore imposta il proprio ambiente di sviluppo (utilizzando WAMP o simile) e spinge al server di test.
Per quanto riguarda l'aspetto della distribuzione, ritengo che cambiare manualmente le variabili di configurazione e l'FTP alla produzione sia una cattiva idea. Possibile alternativa: configurare git sul server di produzione, impostare i file di configurazione in .gitignore (mantenerli manualmente direttamente sul server di produzione) e rilasciare le modifiche.
Per gli sviluppatori remoti, dovrebbero replicare l'ambiente di sviluppo (di nuovo, WAMP o simile) ma lavorare sul database del server di sviluppo? Penso che sia meglio che copiare il database su macchine locali.

workflows continuous-integration deployment

posta Lukmo 05.04.2013 - 17:47

fonte

1 risposta

Leggi altre domande sui tag workflows continuous-integration deployment

Chi gestisce un CMS dopo che un progetto freelance è stato completato? Come implementare due diversi servizi Web che eseguono la stessa logica aziendale?

score 3 · Accepted Answer

Dai a ogni dev il proprio ambiente, non importa se è su una scatola condivisa o su un'installazione locale (le installazioni locali hanno comunque molti vantaggi)

Quindi, fai in modo che il tuo server sia compilato e distribuito automaticamente in un ambiente di test (o integrazione). Quando i commit vengono trasferiti su un ramo di sviluppo, vengono distribuiti in questo ambiente di test centrale in modo da poterli testare preferibilmente utilizzando strumenti automatici.

Quindi ottenere una configurazione simile all'ambiente di test per il ramo di rilascio, quindi quando il codice viene unito, viene distribuito anche su un sistema più rappresentativo. In genere, gli ambienti di test e di preproduzione inizieranno allo stesso modo, ma il test terminerà con più cruft su di esso, il pre-prod dovrebbe essere molto più pulito in quanto solo il codice che viene unito al ramo di rilascio finirà per esso, senza codice "sperimentale" o rollback.

Configs - questo è un problema SCM standard, manterrei un'area separata per la configurazione di ogni ambiente (inclusa anche la produzione) e memorizzerò tutte le versioni, quindi scegliere quella giusta per qualsiasi implementazione. Ovviamente dovrai scrivere tutto questo in modo che funzioni correttamente, e può essere un PiTA, ma sembra che tu abbia già i passi necessari da eseguire per la distribuzione, quindi basta copiarli. Consiglierei Jenkins come server CI che ti aiuterà con questo se non vuoi codificarlo direttamente in githooks.