Implementare în Live și Staging cu Deploybot

Dacă sunteți în dezvoltare web de ceva vreme, probabil că ați stricat un transfer de fișiere în timp ce încercați să actualizați un site. În cel mai bun caz, adăugați o grămadă de fișiere ușor de identificat într-un director și le eliminați pentru a remedia eroarea. Da, te costă timp și este enervant, dar nu s-a făcut rău.

În cel mai rău caz, transferați o grămadă de fișiere cu teme în mod necorespunzător. Apoi trebuie să vă dați seama care dintre ele au fost suprascrise, care nu aparțin deloc și cum naiba vă veți recupera starea de lucru adecvată a temei.

Astăzi vom aborda rezolvarea acestei probleme folosind Git și Deploybot pentru a vă automatiza procesul de implementare.

Ce este implementarea automată?

O implementare automată de bază are patru piese, așa cum se arată în această diagramă.

Majoritatea dezvoltatorilor încep doar cu codul lor și cu serverul. Ei fac modificări la copia lor de lucru a site-ului și apoi împing acele modificări direct pe server prin FTP. Instrumente precum Coda sau Dreamweaver au integrare FTP directă, astfel încât să puteți face acest lucru din interiorul mediului de codare.

Următorul pas pe care îl fac mulți dezvoltatori este să adauge un site de staging, astfel încât să nu modifice direct serverul live. Puteți face acest lucru cu ceva de genul VVV sau MAMP. Adesea, acest lucru înseamnă, de asemenea, că utilizați un sistem de control al versiunilor precum Git pentru a gestiona modificările pe care le faceți site-ului dvs. de lucru local.

Când adăugați un site de organizare, adăugați și complexitate. Cum obțineți modificările codului dvs. de la site-ul local de lucru pe un site de pregătire unde clientul poate vedea modificările? Da, așa cum am spus deja, puteți utiliza un client FTP de bază precum FileZilla, Transmit sau Forklift pentru a muta fișierele pe măsură ce faceți modificări, dar acest lucru este predispus la erori și aici automatizarea procesului de implementare vă va economisi atât de mult timp.

În loc să luați fișierele pe care le modificați și să le împingeți pe serverul dvs. de intermediar, utilizați un alt sistem pentru a detecta automat modificările din depozitul dvs. Git și pentru a împinge numai acele modificări pe site-ul de pregătire pe care clientul dumneavoastră îl poate utiliza pentru a verifica munca.

Totuși, acest lucru rămâne site-ul dvs. live ca o implementare manuală, ceea ce este mult mai înfricoșător, deoarece poate însemna pierderea de bani reali dacă eliminați un site de lucru activ. În schimb, să presupunem că veți configura sistemul dvs. de implementare pentru a se implementa automat în staging, iar apoi sistemul dvs. se va implementa cu un singur clic în mediul live când sunteți gata de plecare.

Deci acum aveți un sistem care arată așa.

Să ne aprofundăm astfel încât să vă pot arăta cum am configurat acest proces de implementare pentru fiecare client cu care lucrez. Aceștia sunt pașii pe care îi fac imediat ce încep un nou proiect. Mă asigur întotdeauna că procesul meu de implementare este configurat și funcționează înainte de a începe să lucrez la un proiect client.

Cum să vă structurați depozitul Git

Prima alegere pe care trebuie să o faci este, în ce director vei configura implementarea automată? Cu excepția cazului în care clientul meu solicită în mod special controlul complet al sursei pentru instalarea lor WordPress, folosesc directorul wp-content pentru a-mi configura sistemul de implementare automată. Aceasta începe în terminal prin lansarea acestei comenzi care inițializează un depozit git.

git init

Acum este timpul să ignorați fișierele pe care nu veți dori să le implementați tot timpul. Acestea sunt fișiere precum fișiere de rezervă, imagini și oricare dintre fișierele de proiect personalizate pe care mulți editori de cod le adaugă într-un director. Puteți vedea fișierul meu obișnuit .gitignore mai jos.

config/app_config.yml

config/database.yml

config/*.sphinx.conf

config/s3_credentials.yml

*~

*.cache

*.Buturuga

*.pid

tmp/**/*

.DS_Store

