Capistrano un Wordpress (I daļa)

Šis raksts ir ievads aprakstam, kā atvieglot izmaiņu veikšanu kodā, izmantojot Ruby rīku Capistrano ne-Ruby mājaslapām, šajā gadījumā Wordpress (kas, ja kāds to nezina, ir rakstīts PHP). Capistrano ir neaizvietojams Ruby web projektu veidošanas procesā, izmantojot Ruby on Rails, Sinatra, Camping vai kādus citus freimvorkus, bet šī raksta iemesls bija tāds, ka PHP izmaiņu veikšana (pēc darba ar Ruby on Rails) man likās sāpīgs process, ko vajadzēja atvieglot, tāpēc es dalos ar informāciju šajā sakarā.

Capistrano ir rīks, kas paredzēts ērtai mājaslapu izvietošanai(deployment) uz servera. Protams, lielākā daļa mājaslapu veidotāju ir pieraduši savas mājaslapas failus kopēt caur FTP, vai vēl lielākai daļai nav vajadzīgs pat tas - izmaiņas tiek veiktas tikai saturā ar klikšķiem (kādā iespējām ierobežotā CMS, kā piemēram, Blogger, Tumblr, Posterous vai Wordpress.com). Pēdējai grupai (un cilvēkiem, kas neveido mājaslapas) šis raksts (un nākamie par šo tēmu) diez vai interesēs.

Capistrano projekts iekš GitHub
Capistrano video no Railscasts

Versiju kontroles sistēma, piemēram, Git, SVN, CVS, Mercurial vai kāda cita, ļoti atvieglo koda izmaiņu piefiksēšanu. Versiju kontroles sistēma ir paredzēta tam, lai nekas nepazustu no iepriekšējā darba (lai varētu atrast, piemēram, to, kāda izskatījās lapa pirms gada) vai lai vairāki cilvēki varētu paralēli strādāt pie projekta izstrādes, nemaisoties viens otram pa kājām (atrisinot atšķirības dažādos failos, ko veikuši vairāki cilvēki). Vispār, ja godīgi, tagad man pat nav bijusi doma kaut mazāko projektu (pat tad, ja strādāju viens pie tā) sākt bez versiju kontroles sistēmas - tas vienkārši ir neprāts!

Git projekta mājaslapa
Git bezmaksas grāmata #1 / Git bezmaksas grāmata #2
Gatis Tomsons (ITHouse) par Git 

Lūk, kad tiek izmantota versiju kontroles sistēma, tad arī praktiski vienmēr veidojamā mājaslapa mums stāv gan lokāli uz datora, gan uz servera(saukts arī par production serveri, kam citreiz ir mazākais brālis - staging serveris) un katrreiz, kad veicam izmaiņas lokāli, tās arī piefiksējam jau minētajā versiju kontroles sistēmā, taču problēma rodas tad, kad mums nepieciešams lapu dabūt uz servera. Protams, mēs varam nokopēt failus uz servera, bet tas var būt ilgi (tāpēc arī riskanti) un ne sevišķi ērti. Tieši šo posmu Capistrano padara ļoti ērtu - kad izmaiņas ir uzliktas augšā uz attiecīgās versiju kontroles repozitorija(es 99% gadījumu strādāju tikai ar Git, ko es arī iesaku izmantot citiem), tad, palaižot konsolē komandu cap deploy , pēc dažām sekundēm ir redzamas izmaiņas. Un tas arī ir viss - nav nedz jāmeklē tas, kuri faili ir jākopē, nedz arī jāuztraucas par cilvēciskās kļūdas faktoru (kas, protams, ir diezgan bieža).


Darbību secība bez capistrano 
  1. Veicam izmaiņas failos (piemēram, pamainam tēmas CSS, JS un PHP failus)
  2. Atveram Filezilla vai kādu citu FTP programmu, savienojamies ar serveri
  3. Atrodam failus, kuros tika veiktas izmaiņas un pārkopējam tos uz servera (šajā procesā parasti ir visvairāk kļūdu, jo vai nu pārkopēts par daudz, vai par maz izmaiņu, kā arī tas prasa visvairāk laika/enerģijas)
  4. Aizveram Filezilla un atveram, pārbaudām Wordpress lapu ar cerībām, ka viss strādā
  5. Ja kaut kas neiet, to salabot/atgūt atpakaļ ir praktiski neiespējami, ja nav veiktas rezerves kopijas, bet tās praktiski neviens neveic Wordpress lapām, jo tas ir laikietilpīgi un "nav vajadzīgs"
Darbību secība ar capistrano
  1. Veicam izmaiņas failos
  2. Piefiksējam izmaiņas git un uzliekam tās uz servera repozitorija (kas visbiežāk atrodas turpat, kur serveris)
    git commit -am "tēmas izmaiņas" 
    git push origin
  3. Uzliekam izmaiņas
     cap deploy
Par to, kā izmantot Wordpress ar Capistrano - nākamajā rakstā.
comments powered by Disqus