Come iniziare a distribuire applicazioni PHP da un repository di sovversione?

https://stackoverflow.com/questions/800294

03-07-2019
|

Domanda

Ho sentito la frase "distribuire applicazioni" che suona molto meglio / più facile / più affidabile rispetto al caricamento di singoli file modificati su un server, ma non so da dove cominciare.

Ho un'applicazione Zend Framework che è sotto controllo di versione (in un repository Subversion). Come posso procedere con " distribuzione " la mia applicazione? Che cosa devo fare se ho un " uploads " directory che non voglio sovrascrivere?

Ospito la mia applicazione tramite una terza parte, quindi non conosco molto altro che FTP. Se una di queste operazioni comporta l'accesso al mio server, spiegare la procedura.

Soluzione

La distribuzione automatica + l'esecuzione dei test su un server di gestione temporanea è nota come integrazione continua. L'idea è che se effettui il check in qualcosa che interrompe i test, verrai avvisato immediatamente. Per PHP, potresti voler esaminare Xinc o phpUnderControl

In genere non vorrebbe comunque essere distribuito automaticamente alla produzione. La cosa normale da fare è scrivere alcuni script che automatizzano l'attività, ma che è comunque necessario avviare manualmente. Puoi usare framework come Phing o altri strumenti di compilazione per questo (una scelta popolare è Capistrano ), ma puoi anche sbattere insieme alcuni script di shell. Personalmente preferisco quest'ultimo.

Gli script stessi potrebbero fare cose diverse, a seconda dell'applicazione e della configurazione, ma un processo tipico sarebbe:

ssh sul server di produzione. Il resto dei comandi viene eseguito sul server di produzione, tramite ssh.
esegui svn export svn: // path / to / repository / tags / RELEASE_VERSION / usr / local / application / release / TIMESTAMP
servizi di arresto (Apache, demoni)
esegui unlink / usr / local / application / current & amp; & amp; ln -s / usr / local / application / release / TIMESTAMP / usr / local / application / current
esegui ln -s / usr / local / application / var / usr / local / application / release / TIMESTAMP / var
esegui /usr/local/application/current/scripts/migrate.php
avvia servizi

(Supponendo che tu abbia la tua applicazione in / usr / local / application / current )

Altri suggerimenti

Non consiglierei l'aggiornamento automatico. Solo perché i test delle unità superano non significa che l'applicazione funziona al 100%. Cosa succede se qualcuno esegue il check-in in una nuova funzionalità casuale senza alcun nuovo test unitario e la funzionalità non funziona? I test delle unità esistenti potrebbero passare, ma la funzionalità potrebbe essere interrotta comunque. I tuoi utenti potrebbero vedere qualcosa che è a metà. Con la distribuzione automatica da un check-in, potresti non notare per alcune ore se qualcosa lo ha reso live che non avrebbe dovuto.

In ogni caso, non sarebbe così difficile avviare una distribuzione automatica se davvero lo desideri. Avresti bisogno di un hook post-check-in, e in realtà i passaggi sarebbero:

1) Esporta dall'ultimo check-in 2) Carica l'esportazione sul server di produzione 3) Disimballare / configurare l'esportazione appena caricata

Ho sempre eseguito gli ultimi passaggi manualmente. Generalmente è semplice come esportare SVN, comprimere, caricare, decomprimere, configurare e gli ultimi due passaggi che ho appena alias un paio di comandi bash per eseguire. Quindi sostituisco la directory dell'app root con quella nuova, assicurandomi di conservare quella vecchia come backup ed è buona norma.

Se sei sicuro della tua capacità di rilevare errori prima che vadano automaticamente in diretta, puoi provare ad automatizzare quella procedura. Mi dà però il jibbly-jibblies.

Ecco un eccellente articolo sull'uso di Subversion per distribuire progetti web & # 8212; risponde a molte delle tue domande.

http://athleticsnyc.com/blog/entry/ on-con-la sovversione-per-progetti web

Nella mia azienda webdev abbiamo recentemente iniziato a utilizzare Webistrano , che è una GUI Web per il popolare Capistrano strumento.

Volevamo uno strumento di implementazione rapido e facile da usare con un'interfaccia centralizzata, responsabilità (chi ha distribuito quale versione), rollback a versioni precedenti e preferibilmente gratuito. Capistrano è noto come strumento di distribuzione per le applicazioni Ruby on Rails, ma non centralizzato e destinato principalmente alle app Rails. Webistrano lo migliora con una GUI, responsabilità e aggiunge il supporto di base per la distribuzione di PHP (usa il tipo di progetto 'file puro').

Webistrano è esso stesso un'app Ruby on Rails, che si installa su un server di sviluppo o di gestione temporanea. Aggiungi un progetto per ciascuno dei tuoi siti Web. Ad ogni progetto aggiungi fasi, come Prod e Dev.

Ogni stage può avere server diversi su cui distribuire e impostazioni diverse. Scrivi (o modifica) una 'ricetta', che è uno script ruby ??che dice a capistrano cosa fare. Nel nostro caso ho appena usato la ricetta fornita e ho aggiunto un comando per creare un collegamento simbolico a una directory condivisa per i caricamenti, proprio come hai menzionato.

Quando si fa clic su Distribuisci, Webistrano SSH nei server remoti, esegue un checkout svn del codice e qualsiasi altra attività richiesta, come migrazioni del database, collegamento simbolico o pulizia delle versioni precedenti. Tutto ciò può essere modificato ovviamente, dopo tutto, è semplicemente scritto.

