Compositore & compositore.blocco in GIT e i conflitti di unione

Ecco la nostra situazione :

Abbiamo 3 diversi Laravel progetti e tutti e 3 i progetti si basano sul nostro Core progetto.
Questo Nucleo centrale del progetto è separato Laravel pacchetto ospitato nella nostra repo e viene utilizzato come un dipendenza per altri progetti.

Prima, ogni volta che qualcosa potrebbe cambiare nel “cuore” del progetto si accendevano basta eseguire un compositore di aggiornamento ourvendor/ourcorepackage sui nostri server, per ogni progetto, per tirare le modifiche principali. Tuttavia, come ultimamente compositore sembra soffrire di gravi problemi di memoria quando si tenta di eseguire l’aggiornamento sul nostro Digital Ocean ambiente di gestione temporanea con 512 MB di Ram. Vedere : https://github.com/composer/composer/issues/1898

La soluzione che ho sempre incontrato è gente che dice che si dovrebbe sempre eseguire compositore installare sul vostro server di produzione. Posso riferire che in termini di sicurezza, perché può essere pericoloso se si esegue l’aggiornamento a una nuova versione di alcuni 3rd party pacchetto che può rompere il vostro codice. Ma nel nostro caso abbiamo solo aggiornare il proprio pacchetto di base, quindi sappiamo quello che stiamo facendo, ma questo problema di memoria ci impone di usare il compositore metodo di installazione perché è meno memoria esigenti.

Quindi, in pratica questo è il nostro flusso di lavoro corrente :

Quando qualcosa cambia nel nostro pacchetto di base di cui abbiamo bisogno per eseguire un compositore
aggiornamento ourvendor/ourpackage su ogni progetto a livello LOCALE, Questo genera un
compositore.file di blocco
Ci impegniamo compositore.blocco di file nella nostra repo
Sul server per ogni progetto, abbiamo una git pull ed eseguire un compositore
installare. Questo sarà solo un aggiornamento del pacchetto di base e corre molto più veloce
e non ha problemi di memoria vs compositore aggiornamento

Tuttavia questa soluzione genera 2 problemi :

Dal momento che stiamo lavorando con più sviluppatori sullo stesso progetto che abbiamo, a volte, finiscono per avere conflitti di unione per il compositore.file di blocco quando si tira in modifiche a livello locale.
Esecuzione di un git pull sul server dà un errore : le modifiche locali alle seguenti file verrà sovrascritto da unire: compositore.blocco
Si prega di eseguire il commit delle modifiche o stash prima di poter unire.

Quindi cosa dovrei fare qui? Prima di tirare su il server rimuovere il compositore.file di blocco?
Come gestire i conflitti di unione per il compositore.file di blocco?

È un peccato che il compositore aggiornamento soffre di problemi di memoria, perché tale metodo sembra molto più logico. Basta aggiornare il pacchetto che si desidera e senza problemi con il compositore.file di blocco..

Si prega di consulenza come un flusso di lavoro corretto con GIT e compositore dovrebbe essere, nel nostro caso, e come risolvere i conflitti di cui sopra ?

Molte grazie per il vostro input

blog.doh.ms/2016/11/28/risoluzione dei-conflitti-in-compositore-lock
Correlate: Dovrebbe compositore.blocco di impegnarsi per il controllo di versione?

InformationsquelleAutor cenob8 | 2014-09-08

Tags: composer-php, git, laravel, merge, php

Come si può verificare che un aggiornamento di base (o di qualsiasi altra dipendenza che viene aggiornato) non rompere le cose in progetti utilizzando, se lo sviluppatore non fare questo passo?

Ecco perché il solito flusso di lavoro è previsto il composer update essere eseguito su una macchina di sviluppo, di avere abbastanza RAM (cioè probabilmente più di 1GB di impostare come limite di memoria PHP), e l’aggiornamento dovrebbe essere attivato manualmente dal committente (e se attivato automaticamente da una continua integrazione di costruire, i requisiti di memoria di applicare per questa macchina).

Non vi è alcun modo per aggirare questo requisito di memoria. Un server web con solo 512 MB di RAM installata potrebbe essere in grado di funzionare come un server di gestione temporanea con a malapena qualsiasi concorrente utenti presenti, ma non dovrebbe essere utilizzato per aggiornare il Compositore dipendenze.

Personalmente posso risolvere i conflitti di unione in composer.lock con un sistema molto semplice: Eliminare il file di blocco ed eseguire composer update. Questo consentirà di aggiornare tutte le dipendenze per le ultime versioni che soddisfano i requisiti di versione, e creare un nuovo lavoro composer.lock file che si impegna durante la fusione.

Non ho paura di aggiornare potenzialmente tutto, perché funziona come previsto, o il mio test di cattura rapidamente gli errori.

Faccio selezionare la 3 ° festa di pacchetti che uso con attenzione:

hanno per etichettare i loro versioni, preferibilmente utilizzando semantic versioning.
Io non uso i rami per il rilascio di versioni (le rare volte che qualcuno li ha usati durante lo sviluppo sono state dolorose)
dovrebbero spedire una versione nuova se fanno indietro modifiche incompatibili
localmente sviluppati anche i pacchetti di seguire questi requisiti

Questo funziona con circa 270 pacchetti serviti da locale Satis istanza (probabilmente anche un fattore da considerare quando si cerca di ridurre l’ingombro di memoria – solo i pacchetti noto Compositore può finire in memoria: Confrontare le decine di migliaia di pacchetti potenzialmente disponibili su packagist.org con 270 pacchetti locali). 60 pacchetti di 270 sono sviluppati a livello locale da 20 sviluppatori, e in modo casuale il rilascio di nuove versioni. L’aggiornamento fallimenti negli ultimi 2 anni sono molto rari, e dovrebbe essere trattato come gli altri bug: Se una versione codificata è rilevato di essere incompatibile il rilascio di una versione di bugfix annullando i cambiamenti, e tag originale cambiare con una nuova major release, se incompatibile il cambiamento è necessario.

In modo che il flusso di lavoro si chiedono è probabilmente in questo modo:

In qualsiasi momento, ogni sviluppatore dovrebbe essere in grado di eseguire composer update sulla propria macchina locale.
Essi dovrebbero essere in grado di rilevare se questo si rompe le cose sulla propria macchina locale.
Se non è rotto, commettere le modifiche tra cui l’ composer.lock file Git
Il server di gestione temporanea viene eseguito solo composer install e utilizzare esattamente le versioni che lo sviluppatore usato la sua macchina.
Se non è rotto sulla messa in scena, che versione è pronta per essere utilizzata per la produzione.

Fusione tra una già impegnata versione su un altro sviluppatori macchina sarà probabilmente mostrare i conflitti di unione con composer.lock.

Risolvere i conflitti di tutti gli altri file.
Il composer.lock il file deve essere eliminato.
Da qui, il flusso di lavoro è, come sopra, e cioè:
Lo sviluppatore dovrebbe essere in grado di eseguire composer update sulla sua macchina locale.
Essi dovrebbero essere in grado di rilevare se questo si rompe cose sulla sua macchina locale.
Se non è rotto… e così via.

Grazie per la tua risposta. Usiamo anche rigoroso controllo delle versioni per i nostri pacchetti e solo loro aggiornamento dopo il test in locale. Ho appena guardato e si può aggiornare il compositore.file di blocco facilmente eseguendo : $ compositore update –serratura in Modo che in questo modo siamo in grado di risolvere l’unione locale conflitti di compositore.bloccare Qualsiasi idea perché a tirare su il server a volte non riesce a causa di conflitti di fusione sul compositore.lock?
Il compositore.bloccare il file deve essere eliminato. Che ne dite di un nuovo pacchetto aggiunto? Eliminazione di compositore.blocco portare a perdita di lavoro da un altro sviluppatore.
Per gestire correttamente i conflitti di unione con il compositore.la serratura è difficile. Eliminare il file non, poiché questo si possono installare diverse versioni, da quello che altri gli sviluppatori stanno utilizzando. Il compositore.file di blocco è stato progettato per tenere traccia di quali versioni sono installati e devono essere impegnati a git. Vedi: blog.theodo.fr/2013/03/resolving-composer-merge-conflicts
anni dopo quella risposta era scritto, migliori pratiche di emergere. D’altra parte, i progetti di aggiornare regolarmente le loro dipendenze e di avere abbastanza prove per trovare la risultante bug sono meno probabilità di essere colpiti da un conflitto di unione, anche se il rullo compressore tattiche di eliminare il file di blocco durante il merge è applicato.
Se un pacchetto è stato aggiunto, dovrebbe essere in composer.json. Esecuzione di un aggiornamento completo, verrà creato un nuovo composer.lock file che include tutto, dalla composer.json.

InformationsquelleAutor Sven

2 Replies

11

Come si può verificare che un aggiornamento di base (o di qualsiasi altra dipendenza che viene aggiornato) non rompere le cose in progetti utilizzando, se lo sviluppatore non fare questo passo?

Ecco perché il solito flusso di lavoro è previsto il composer update essere eseguito su una macchina di sviluppo, di avere abbastanza RAM (cioè probabilmente più di 1GB di impostare come limite di memoria PHP), e l’aggiornamento dovrebbe essere attivato manualmente dal committente (e se attivato automaticamente da una continua integrazione di costruire, i requisiti di memoria di applicare per questa macchina).

Non vi è alcun modo per aggirare questo requisito di memoria. Un server web con solo 512 MB di RAM installata potrebbe essere in grado di funzionare come un server di gestione temporanea con a malapena qualsiasi concorrente utenti presenti, ma non dovrebbe essere utilizzato per aggiornare il Compositore dipendenze.

Personalmente posso risolvere i conflitti di unione in composer.lock con un sistema molto semplice: Eliminare il file di blocco ed eseguire composer update. Questo consentirà di aggiornare tutte le dipendenze per le ultime versioni che soddisfano i requisiti di versione, e creare un nuovo lavoro composer.lock file che si impegna durante la fusione.

