Alternativa alla codifica direttamente sul server? [duplicare]

12

Abbiamo un grande sito Web realizzato in PHP in esecuzione su Apache su Linux. Ci sono programmatori e utenti non tecnici che modificano il sito ogni giorno e lo facciamo direttamente sul server di prova.

C'è qualche alternativa alla modifica dei file direttamente sul server?

Certo, i programmatori potrebbero configurare un'istanza Apache sulla loro macchina e gestirla, ma è un po 'problematico, dato che a volte aggiungiamo nuove estensioni a PHP o cambiamo configurazione in Apache, il che significa che tutti hanno bisogno di cambiarle manualmente. Inoltre, non è realistico aspettarsi che i nostri utenti non tecnici gestiscano la propria istanza di Apache.

Un altro problema è che siamo tutti su computer Windows, ma il sito web funziona sotto Linux. Il codice non è compatibile con Windows, quindi questo è un altro problema. Passare completamente a Linux non è un'opzione, dato che stiamo utilizzando molti programmi che funzionano solo su Windows per altre attività, quindi dovrebbe essere un dual boot o una VM.

Sembra strano lavorare tutti direttamente sul server, ma è il modo migliore per farlo nel nostro caso?

    
posta Gudradain 05.11.2015 - 23:53
fonte

5 risposte

54

Tutti coloro che modificano l'applicazione dovrebbero farlo nel controllo del codice sorgente e si dovrebbe avere un processo automatico per la distribuzione di una versione specifica dal controllo del codice sorgente al server di test. Potrebbe richiedere un po 'di persuasione per far sì che le persone non tecniche usino il controllo del codice sorgente, ma in realtà non è un'alternativa al mantenimento affidabile di un sistema non giocattolo. Se il passaggio per il check-in e l'implementazione del codice è abbastanza semplice, non importa che nessuno lavori direttamente sul server. Alla gente piace usare git per questo perché git è veloce e ha sviluppato un ecosistema di buoni strumenti per l'utente finale. Avere persone che lavorano direttamente sul server è una ricetta per il disastro.

    
risposta data 06.11.2015 - 00:02
fonte
19

Usa vagabondo per configurare l'ambiente che rispecchia le impostazioni sul server e lasciale giocare lì.

Come tornare al server, si tratta di implementazione, a questa parte viene data una risposta soddisfacente da @antlersoft, con l'avvertenza: non credo che si possa convincere gli utenti non tecnici a usare il controllo del codice sorgente (e git è uno di quelli più duri). Se hai bisogno di utenti non tecnici per cambiare web, investi tempo e denaro per trovare il CMS appropriato e usarlo.

    
risposta data 06.11.2015 - 00:08
fonte
11

Una flotta di macchine virtuali su un host, ogni utente ha la sua istanza con cui giocare, quindi spingere da lì al repository principale e fare il vero aggiornamento del server di test da lì.

Non provare a introdurre git a utenti non tecnici, potresti finire con un'ascia nella tua testa un giorno. :-) Anche per alimentare gli sviluppatori che lo usano ogni giorno aggiunge un tale livello di complessità che falliscono. Strumenti come SourceTree sono belli, ma non ti impediscono di rovinare.

Il controllo della versione più intuitivo che ho sperimentato finora è TortoiseSVN, anche gli utenti non tecnici comprendono i comandi svn up e svn commit quando vengono presentati in un'interfaccia grafica pulita.

    
risposta data 06.11.2015 - 03:52
fonte
10

La risposta al tuo problema è duplice.

TL; DR: Usa DTAP e implementa un VCS.

In primo luogo, in un ambiente aziendale mai vuoi essere codificato direttamente sul server. Anche se non è l'ambiente live, avere più persone che modificano i file nello stesso ambiente ti dà una possibilità molto alta di modifiche in conflitto, il che porta a risultati imprevedibili. L'implementazione completa di DTAP ti aiuterà a risolvere questo problema.

DTAP sta per "Sviluppo, test, accettazione, produzione" e viene utilizzato per descrivere un sistema in cui ci sono 4 posizioni separate in cui il codice può essere. La separazione è progettata per proteggere la produzione dal maggior numero possibile di problemi:

Prima il codice viene eseguito e testato su Sviluppo (che può essere una macchina separata ma spesso è semplicemente il PC dello sviluppatore). Se lo sviluppatore è soddisfatto del suo lavoro, il codice passa all'ambiente Test, dove qualcun altro (idealmente un tester dedicato ma un altro sviluppatore può lavorare) proverà il codice. Se questa fase di test non rileva problemi, il codice passa a Acceptance, dove il lato "business" dell'azienda testerà il codice. Questo può essere il tuo cliente se la tua azienda produce un prodotto per un'altra parte o può essere un reparto diverso che è in contatto con ciò che il prodotto dovrebbe fare per soddisfare le esigenze dei clienti finali. Solo se accettano il codice, il codice passerà all'ambiente di produzione, che è l'ambiente live.

