Qual è il modo migliore per pubblicare in modo sicuro un sito dopo la creazione?
-
09-06-2019 - |
Domanda
Quindi, secondo la tua esperienza, qual è il modo migliore?Esiste un modo sicuro che sia anche scrivibile/attivabile in uno strumento di automazione della build?
Modificare:Dovrei menzionare che questo è Windows/.net e lo distribuirò su iis6
Soluzione
Per alcuni progetti utilizzo Capistrano spingere fuori per vivere.È costruito su Ruby e rende estremamente semplice la scrittura di script e utilizza ssh.
Su altri progetti ho una piccola app di distribuzione che utilizza bash per eseguire un'esportazione svn in una directory temporanea e quindi sincronizzarla sul server live.Puoi fare in modo che rsync usi ssh.
Preferisco di gran lunga il metodo Capistrano, anche se il tuo progetto non è in ruby/rails.
Altri suggerimenti
@Neall, aggiungerei un set -e
sulla seconda riga, perché non vuoi che il sito live venga sostituito se il file rsync
fallisce per qualsiasi motivo. set -e
fa sì che lo script venga chiuso se uno qualsiasi dei suoi comandi fallisce.
Modificare:IL set -e
dovrebbe essere la prima cosa nella sceneggiatura, subito dopo #!/bin/bash
.
Crea una copia della directory del tuo sito live, utilizza rsync per aggiornare quella copia con la versione più recente, quindi rinominare le directory live e aggiornate in modo che la versione aggiornata sia ora attiva.
In bash:
#!/bin/bash
set -e
cp -R /var/livesite /var/newversion
rsync user@devserver:/var/readytogolive /var/newversion
mv /var/livesite /var/oldlivesite
mv /var/newversion /var/livesite
Viola!
Modificare:@Ted Percival - È una buona idea.Non sapevo nemmeno di "set -e".Scritta aggiornata.Modificare:aggiornato di nuovo su suggerimento di Ted (anche se penso che funzionerebbe comunque se in qualche modo il comando cp fallisse, e se cp fallisce probabilmente avrai problemi più seri.)
Asseconderò la raccomandazione per Capistrano, anche se se stai cercando una soluzione basata sulla GUI potresti provare il file Webistrano fine frontale.Semantica di rollback e distribuzione pulita, basata su ssh e sensata, scripting semplice ed estensibilità tramite Ruby.
Potresti sempre scrivere una piccola app client/server che crittografa all'origine, invia i file e quindi decrittografa alla destinazione.È un po' di lavoro, ma probabilmente una quantità irrisoria.Ed è scrivibile fintanto che il tuo strumento di automazione supporta l'esecuzione di qualcosa nel file system (cosa che penso facciano tutti).
L'unico svantaggio è che potresti non essere in grado di ricevere messaggi di errore significativi in caso di errore nel tuo ambiente di integrazione senza un po' più di lavoro da parte tua (anche se, a seconda della configurazione, questo potrebbe essere semplice come inviare messaggi di errore a stdout).
hm, da queste parti utilizziamo un "server" di staging a scopo di test sull'ambiente live (in realtà, è un host virtuale Apache sul server di produzione) e araxis si fondono (uno strumento di confronto dei file riga per riga davvero intelligente) per sincronizzare lo sviluppo e la gestione temporanea.
una volta testato, basta;sostituisci i file sulla webroot di produzione :)
/mp
In un lavoro freelance che ho svolto, abbiamo creato tre ambienti separati.
- Un server di sviluppo eseguito continua a creare utilizzando CruiseControl.Qualsiasi check-in attiverebbe una build.Il test QA è stato eseguito qui.
- Un server di test su cui è stato eseguito il test di accettazione dell'utente.
- Produzione.
Il flusso di lavoro è stato il seguente:
- Lo sviluppatore archivia le modifiche in SourceControl.
- CruiseControl crea e distribuisce la build a Dev.
- Dev è sottoposto al QA
- Dopo aver superato il QA, viene eseguito uno script Robocopy che distribuisce la build Dev al test.
- Il test è UAT
- Una volta superato il test, viene eseguito uno script robocopy che distribuisce Test su PRD.