Non ho paura di aggiornare potenzialmente tutto, perché funziona come previsto, o il mio test di cattura rapidamente gli errori.

Faccio selezionare la 3 ° festa di pacchetti che uso con attenzione:
- hanno per etichettare i loro versioni, preferibilmente utilizzando semantic versioning.
- Io non uso i rami per il rilascio di versioni (le rare volte che qualcuno li ha usati durante lo sviluppo sono state dolorose)
- dovrebbero spedire una versione nuova se fanno indietro modifiche incompatibili
- localmente sviluppati anche i pacchetti di seguire questi requisiti
Questo funziona con circa 270 pacchetti serviti da locale Satis istanza (probabilmente anche un fattore da considerare quando si cerca di ridurre l’ingombro di memoria – solo i pacchetti noto Compositore può finire in memoria: Confrontare le decine di migliaia di pacchetti potenzialmente disponibili su packagist.org con 270 pacchetti locali). 60 pacchetti di 270 sono sviluppati a livello locale da 20 sviluppatori, e in modo casuale il rilascio di nuove versioni. L’aggiornamento fallimenti negli ultimi 2 anni sono molto rari, e dovrebbe essere trattato come gli altri bug: Se una versione codificata è rilevato di essere incompatibile il rilascio di una versione di bugfix annullando i cambiamenti, e tag originale cambiare con una nuova major release, se incompatibile il cambiamento è necessario.

In modo che il flusso di lavoro si chiedono è probabilmente in questo modo:
- In qualsiasi momento, ogni sviluppatore dovrebbe essere in grado di eseguire composer update sulla propria macchina locale.
- Essi dovrebbero essere in grado di rilevare se questo si rompe le cose sulla propria macchina locale.
- Se non è rotto, commettere le modifiche tra cui l’ composer.lock file Git
- Il server di gestione temporanea viene eseguito solo composer install e utilizzare esattamente le versioni che lo sviluppatore usato la sua macchina.
- Se non è rotto sulla messa in scena, che versione è pronta per essere utilizzata per la produzione.
Fusione tra una già impegnata versione su un altro sviluppatori macchina sarà probabilmente mostrare i conflitti di unione con composer.lock.
- Risolvere i conflitti di tutti gli altri file.
- Il composer.lock il file deve essere eliminato.
- Da qui, il flusso di lavoro è, come sopra, e cioè:
- Lo sviluppatore dovrebbe essere in grado di eseguire composer update sulla sua macchina locale.
- Essi dovrebbero essere in grado di rilevare se questo si rompe cose sulla sua macchina locale.
- Se non è rotto… e così via.
Grazie per la tua risposta. Usiamo anche rigoroso controllo delle versioni per i nostri pacchetti e solo loro aggiornamento dopo il test in locale. Ho appena guardato e si può aggiornare il compositore.file di blocco facilmente eseguendo : $ compositore update –serratura in Modo che in questo modo siamo in grado di risolvere l’unione locale conflitti di compositore.bloccare Qualsiasi idea perché a tirare su il server a volte non riesce a causa di conflitti di fusione sul compositore.lock?
Il compositore.bloccare il file deve essere eliminato. Che ne dite di un nuovo pacchetto aggiunto? Eliminazione di compositore.blocco portare a perdita di lavoro da un altro sviluppatore.
Per gestire correttamente i conflitti di unione con il compositore.la serratura è difficile. Eliminare il file non, poiché questo si possono installare diverse versioni, da quello che altri gli sviluppatori stanno utilizzando. Il compositore.file di blocco è stato progettato per tenere traccia di quali versioni sono installati e devono essere impegnati a git. Vedi: blog.theodo.fr/2013/03/resolving-composer-merge-conflicts
anni dopo quella risposta era scritto, migliori pratiche di emergere. D’altra parte, i progetti di aggiornare regolarmente le loro dipendenze e di avere abbastanza prove per trovare la risultante bug sono meno probabilità di essere colpiti da un conflitto di unione, anche se il rullo compressore tattiche di eliminare il file di blocco durante il merge è applicato.
Se un pacchetto è stato aggiunto, dovrebbe essere in composer.json. Esecuzione di un aggiornamento completo, verrà creato un nuovo composer.lock file che include tutto, dalla composer.json.

InformationsquelleAutor Sven
2

Un altro approccio (senza fare composer update):
1. Copiare il nuovo (ed eliminare) le linee da composer.json in un file di testo separato.
2. Utilizzare tutto il remote composer.json e composer.lock file.
3. Durante il merge dei conflitti modalità:
  - composer install
  - Per ogni nuovo pacchetto di vostro annotato nel passaggio 1 eseguire composer require vendor/package:version
  - Per ogni pacchetto rimosso il annotato nel passaggio 1 eseguire composer remove vendor/package
4. Test!, Commettere, fatto!
In questo modo blocca da remoto ramo (forse master o develop rami), e solo rielabora i tuoi nuovi pacchetti.

InformationsquelleAutor Xover

Lascia un commento Annulla risposta

Devi essere connesso per inviare un commento.