it-swarm-eu.dev

Můžete doporučit způsoby správy nasazení kódu na webový server se systémem Linux?

K nasazení kódu jsem vždy používal velmi jednoduchý bash skript. Přecházím od používání Subversion k Mercurialu, ale nemyslím si, že by revizní řídicí software byl důležitý pro nasazení.

Jaké jsou lepší způsoby, jak toho dosáhnout?

#!/bin/sh
date=`date +%Y%m%d_%H%M%S`
tar -zcvf app-dir-$date.tar.gz app/dir 
tar -zcvf app-templates-$date.tar.gz app/templates
tar -zcvf app-media-$date.tar.gz app/media
svn export http://example.com/somepath/trunk hh/ --force
7
citadelgrad

Používám Mercurial ke správě všeho , včetně mých statických HTML stránek. Život je pro mě opravdu snadný.

Výhody zahrnují

  • Všechny nabídky pro správu verzí (vrácení zpět, značky milníků atd.)
  • Spěchat klonování vašich stránek
  • Vždy máte funkční místní zálohu/kopii
  • Snadná synchronizace, pokud máte sklon provádět změny na místě (na místě, na serveru)
  • Většina sdílených hostitelů (pokud s nimi jednáte) nevadí instalace

Zřeknutí se odpovědnosti, napsal jsem návod. Ano, na druhu VCS, do jaké míry používáte, záleží. Například bych v tomto scénáři nepoužil něco, kde bych se nemohl místně zavázat a udělat jeden velký push/update. To mě jen nutí soustředit příliš mnoho potenciálně problematických změn do jednoho závazku.

jsem to mohl udělat s Subversion a já vůbec ne klepe na SVN. Jen si myslím, že Mercurial je mnohem lepší nástroj pro problém, který se snažíte vyřešit.

Je to můj názor, že byste neměli „obcházet“ své nástroje, pokud nemáte jinou možnost. Dělá to tak, že poráží účel, který má, a máte na výběr :)

5
Tim Post

Kromě vynikajících návrhů v ostatních odpovědích můžete zvážit, zda je pro vás důležité provést atomovou aktualizaci.

Na mém serveru FreeBSD to dosáhnu dvěma mechanismy:

  • Vytváření verzí všech mých statických zdrojů. (Např. http://static.example.com/images/logo.1.png nebo http://static.example.com/style/main.3.css). To mi umožňuje svn update statický web přímo před aktualizací dynamického webu bez obav, že uživatelé uvidí nové soubory na starých stránkách.

  • Verze celého dynamického webu. V mém případě mám kořen dokumentu směřující na symbolický odkaz. Moje strategie je dostat novou verzi výroby na místo a poté jediným příkazem Push it live. .G. něco takového:

    cp -Rp www.site1.com.1 www.site1.com.2 (nebo svn checkout)

    svn update site1.com.2 (možná bude potřeba nejdříve svn switch)

    ln -sf site1.com.2 www.site1.com (atomicky přesunout změny do výroby)

To zajišťuje, že žádný z mých uživatelů nakonec neuvidí napůl pečenou stránku. Budou vidět starou verzi, pokud je stále v mezipaměti, nebo novou.

Tato strategie funguje dobře, pokud nemícháte obsah nahraný uživateli s dynamickým webem.

1
JasonBirch

Používáme mravence scp task , s modifikovaný selektor . To znamená, že pouze aktualizujete soubory, které se změnily od předchozího nahrání. Bohužel se zdá, že upravený selektor je určen pouze pro osobní použití, nikoli ke sdílení se členy týmu. Soubor cache.properties obsahuje názvy cest k pracovnímu adresáři uživatele v něm. Napsali jsme spoustu mraveneckých cílů, abychom masírovali soubor cache.properties do formátu, který je možné sdílet mezi vývojáři, a poté masírovat zpět do formátu, který mravenec potřebuje. Formát se také liší mezi prostředím Windows a prostředím GNU/Linux.

0
Don Kirkby

Není pouhým používáním kontroly verzí, že se nemusíte starat o zálohování webu před vysláním aktualizace?

Pokud je to provedeno správně, mělo by stačit svn update (nebo ekvivalent) a pokud je to chyba, pak ji vrátit zpět k předchozímu odevzdání? To je to, co děláme. Potvrďte všechny změny, svn update staging server, pokud je vše v pořádku, pak svn update live server.

0
Mark Henderson