Configurazione di un server di sviluppo

Question

Quando si sviluppano applicazioni PHP, è meglio avere un server su cui si sviluppa/test, quindi un server live si mette tutto quando è pronto.

OK, ma come?

Se si sta ospitando tramite una società di hosting, come è possibile configurare il proprio server di sviluppo per testare su ciò che imita tutte le impostazioni LAMP come server live? Perché se differiscono poi testare su uno che non è identico a quello vivo, sconfigge lo scopo giusto?

È meglio utilizzare un altro server tramite la stessa società di hosting e chiedere loro di effettuare sia lo sviluppo che i live con le stesse identiche impostazioni?

Inoltre, qual è il flusso di lavoro migliore da utilizzare per controllare i file da "server live" su di essi nel "server di sviluppo", quindi ricontrollarli nel server live?

Grazie !!

Answer 1

Due punti dal mio lavoro quotidiano:

• XAMPP è il vostro negozio one-stop per la creazione di uno stack Apache/MySQL/PHP su Windows. Sviluppo con esso e implementazione su macchine Linux, nessun problema.

• Se si vuole impostare un ambiente Linux su un server di casa o una macchina virtuale, ho fatto una domanda qualche tempo fa che potrebbero interessarti: Pre-installed Linux for Web Developers?

è meglio utilizzare un altro server attraverso la stessa società di hosting e chiedi loro di fare in modo che sia lo sviluppo sia i live abbiano le stesse identiche impostazioni?

Se ti puoi permettere un secondo server, potrebbe essere il modo migliore per andare. D'altra parte, una macchina locale è possibile aggiornare e giocherellare con la volontà, e tutto ciò ad una frazione del costo a lungo termine di un secondo server noleggiato. In caso di dubbio, andrei a prendere una macchina locale.

Non dimenticare che PHP è un linguaggio molto portatile. Se non si utilizzano strumenti da riga di comando specifici o estensioni totalmente esotiche, far funzionare un'applicazione PHP su Linux e anche su Windows è una questione di alcune impostazioni e dettagli, ma non è davvero un grosso problema.

Inoltre, qual è il flusso di lavoro migliore da utilizzare per controllare i file da "server live" su di essi nel "server di sviluppo", quindi ricontrollarli nel server live?

Ci sono molte, molte opinioni e pratiche in questo campo. Per me personalmente, il seguente flusso di lavoro si è rivelato ideale laddove l'ho usato - sono ancora in fase di implementazione da solo in tutti i progetti e per tutti i clienti.

1. Modificare i file localmente in IDE

2. Upload al server di sviluppo tramite funzione built-in FTP di IDE

3. di prova sul server di sviluppo

4. Una volta che una funzione è testato e funziona sul server di sviluppo (cioè è "finito"), controllare l'intero pacchetto in un repository Subversion (o altro)

5. Sul server live, fare in modo che uno script di build controlli l'ultima revisione dal repository, scaricalo in una directory con il numero di revisione e, al termine, modificare un collegamento simbolico che punta alla revisione precedente a quella più recente.

In questo modo, ogni modifica apportata per l'ambiente dal vivo viene registrato nel sistema di controllo versione, e tornando alla revisione precedente è una domanda se secondi. Per me, questo è stato un enorme sollievo rispetto a lavorare con FTP puro ovunque.

Forse anche interessante domanda: Setting up a deployment/build/CI cycle for PHP projects

Answer 2

È possibile controllare tutti i setup del server di produzione tramite phpinfo() e copiarli sul vostro ambiente di sviluppo, non c'è bisogno per loro di essere sullo stesso fornitore.

In genere, eseguo il commit del codice per il controllo del codice sorgente e il checkout nell'ambiente di produzione, nascondendo tutte le informazioni del repository tramite .htaccess, ad esempio, vedere here.

Un'altra opzione (meno consigliata) è quella di avere solo la fonte principale nella macchina di sviluppo, e una volta che è pronta per l'FTP, ci sono vari strumenti gratuiti che caricheranno solo i file modificati.

Answer 3

Per quanto riguarda il lato server, si hanno più possibilità. È possibile utilizzare vhost quando si dispone di Apache, con due DocumentRoot diversi: uno per la versione live e uno per lo sviluppo. Oppure puoi avere l'ambiente di sviluppo sul tuo computer locale e poi il live (+ staging) sul tuo server/spazio web dedicato.

Nel nostro progetto attuale abbiamo un sistema a tre livelli:

sviluppo, messa in scena e vivere. La messa in scena e il live sono praticamente la stessa cosa, quindi posso eliminare qualsiasi problema durante il roll out da dev alla messa in scena. Mi dà un altro livello di sicurezza prima di uscire per vivere e alla fine di notare che qualcosa è andato storto.

Considerando il flusso di lavoro per il roll out, è necessario creare una configurazione dell'applicazione, in cui è possibile definire diversi ambienti applicativi (sviluppo e produzione) che scelgono automaticamente il proprio ambiente in base a URL, variabili d'ambiente definite o altro. Quindi, in Zend Framework, ad esempio, questo comportamento guidato dalla configurazione è integrato nelle tue applicazioni. Nel file config.ini, si dispone di un modello che assomiglia a questo:

[production] 

[staging : production] 

[testing : production] 

[development : production] 

Lì è possibile definire diverse opzioni per, permette di dire, la connessione al database vale a dire

Quindi quando si controllano le modifiche sulla macchina di sviluppo in subversion e si esegue un'implementazione nel sistema live, non è necessario modificare la configurazione. Dovrebbe funzionare.

Answer 4

Per quanto riguarda il flusso di lavoro, in genere ciò che accade per i siti di piccole dimensioni. A seconda delle dimensioni del progetto, tuttavia, potrebbe essere una buona idea usare il controllo di versione come Git o Subversion.

Answer 5

Non è necessario andare da nessuna parte per chiedere a una società di hosting di configurare due identici ambienti di hosting. La maggior parte delle volte hanno versioni aggiornate di php, mysql e apache. Sviluppo su una macchina Linux, che ha già un setup di stack di lampade, quindi il mio flusso di lavoro è piuttosto semplice e io uso un svn con ganci post-commit da caricare sul server live. Se siete preoccupati per le incompatibilità tra sei server 'dev' e il server che ospita, la cosa più facile da fare è creare un file phpinfo,

<?php phpinfo(); ?> 

e verificare che il server di hosting non vieta eventuali funzioni speciali si utilizza sul proprio server di sviluppo (e questo è piuttosto raro che la società di hosting blocchi le cose vitali, e se lo fanno si può facilmente inviare un'e-mail di supporto e il 99% delle volte ti assisterà per abilitare qualsiasi informazione tu richieda. Per quanto riguarda la configurazione del tuo ambiente di sviluppo, scenderò la traccia di afferrare virtualbox e installare Ubuntu, trovare un tutorial per rendere ubuntu un server web (solo pochi comandi apt-get) e fumerai con il gas!