In secondo luogo, per tenere traccia delle modifiche e prevenire i problemi che sorgono quando più persone modificano la stessa area del codice allo stesso tempo, è necessario implementare un VCS (Sistema di controllo versione) nella propria organizzazione che terrà traccia di tutte le modifiche a tutti i file (gli esempi sono SVN, Git e Mercurial). Questi sistemi ti consentiranno anche di eseguire il rollback delle modifiche se si scopre di aver fatto un errore. Per semplificarti la vita, potrebbe valere la pena utilizzare il tuo sistema di scelta con un account in un servizio come Bitbucket che ti consentirà di utilizzare la loro interfaccia per il processo di combinazione del lavoro di uno sviluppatore con un altro. Tutti i tuoi sviluppatori dovranno concordare la strategia specifica da utilizzare per unire il codice nello stato che passerà dallo sviluppo al prossimo ambiente, ma non sovraccaricherò la mia risposta.

Quando dici che le persone non tecniche stanno modificando l'ambiente di test, spero che intendi che apportano modifiche alla configurazione e / o al contenuto, non ai file reali. Le persone non tecniche dovrebbero mai toccare il codice del sito web, dopotutto se non hanno idea di quello che stanno facendo potrebbero accidentalmente rompere qualcosa!

Per quanto riguarda la questione della compatibilità e l'affermazione che le persone non tecniche non possono aspettarsi di mantenere il proprio server Apache, ci sono diverse opzioni che posso vedere. Un'opzione è avere una persona che gestisca l'installazione di questi server per tutte le parti coinvolte, ma questo può essere un lavoro a tempo pieno e potrebbe non essere adatto alla tua organizzazione per avere una tale persona. L'alternativa è usare uno degli strumenti disponibili come Vagrant o Docker, che consentirà a una persona tecnica di creare una "immagine" che avrà l'ambiente di lavoro (che sarà tipicamente basato su Linux) e che l'immagine può essere distribuita a tutti sviluppatori in modo che possano eseguirlo sul proprio computer. Se è necessario apportare aggiornamenti all'architettura, questa persona aggiorna l'immagine e la distribuisce nuovamente agli sviluppatori.

Parere personale: Dal post originale deduco che la tua azienda ha superato lo stato di "solo 2 persone stanno lavorando sul sito comunque, quindi non importa quello che facciamo". Questi concetti che propongo sono ampiamente accettati come buone pratiche, come potete vedere dalla mia spiegazione otterrete MOLTI controlli aggiuntivi sulla qualità del prodotto, al compromesso dell'introduzione di una complessità aggiuntiva relativamente piccola al vostro processo. Un sistema di controllo della versione come Git o Mercurial può sembrare intimidatorio, ma a mio avviso, con un po 'di formazione letteralmente chiunque può imparare come lavorarci correttamente. Tutto ciò che richiede è un atteggiamento di volontà da apprendere invece di vedere il sistema come un nemico che ti impedisce di portare a termine il tuo lavoro, l'ultimo dei quali è purtroppo molto più comune di quanto dovrebbe essere. Imparando a utilizzare correttamente lo strumento, risparmierai il tempo che dovresti dedicare a correggere gli errori e ad ordinare manualmente come il lavoro di più persone debba essere combinato nel codice.

    
risposta data 06.11.2015 - 12:21
fonte
3

Prima di tutto, il controllo della versione è obbligatorio. Ma inoltre è necessario testare qualsiasi modifica prima che vengano commessi. E per quelle modifiche ogni utente ha bisogno del proprio ambiente di test. Quindi la codifica diretta su il server non è una buona idea.

Quanta separazione hai bisogno tra l'ambiente di test di ciascun utente dipende dalle tue esigenze specifiche. Per alcune semplici attività è possibile ottenere una separazione sufficiente avendo un server di test condiviso che esegue un vhost per utente. Se hai bisogno di più separazione, puoi configurare un VPS per utente.

Per le attività più impegnative potresti aver bisogno di una macchina fisica dedicata per utente. Se ciò significa che è necessario acquistare un'altra macchina fisica per alcuni utenti, è necessario decidere se si desidera che l'altra macchina si trovi sulla scrivania dell'utente o su un rack del server.

Ho visto che gli utenti commettono errori in ogni sistema di controllo delle versioni con cui ho mai lavorato. Alcune persone sono in grado di imparare a lavorare correttamente con un sistema di controllo delle versioni, altre no. Se hai persone non tecniche che hanno bisogno di cambiare parte della base di codice, ma non possono imparare come usare il controllo di versione, c'è un'altra opzione che vale la pena considerare.

Puoi consentire agli sviluppatori di accedere alle macchine di prova della persona non tecnica (come login della shell o tramite un file system di rete), in modo tale che una volta che una modifica sia pronta, la persona non tecnica può chiedere a uno sviluppatore di impegnarsi il cambiamento.

    
risposta data 06.11.2015 - 13:19
fonte

Leggi altre domande sui tag