db/cstore/**

db/sfinx/**

doc/api

doc/aplicație

doc/plugin-uri

doc/*.punct

acoperire/*

db/*.sqlite3

*.tmproj

*.sw?

*.esproj

_note*

dwsync.xml

podcast.xml

*.kpf

*incarcari/*

*.swp

*.idee

*.sublim-proiect

*.sublim-spațiu de lucru

*/node_modules/*

Etichete

*.bak

cache/*

managementwp/*

mu-plugins/*

dp.php

curent ascendent/*

limbi/*

db.php

plugins/wp-rocket/cache.json

Simțiți-vă liber să adăugați sau să eliminați din aceasta după cum este necesar. Aproape fiecare proiect la care lucrez are nevoie de un fel de intrare personalizată pentru a ignora un fișier care este specific site-ului meu de lucru local pentru care site-urile de punere în scenă și live vor avea propriul fișier personalizat pe care nu vreau să-l suprascriu.

De aici este timpul să configurați sucursalele de care veți avea nevoie pentru a vă pune în funcțiune sistemul de implementare. Folosesc două ramuri principale. Prima este ramura principală care corespunde site-ului meu de producție live. În al doilea rând, este o ramură pe care o etichetez pe staging și care corespunde site-ului de staging pe care vreau să-l folosească clientul meu ca modalitate de a verifica modificările pe care le facem.

Când ați inițializat depozitul Git, ați primit deja ramura principală, așa că utilizați această comandă pentru a adăuga o ramură intermediară și verificați-o.

git checkout -b staging

Această comandă creează și verifică o nouă ramură. Dacă sunteți nou la git, puteți găsi mai multe informații despre comenzile disponibile în documentația Git.

Acum va trebui să vă împingeți proiectul în sistemul de control al sursei. Github și Bitbucket sunt două opțiuni populare care funcționează ambele cu sistemul de implementare automatizat pe care îl vom folosi, numit Deploybot. Când creați un nou depozit cu oricare dintre site-uri, acestea vă vor oferi instrucțiuni suplimentare pentru a adăuga depozitul local la versiunea dvs. online în Github sau Bitbucket.

• Documentația de configurare a depozitului Bitbucket
• Documentația de configurare a depozitului Github

Configurarea Deploybot

Când m-am apucat pentru prima oară de o muncă mai complexă ca dezvoltator, prietenul meu Duane mi-a tot recomandat Deploybot când m-am plâns online că am greșit implementarea manuală a FTP. A fost nevoie de o serie de recomandări până să fac în sfârșit ceea ce mi sa spus, dar acum sunt un client fericit Deploybot de ani de zile.

Deși există și alte modalități de a vă implementa site-urile, multe dintre ele implică interfața cu Git Webhooks sau unele fișiere de configurare a implementării automate prin intermediul editorului de cod. Există multă putere în acele alte instrumente, dar dacă abia începi cu implementarea automată, atunci să mergi cu ceva direct precum Deploybot este locul de început.

Pentru a începe, înscrieți-vă pentru un cont Deploybot și conectați Github sau Bitbucket la contul dvs. Îmi voi folosi contul Bitbucket existent astăzi. Începeți prin a adăuga un nou depozit la contul dvs. Deploybot.

Odată ce ați găsit depozitul pe care doriți să îl configurați pentru implementare automată, faceți clic pe butonul etichetat conectați în partea de jos a paginii. Acest lucru vă va trimite înapoi la pagina de depozit în timp ce Deploybot termină de inițializare depozit. În general, acest lucru se face într-un minut sau două, așa că umpleți-vă cafeaua și reveniți pentru a finaliza configurarea procesului de implementare.

Odată ce depozitul dvs. este configurat, faceți clic pe el pentru a fi dus la pagina sa principală. Deoarece nu avem încă configurate informații sFTP, va avea o casetă mare pe ea care vă va spune să configurați un server. Faceți clic pe butonul pentru a crea un mediu și un server.

Să începem cu implementarea în mediul nostru de pregătire. Așa că etichetați-vă serverul ca fiind montat. Alegeți implementarea automată și asigurați-vă că ați setat ramura la staging.

Când ați terminat, faceți clic pe butonul Salvare din partea de jos a paginii pentru a trece la configurația serverului dvs.

Pe pagina următoare, etichetați-l din nou ca server Staging și introduceți informațiile dvs. sFTP de pe site-ul dvs. Dacă nu sunteți sigur unde să le găsiți, citiți acest ghid util.

Cu informațiile dvs. sFTP introduse, puteți derula în jos și le puteți salva. Deploybot vă va testa apoi conexiunea pentru a se asigura că informațiile pe care le-ați furnizat funcționează. Acum este timpul să facem implementarea noastră inițială pentru site pentru a ne asigura că totul funcționează. Adaug adesea un fișier test.txt la implementare ca o modalitate ușoară de a verifica dacă implementarea a funcționat corect.

Pentru a începe implementarea în istoricul mediului și faceți clic pe implementare.

Acum veți vedea o pagină cu ultimul mesaj git commit pe ea ca nota pe care o veți vedea în Deploybot lângă această implementare. Pentru schimbări mari, voi schimba acest lucru, dar dacă schimb doar CSS sau ceva minor, mesajul de confirmare poate rămâne. Deoarece aceasta este punerea în scenă, fiecare comitere către filiala noastră de punere în scenă va fi implementată automat, ceea ce înseamnă că mesajele dvs. de comit sunt cele care vor apărea. Este doar comiterea inițială pe care trebuie să o facem manual pe site-ul nostru de pregătire.

Acum verificați dacă fișierele dvs. au fost publicate pe site-ul de pregătire și putem configura implementarea live.

Pentru implementarea dvs. live, asigurați-vă că nu alegeți implementarea automată și asigurați-vă că alegeți ramura principală ca sursă a implementării. Dorim ca aceasta să fie o implementare manuală atunci când suntem gata să facem modificări site-ului nostru live.

Pentru a face acest lucru, va trebui să verificați ramura dvs. principală, apoi îmbinați modificările din ramura dvs. de staging în principal.

Puteți face asta cu aceste comenzi.

git checkout master

git merge staging

git push origin master

Acum, când accesați contul dvs. Deploybot, veți putea implementa manual modificările la fel cum am făcut-o cu implementarea noastră inițială în mediul nostru de pregătire. Pentru mediul dvs. live, asigurați-vă că modificați mesajul de implementare pentru a se potrivi cu modificările care sunt trimise pe site-ul dvs. live. De asemenea, ar trebui să creați o copie de rezervă a site-ului dvs. Puteți face acest lucru accesând navigarea pentru copii de rezervă de pe site-ul dvs. și apoi creând o copie de rezervă manuală.

Gata, aveți configurarea sistemului dvs. de implementare automată atât pentru medii de punere în scenă, cât și pentru medii live.

Alte considerații privind implementarea

Deși acest sistem este un mare pas înainte pentru majoritatea dezvoltatorilor, nu este lipsit de probleme. Cel mai important este că, dacă aveți o grămadă de modificări, încă așteptați ca FTP să termine transferul fișierelor care s-au schimbat. Acest lucru poate însemna că cineva vă vizitează site-ul și nu sunt prezente toate fișierele pe care site-ul dvs. trebuie să le ruleze.

Pentru mulți clienți, aceasta nu va fi o problemă, dar dacă este pentru site-ul dvs., atunci va trebui să vă uitați la configurarea unui sistem de implementare Atomic. Acest tip de sistem de implementare mută toate fișierele, verifică dacă funcționează corect și apoi modifică setările fișierelor de pe serverul tău, astfel încât noul director să fie acum cel care rulează site-ul tău.

Procesul de conectare la un folder nou durează atât de scurt încât doar un computer ar observa. Aceasta înseamnă, de asemenea, că dacă găsiți o problemă mai târziu, puteți modifica linkul de sistem înapoi la versiunea veche a site-ului pentru a reveni la versiunea care funcționa. Acest lucru, din nou, durează doar o perioadă foarte scurtă de timp și reduce timpul de nefuncționare.

Indiferent ce alegeți să faceți, nu mai utilizați un client FTP pentru a vă implementa fișierele client astăzi. Costul lunar mic al Deploybot este recuperat de fiecare dată când nu faceți o greșeală la implementarea fișierelor.