• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    DELVITLinux pro zacatecniky a obycejne uzivatele (NO FLAMES!)
    CHOROBA
    CHOROBA --- ---
    download helper ve firefoxu taky funkuje
    ERGOSUM
    ERGOSUM --- ---
    CHEVALIER: Mě to zvládá dwhelper plugin do Firefoxu. A výsledek mám v mp3.
    CHEVALIER
    CHEVALIER --- ---
    Potřebuju stáhnout http://prehravac.rozhlas.cz/audio/3252718 . Nevíte jak?
    GILHAD
    GILHAD --- ---
    PISKVOR: Obecne urcite jo a s "beznym zakaznikem" bych to resil jinak, ale zrovna tohle neni tak zcela bezna konstelace a ver mi, ze ruznych pruseru uz jsme spolu prestali dost (ano, i ja jsem nechtic par vyrobil, on podstatne vic a nektere nastaly z "vyssi moci"), takze vim, jak reaguje, co ci muzu risknout a co urcite ne. Ale tim se uz dostavame hodne OT.

    Cele to zacalo pozadavkem, jak resit jednu urcitou situaci a ja popsal jedno reseni, ktere v ni lze pouzit. Nikoli jako navod, jak si usporadavat vlastni vyvoj, ale jako rychle reseni prave te konkretni situace, do ktere se dostal SYNTAX_TERROR: .

    Ze je dobre si zorganizovat workflow tak, aby se clovek do podobnych situaci nedostaval je sice pravda, ale kdyz v ni uz je, tak mu ta pravda moc nepomuze.

    PISKVOR
    PISKVOR --- ---
    GILHAD: "A kdyz dojde k odstavce, tak to holt bude muset okecat bez pocitace - zatim se to jeste nestalo" - a jsme u toho. To ti možná tvrdí teď, ale až se jednoho krásného dne exkrement setká s větrákem, půjde to za tebou; o to bych se klidně vsadil (což je taky důvod, proč by v tom rozhodně neměl mít ani _možnost_ hrabat sám, aspoň ne bez audit trailu).

    A "_moje_ codebase" taky leccos vysvětluje - jeden kovboj na produkci je ještě zvladatelný, dva jsou průser, tři příležitost aplikovat DR.
    GILHAD
    GILHAD --- ---
    PISKVOR: Proto taky s funkcnosti divociny neporadam a kdyz zakaznik pozaduje zmeny ve webovkach nejpozdeji ihned a nejvetsi hrozba je, ze se rozsype barevne podani a v textu budou preklepy, tak to jisti revert z toho gitu na produkci.

    Na druhou stranu, proc nevyjit zakaznikovi vstric, kdyz vim, ze cokoli kdykoli dokazu plne vratit a on ma pocit, ze mu mizive riziko nekolikaminutove odstavky stoji za novou, naprosto uzasnou vstupni obrazovku se supernovym logem, kterou ohromi sveho klienta tak, ze si zakoupi produkt, nebo podporu nebo tak neco. (A kdyz dojde k odstavce, tak to holt bude muset okecat bez pocitace - zatim se to jeste nestalo). Jakmile se situace uklidni (tedy odpoledne tehoz dne), poberu zmeny, rozumne zanesu k sobe a udelam cisty release v nejblizsi vhodnou chvili.

    Moje codebase je v usporadanem stavu porad a jestli zakaznik chce hazardovat na svem serveru se svou instalaci, i kdyz zna rizika, je to jeho boj. Proc je to problematicke jsme si vyrikali davno, pokud na tom presto trva, nese riziko sam a vedome. Koneckoncu je uz svepravny a pouceny.

    (Pokud zakaznik trva na tom, ze se kladivem chce prastit do palce, tak mu vysvetlim nevyhody, ale jeho zakoupene kladivo mu neseberu. Muj palec to neni, me to bolet nebude a jemu to treba udela radost)

    Lip, nez kdyby se v tom zkousel hrabat nejak sam (produkcni pocitace jsou jeho a ma k nim plny (i fyzicky) pristup. Takhle mu muzu udelat zmeny male a neskodne v kratkem case a velke rozmluvit a nechat na pozdeji, ono ne vzdy je z pohledu uzivatele videt, co presne kam spada. ("Kdyz nebyl problem pridat chlivecek pro druhy komentar, proc by mel byt problem pridat chlivecek pro zadani meny" - protoze z nejakeho komentare nic neplyne a moznost pocitat ve vice menach zasahne skoro vsechno, ze (ne, ze by ten muj zatim pocital jakekoli penize, ale tohle je snadno popsatelny priklad))
    PISKVOR
    PISKVOR --- ---
    GILHAD: Ok, tu první část dokážu akceptovat.
    A taky chápu, že se "divokosti dělají jen zřídka" - abych parafrázoval úsloví o backupech, "jsou týmy, které dosud umožňují divočinu na produkci, a pak jsou týmy, které už si takhle shodily kriticky důležitou funkčnost." Neboli jinak: produkční prostředí není místo na "zkoušení."
    GILHAD
    GILHAD --- ---
    PISKVOR: Mam skripty na to, co je vyhodne skriptovat. Ale deployovaci kolecko znamena "udelat balicek, nahrat tar.gz na server, nahrat ebuild na server" (jeden skript na jednom pocitaci) a "dat update;emerge -DuN world; /etc/init.d/produkt restart" na produkci (druhy skript na druhem pocitaci).

    Vzhledem k tomu, ze ne vzdy se restart hodi a projiti zavislosti nejakou dobu trva a kopirovani balicku taky, navic casto zmena muze zasahnout vic balicku (system jich ma par desitek) a je dobre ji publikovat naraz a zaroven to taky lidi pouzivaji, tak neni dobre mit svazano nasazovani s vyvojem. Takze si vesele programuju, kdy se to hodi me a nasazuju, kdy se to hodi zakaznikum.

    Ten git na produkci je naprosto nesvazany s jinymi repozitari a neni duvod je provazovat, v normalnim provozu jsou commity pouze typu "upstream verze", tyhle divokosti se deji jen zridka. A obcas zasahuji povicero balicku a je zajimavy az konecny vysledek a ne co vsechno zakaznik chtel vyzkouset a pak zavrhnul.
    PISKVOR
    PISKVOR --- ---
    GILHAD: A na to nemas skript, kterej to deployovaci kolecko udela automagicky, kdyz commitnes neco na gitu do vetve "master" (nebo "release", nebo co tam mas)? Ja myslel, ze to uz je dneska skoro samozrejmost. Aspon teda ze tu nepadlo F-word (to na tri pismenka).
    SYNTAX_TERROR
    SYNTAX_TERROR --- ---
    vyzkoušim tenhle script http://code.google.com/p/git-sync/
    sice mi ty nový soubory(na produkci) nevypíše, ale rovnou jimi zpětně updatne ty z dev. verze, ale s trochou snahy by se to dalo přiohnout.

    Jinak jednu git repository mám v té dev. verzi projektu. Používám občas před nějakými úpravami, kdy se bojim že něco rozbiju a budu muset rychle vrátit. Při syncu se do prod. verze kopíruje i tenhle .git adresář/repozitář, takže nějaký porovnávání mězi nimi asi nepřipadá v úvahu, když jsou stejný(?)

    Je pravda že git používám dost povrchně, možná že to co potřebuju zvládá levou zadní. Budu ho muset trochu nadrtit.
    GILHAD
    GILHAD --- ---
    Ja to delam tak, ze mam i na te produkcni nahozeny git (s prislusnyma .gitignore) a po nasazeni vzdy commitnu zmeny, ze "upstream x.y.z". A pred nasazovanim git status, git diff, a hned je videt, kam a jak se sahalo (a snadno se to copy+paste prenese na ten dev, nebo kamkoli jinam)

    (Jo, v nekterych pripadech fakt saham na produkcni, zvlast, kdyz si nekdo vzpomene, ze nutne prave ted (pul hodiny pred navstevou zakaznika, kteremu to chce ukazat) potrebuje preformulovat nejake texty nebo prebarvit nejake barvy ve webovkach a ze se na to hned koukne a rekne co jeste dal ... tam tezko neco rozhodim prilis a delat cele kolecko s vytvarenim balicku a nasazenim, zvlast, kdyz vzapeti rekne, ze ta zelena je moc zelena a ze tam radsi teda mam dat modrou, aby nakonec usoudil, ze puvodni hneda asi byla fakt lepsi, jen by mohla byt trochu svetlejsi ... to by bylo nesmyslnych balicku az hruza ...)
    SATAI
    SATAI --- ---
    SYNTAX_TERROR: Co nahradit rsync nejakym VCS? (cti: pouzit git)
    SYNTAX_TERROR
    SYNTAX_TERROR --- ---
    Tak jsem vytvořil nový image a nainstaloval/nakonfiguroval těch pár služeb znovu, zas tak moc práce to nakonec nebylo :)

    A poprosil bych o help ještě s jednou věcí: mám na jednom serveru produkční a testovací verzi jednoho projektu + script, který rsyncuje soubory z dev verze na produkční. Už se mi stalo, a obávám se že v budoucnu stane znovu, že byly na prod. verzi nějaké nové úpravy, které někdo (třeba i já:) udělal rovnou na této prod. verzi, ale ne na devel. Při syncu by to pak nedělalo dobrotu.

    Vím, že s rsyncem můžu updatovat jen starší/na prod. verzi nezměněné soubory. Ale to by pak mohl vzniknout maglajz a na dev verzi by se tak úpravy z prod. stejně nedostaly. Takže bych chtěl nějak v rámci toho synchronizačního sciptu zjistit, že prod. verze obsahuje nověji modifikovaný soubory. Nejlépe teda rovnou ty soubory i rovnou vypsat, abych to mohl zkontrolovat a případně zkopčit na dev. ručně.
    PISKVOR
    PISKVOR --- ---
    RATTKIN: Divný; ještě je otázka, jestlis tam neměl nějaký exotický FS - já takhle zmenšoval vfat, ntfs, ext[34], i o třeba dvacet procent, a bez problému (musí tam být pochopitelně adekvátní volný místo).

    Jinak pokud máš image a tohle ti nejde, namountoval bych to rw do loopu a pustil na to gparted, ten partitions zmenšuje už úplně bez problémů.
    RATTKIN
    RATTKIN --- ---
    PISKVOR: Zkouše jsem to před 3 měsíce v poslední stable clonezilla live, zkoušel jsem save disk disk - restore disk, i partition -> partition. nic mi nešlo. V reklamaci vyměnili 250g disk WD za jiného výrobce, který byl o půl mega menší, strašnej wopruz
    PISKVOR
    PISKVOR --- ---
    PISKVOR: A teda bacha, Clonezilla != Clonezilla Live...
    PISKVOR
    PISKVOR --- ---
    RATTKIN: Ne? Já mám dojem, že už nejmíň dva roky umí - resp. pokud děláš restore-to-disk, tak na menší disk všechny obnovovaný partitions proporcionálně zmenší. Nevím, jestli to umí i v módu restore-single-partition...
    RATTKIN
    RATTKIN --- ---
    PISKVOR: s clonezillou jsem vždycky měl problém, když jsem chtěl jí na menší disk, neumí resize partition (nebo možná jo, ale po nějaký super konfiguraci)
    PISKVOR
    PISKVOR --- ---
    SYNTAX_TERROR, RATTKIN: Kdysi jsem to takhle řešil pomocí Clonezilly Live (nabootované uvnitř virtuálu)- starý VM zazálohovat na hosta, zálohu obnovit na menší virtuální disk. Zdlouhavé, leč funkční.
    RATTKIN
    RATTKIN --- ---
    SYNTAX_TERROR: taky by se dala kopírovat patition na novou menší partition přes gparted nebo něco podobného
    Kliknutím sem můžete změnit nastavení reklam