Siamo molto contenti, ma mi ci sono voluti alcuni giorni per imparare e configurare, soprattutto perché non avevo familiarità con Ruby e Rails. Tuttavia, posso consigliarlo caldamente per l'uso in produzione nelle piccole e medie imprese, dal momento che si è dimostrato molto affidabile, flessibile e ci ha risparmiato molte volte l'investimento iniziale. Non solo accelerando le implementazioni, ma anche riducendo errori / incidenti.

Questo genere di cose è ciò che chiameresti "integrazione continua". Atlassian Bamboo (costo), Sun Hudson (gratuito) e Cruise Control (gratuito) sono tutte opzioni popolari (in ordine delle mie preferenze) e hanno il supporto per gestire l'output di PHPUnit (perché PHPUnit supporta l'output di JUnit).

Le cose di distribuzione possono essere fatte con un trigger post build. Come alcune altre persone su questo thread, farei molta attenzione prima di fare distribuzioni automatiche al check-in (e test di superamento).

controlla fredistrano, è un clone capistrano funziona alla grande (installazione un po 'confusa ma dopo tutto funziona alla grande)

http://code.google.com/p/fredistrano/

Per gestire i caricamenti, la soluzione classica è quella di spostare la directory reale fuori dallo spazio web principale, lasciandola solo per una versione nuova da verificare (come faccio nello script seguente) e quindi usando Apache su 'Alias' torna al suo posto come parte del sito Web.

Alias /uploads /home/user/uploads/

Ci sono meno scelte se non si ha lo stesso controllo del server.

Ho uno script che uso per distribuire un determinato script sui siti dev / live (entrambi funzionano sullo stesso server).

#!/bin/sh

REV=2410
REVDIR=$REV.20090602-1027

REPOSITORY=svn+ssh://topbit@svn.example.com/var/svn/website.com/trunk
IMAGES=$REVDIR/php/i
STATIC1=$REVDIR/anothersite.co.uk

svn export --revision $REV  $REPOSITORY $REVDIR

mkdir -p $REVDIR/tmp/templates_c
chown -R username: $REVDIR
chmod -R 777       $REVDIR/tmp $REVDIR/php/cache/
chown -R nobody:   $REVDIR/tmp $REVDIR/php/cache/ $IMAGES
dos2unix $REVDIR/bin/*sh  $REVDIR/bin/*php
chmod 755 $REVDIR/bin/*sh $REVDIR/bin/*php

# chmod -x all the non-directories in images
find $IMAGES -type f -perm -a+x | xargs -r chmod --quiet -x
find $STATIC1 -type f -perm -a+x | xargs -r chmod --quiet -x

ls -l $IMAGES/* | grep -- "-x"

rm dev && ln -s $REVDIR dev

Ho inserito il numero di revoca e la data / ora utilizzati per il nome della directory di check-out. I chmod nel mezzo rendono anche i permessi sulle immagini sono OK in quanto sono anche collegati al nostro server di immagini dedicato.

L'ultima cosa che succede è un vecchio link simbolico ... / website / dev / viene ricollegato alla directory appena estratta. La configurazione di Apache ha quindi una radice doc di ... / website / dev / htdocs /

C'è anche una corrispondenza ... / website / live / htdocs / docroot e, di nuovo, "live" è un altro collegamento simbolico. Questo è il mio altro script che rimuoverà il link simbolico live e lo sostituirà con qualunque cosa dev punti a.

#!/bin/sh
# remove live, and copy the dir pointed to by dev, to be the live symlink
rm live && cp -d dev live

Sto solo inviando una nuova versione del sito ogni pochi dati, quindi potresti non voler utilizzare questo più volte al giorno (la mia cache APC non vorrebbe più di alcune versioni del sito in giro), ma per me trovo che questo sia molto privo di problemi per la mia distribuzione.

Dopo 3 anni, ho imparato qualcosa sulle migliori pratiche di implementazione. Attualmente uso uno strumento chiamato Capistrano perché è facile da configurare e utilizzare e gestisce bene molte impostazioni predefinite.

Le basi di un processo di distribuzione automatizzata sono le seguenti:

Il tuo codice è pronto per la produzione, quindi è taggato con la versione della versione: v1.0.0
Supponendo che tu abbia già configurato lo script di distribuzione, esegui lo script, specificando il tag appena creato.

Lo script SSH si trova sul tuo server di produzione che ha la seguente struttura di directory:

/your-application
    /shared/
        /logs
        /uploads
    /releases/
        /20120917120000
        /20120918120000  <-- latest release of your app
            /app
            /config
            /public
            ...etc
    /current --> symlink to latest release

Your Apache document root should be set to /your-application/current/public

Lo script crea una nuova directory nella directory dei rilasci con il datetime corrente. All'interno di quella directory, il tuo codice viene aggiornato con il tag specificato.
Quindi viene rimosso il collegamento simbolico originale e viene creato un nuovo collegamento simbolico, che punta all'ultima versione.

Le cose che devono essere mantenute tra le versioni vanno nella directory condivisa e i collegamenti simbolici vengono creati per quelle directory condivise.

Dipende dalla tua applicazione e dalla solidità dei test.

Dove lavoro tutto viene controllato nel repository per la revisione e quindi rilasciato.

L'aggiornamento automatico da un repository non sarebbe intelligente per noi, poiché a volte effettuiamo il check-in in modo che altri sviluppatori possano estrarre una versione successiva e unire lì le modifiche.

Per fare ciò di cui stai parlando avrebbe bisogno di una sorta di check in e out secondario per consentire la collaborazione tra gli sviluppatori nell'area del check in primario. Anche se non ne so nulla o se è addirittura possibile.

Esistono anche problemi con la ramificazione e altre funzionalità simili che dovrebbero essere gestite.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow