Il controllo del codice sorgente ha delle disposizioni per impedire al vecchio codice di sovrascrivere un nuovo codice?

1

Sono sicuro che esiste già una domanda simile, ma non ne ho visto uno che fosse abbastanza vicino, quindi ecco qui ...

  • Usiamo una società di terze parti per ospitare il nostro sito e fare la maggior parte degli aggiornamenti del codice e il codice viene mantenuto in un repository Git. Tuttavia, non siamo stati molto contenti del lavoro che hanno svolto, quindi abbiamo esternalizzato sempre più progetti ad altre società.
  • Queste altre società gestiscono i propri server di staging e inviamo loro versioni aggiornate del codice sorgente e del database il più frequentemente possibile, ma nella maggior parte dei casi non avviano sempre ogni progetto con l'ultima versione assoluta di entrambi.
  • A causa di un arretrato, di recente abbiamo riscontrato un problema per il quale un progetto presentato da quella società non è arrivato al nostro server di gestione temporanea fino a circa un mese dopo la sua presentazione. Quindi, quando questi file sono stati copiati sul server di staging, il file utilizzato dal resto dell'applicazione era di circa un mese e nel frattempo vi erano stati alcuni aggiornamenti.
  • Quindi, quando questo file è andato al server di staging, molti degli aggiornamenti recenti non erano presenti e la funzionalità messa in produzione non era presente nella gestione temporanea. Alcune delle funzionalità mancanti non erano immediatamente ovvie perché dovevi essere in una certa modalità per notare che mancava, quindi non è stato rilevato immediatamente.
  • Vorrei anche ricordare che anche prima che le società esterne iniziassero a lavorare sui progetti, questo era ancora un problema. Il vecchio codice sostituiva spesso gli aggiornamenti più recenti e quindi dovremmo pagare questa azienda per correggere il problema e ripristinare il lavoro che era già stato completato.

Ovviamente, i siti su cui lavorano più sviluppatori devono affrontare questo problema su base continua. È un caso in cui la società che controlla il processo utilizza una metodologia discutibile o non c'è davvero un buon modo per evitare che ciò accada? Mi sento come se fossi bloccato in una versione Twilight Zone della canzone Springsteen "One Step Forward, Two Steps Back".

Grazie in anticipo per eventuali risposte. Molto apprezzato!

    
posta user3561924 05.08.2016 - 01:48
fonte

1 risposta

2

La maggior parte dei sistemi di controllo delle versioni ha il requisito che il codice sia aggiornato prima che le modifiche possano essere applicate. Sembra che la tua azienda stia aggirando i miei file sostitutivi anziché applicare le patch.

Se non autorizzi l'accesso al controllo della versione, dovresti accettare le patch piuttosto che i file sostitutivi. Non è raro avere un repository pubblico secondario (ish) che può essere sincronizzato con. Le modifiche approvate / verificate vengono quindi inserite nel repository di rilascio.

Sembra che tu stia utilizzando GIT, quindi le altre società dovrebbero estrarre le modifiche dal tuo repository. Dovrebbero spingere le versioni a te come patch. Con GIT, è necessario risolvere i conflitti prima di applicare le modifiche.

Alcuni argomenti con cui dovresti familiarizzare:

  • Flussi di lavoro per la versione che controlla il codice sorgente.
  • Le pratiche di lavoro GIT standard
  • Strategie di ramificazione
  • Tecniche di versioning per dati binari.

Per evitare conflitti prima di premere le modifiche, è necessario estrarre le modifiche dal repository remoto. (Questo è il controllo aggiornato.). Eventuali conflitti sono quindi locali e devono essere risolti localmente. Fino a quando non vengono risolti, non puoi spingere le tue modifiche. Altri sistemi di controllo di revisione gestiscono diversamente, ma generalmente richiedono una copia aggiornata dei file da modificare prima di inviare / confermare le modifiche. È comunque possibile sostituire i file con la propria versione, perdendo qualsiasi altra modifica verificatasi da quando è stata ottenuta. In questo caso, puoi ancora trovare tutte le modifiche perse nel repository e preparare una patch.

Uso un flusso di lavoro include l'aggiornamento frequente della mia copia dell'origine (giornaliera o al massimo settimanalmente). Ciò garantisce che il mio codice incorpori qualsiasi altra modifica. Riduce anche la finestra per l'introduzione di conflitti.

Quando si utilizza il controllo di revisione, i conflitti del codice sorgente tendono ad essere relativamente rari in quanto le modifiche sono in genere a file diversi o almeno a posizioni diverse nel file. Di conseguenza, la patch verrà applicata senza problemi. Un sottoinsieme di conflitti consiste nello stesso cambiamento applicato allo stesso codice da due diversi sviluppatori. Se la formattazione è identica, verrà applicata la patch, ignorando la modifica applicata.

    
risposta data 05.08.2016 - 03:53
fonte

Leggi altre domande sui tag