Dobre, priatelia. Je čas ‘sa popasovať.

Ak ste niečo ako ja, strávili ste svoju prvú nohu Vývoj WordPressu „kovbojské kódovanie“ rokov - to znamená vykonávanie divokých zmien na živých stránkach, ich urgentné testovanie a spustenie pomocou protokolu FTP, čo často vedie k 500 chybovým správam interného servera a prerušeniam celého webu, ktoré sú viditeľné pre vašich ctených návštevníkov.

Aj keď to bolo úplne napínavé, keď vám adrenalín pumpoval medzi prstami a búchal v zabudnutom bodkočiarke, na stránkach s viac ako 0 návštevníkmi (ktorí si skutočne všimli výpadok) by to začal robiť problém. Ak spadne strom a nikto ho nebude počuť, vydá zvuk? Závisí to od teórie ľudstva, ktorú ste prihlásili.

Ak však stránka havaruje a niekto je tu, aby ju videl, určite vydá zvuk.

Nepretržité nasadenie WordPress bolo urobené nesprávne

Zadajte pracovné miesta, duplikujte inštalácie WordPress (aspoň teoreticky), kde je možné vykonať zmeny, a potom znova vykonajte živé stránky, keď sa potvrdí, že všetky fungujú. Aj keď to návštevníkov utíchlo, začalo to u nás vývojárov robiť nejaký hluk. Zrazu sme potrebovali sledovať dva weby, zabezpečiť, aby sa medzi nimi ručne synchronizoval kód, a znova všetko otestovať, aby sme sa uistili, že funguje na živom serveri. Dlhé, chaotické zoznamy výrazov „uistite sa, že to naživo zmeníte“ a „nezabudnite to prepnúť na oddychové miesto pred kopírovaním kódu“, boli mierne povedané nervózne. Zálohovanie tohto systému bolo tiež nočnou morou - množstvo priečinkov s názvom „my-theme-staging-1“ a „my-theme-live-before-menu-restyle-3“ atď.

Musela existovať lepšia cesta a bola.

Bol tu Git, ktorý vývojárom poskytuje dokonalé riadenie zdrojov a ďalšie funkcie. Používanie riadenia verzií pre inštalácie WordPress okamžite urýchlilo a vyčistilo vývoj, pretože hodiny už neboli trávené zálohovaním v systéme pre vývojárov, ale v skutočnosti kódovaním. Zmeny sa uložili a ja som mohol do svojej práce konečne pridať zmysluplné správy, svet odlišností od „my-theme-4-v2“.

Aj keď bola základňa kódov oveľa čistejšia, problémom zostávalo skutočné nasadenie a zabezpečenie toho, aby príslušná stránka používala najnovší kód - zadajte príležitosť-za-ľudskou chybou. Stále sa spoliehať na ručné nahrávanie na FTP, ktoré prepísalo predchádzajúci kód, necítilo sa dobre. Aj keď existovali ďalšie služby CI / CD, veľa z nich malo značnú cenu a veľké množstvo nastavenia - konfigurácia servera, ktorá sa spoliehala na ešte jednu službu aj pre najjednoduchšiu webovú stránku, pričom sa naučila celý „spôsob, ako robiť veci“ a všetky ďalšie služby výstrednosti, ktoré k tomu patria.

Zatiaľ čo podobné nastavenia ako v tomto výučbe je možné vykonať pomocou GitHub / GitLab a ďalších služieb, svoje vajíčka som vložil do košíka Atlassian skoro kvôli ich bezplatným súkromným úložiskám (čo bola iba nedávna ponuka od GitHubu). Kedy Bitbucket predstavili svoje Potrubie a rozmiestnenie služby, umožňoval novému kódu automatické nasadenie na oddychové alebo produkčné stránky (alebo na akékoľvek iné miesto medzi nimi) bez opätovného načítania cez FTP alebo pomocou externej služby. Devs teraz mohli vo vývoji WordPressu využívať všetky hodnoty riadenia zdrojov a tieto zmeny okamžite posielať do príslušných cieľov bez ďalších kliknutí a klávesových skratiek so stavom všetkého viditeľného na jednom prístrojovom paneli. To zaisťuje, že všetko zostane synchronizované, a na prvý pohľad vám umožní vedieť, aký kód je na každom webe spustený. Navyše ceny za minútu na zostavenie Bitbucketu je neuveriteľne cenovo dostupný - s 50 minútami zadarmo mesačne a možnosťou plánu „zadarmo s prekročením“.

Trvalo trochu času na spustenie, kým sme prišli na to, ako čo najlepšie využiť vetvy a ďalšie funkcie riadenia zdrojov v tomto novom modeli a podrobnosti nastavenia Bitbucket Pipelines. Tu je postup, ktorý používam na začatie nových projektov WordPress. Nebudem sa venovať všetkým drobnostiam pri nastavovaní inštalácií git a WordPress, pretože veľké zdroje na to sú len na Google hľadaní. Tok obsahu bude nakoniec asi taký:

Rutina Alexa Green WordPress Depoyment

Tu uvedené kroky by sa mali vykonať podľa potreby:

Na serveri klienta

Nastavte doménu pre aktívne stránky (napr. Clientsite.com) a subdoménu pre inscenácie (napr. Staging.clientsite.com).

Nainštalujte WordPress na živý web aj na pripravovanú subdoménu. To je možné vykonať cez cPanel / Softaculous (ak to má hostiteľský server klienta) alebo stiahnutím z wordpress.org. Zaistite, aby existovali samostatné databázy pre živé vysielanie a inscenačné práce.

Na Bitbucket.com

Vytvorte nové úložisko. Zahrňte súbor .README, ktorý nás naštartuje.

V úložisku Nastavenia> Potrubie> Nastavenia potom skontrolujte Povoliť kanály .

V Nastavenia> Potrubie> Repozitárne premenné , Zadaj nasledujúce:

Name: FTP_username Value: The client FTP username Name: FTP_password Value: The client FTP password

Vráťte sa do Potrubie> Nastavenia a kliknite na ikonu Nakonfigurujte bitbucket-pipelines.yml tlačidlo. Vyberte PHP ako jazyk na nasledujúcej stránke. Budete chcieť použiť niečo ako nasledujúci kód. Uistite sa, že nahradíte verziu PHP tým, čo používate na serveri klienta, a servermi adries URL / FTP skutočnými adresami URL (servery FTP) a produkčnými servermi.

image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com

Kliknite Potvrdiť súbor . Inštalácia potrubí bude teraz potvrdená a spustí sa.

Ak sa všetko úspešne nasadí, vráťte sa späť a upravte súbor bitbucket-pipelines.yml (môžete sa tam dostať cez Potrubie> Nastavenia a Zobraziť bitbucket-pipelines.yml ). Obe miesta budete chcieť vymeniť tam, kde je napísané git ftp init s git ftp push a uložiť / potvrdiť. Takto zabezpečíte, že sa budú nahrávať iba zmenené súbory, a ušetríte tak minúty potrebné na zostavenie. Váš súbor bitbucket-pipelines.yml by mal teraz čítať:

image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com

Pridajte vetvu s názvom main-dev.

Na vašom lokálnom počítači

Klonujte úložisko do prázdneho adresára, ktorý chcete použiť pre miestnu inštaláciu. Pozrite sa na main-dev pobočka.

Nastavte lokálnu inštaláciu WP v tomto adresári. Existuje veľa nástrojov na to— Miestne zotrvačník , MAMP , Docker atď. Skontrolujte, či je všetko rovnaké (verzia WordPress, verzia PHP, Apache / Nginx atď.) ako to, čo je spustené na serveri klienta.

Pridajte znak .gitignore to vyzerá asi takto. V podstate chceme, aby Git ignoroval všetko okrem wp-content (aby sa predišlo problémom s inštaláciou medzi inštaláciami). Možno budete tiež chcieť pridať svoje vlastné pravidlá ignorovania veľkých záložných súborov a ikon vytvorených systémom a súborov DS_Store.

# Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

Uložiť a potvrdiť .gitignore.

Vykonajte zmeny a podľa toho sa zaviažte.

Kedykoľvek sa zaviažete k main-dev, spustí sa upload FTP na pracovnú stránku. Kedykoľvek sa zaviažete zvládnuť, vypáli upload FTP na produkčné miesto. Upozorňujeme, že toto bude využívať minúty na zostavenie, takže možno budete chcieť urobiť väčšinu miestnych zmien na vetve mimo main-dev, potom ich po skončení dňa zlúčiť do main-dev.

Zlúčenie main-dev do masteru prinesie všetky inscenačné zmeny naživo. Stav potrubí a nasadení môžete skontrolovať v repo na Bitbucket.org.

Synchronizácia databáz WordPress naprieč inštaláciami

Vyššie uvedené bude synchronizovať iba súbory (témy, doplnky, atď.). Synchronizácia databázy medzi produkciou a fázovaním sa stáva odlišnou záležitosťou, pretože klienti často robia na živom serveri zmeny, ktoré sa na pracovnom mieste neodrazia, a naopak.

Na synchronizáciu databáz medzi inštaláciami WordPress existuje niekoľko možností. Tradične môžete databázy aktualizovať importom / exportom cez phpmyadmin . To je však zložité, pretože nemôže aktualizovať niektoré veci, ktoré je potrebné aktualizovať, napríklad trvalé odkazy v obsahu príspevku. Pomocou tejto metódy je obľúbeným nástrojom Plugin Velvet Blues Update URL , ktoré potom môžete použiť na vyhľadanie alebo nahradenie všetkých inštancií starej adresy URL webu (napr. https://staging.clientsite.com) na adresu URL novej stránky (napr. https://clientsite.com ). Môžete to tiež použiť s relatívnymi cestami a reťazcami. Táto metóda nakoniec ponecháva veľa priestoru pre ľudské chyby - ak je nahradený reťazec napísaný nesprávne, môže to spôsobiť rozbitie celého webu a nebude môcť používať doplnok / pristupovať k dashboardu.

Zatiaľ čo plugin ako Migrácia All-in-One WP ponúka funkciu hľadania / výmeny už po vybalení z krabice a je neuveriteľne užívateľsky prívetivý. Prináša tiež súbory, čím vracia hodnoty celého nášho pracovného toku Pipelines. Navyše, keďže spätne importuje všetky nahrané súbory wp, môže to mať za následok obrovské súbory a časy načítania (nie je teda vhodný na presun zmien medzi inštaláciami). Takýto doplnok je najlepšie vyhradený na zálohovanie celého webu na účely archivácie alebo zabezpečenia.

VersionPress sa javí ako zaujímavé riešenie, ale zatiaľ nie je overené v mnohých produkčných prostrediach. Zatiaľ sa doplnkom páči WP Sync DB alebo WP Migrate DB Pro sa javia ako najlepšie riešenia pre správu databáz. Umožňujú sťahovať / tlačiť databázy naprieč inštaláciami, zatiaľ čo dávajú možnosť automaticky aktualizovať adresy URL a cesty. Môžu migrovať iba určité tabuľky, napríklad wp_posts iba pre obsah príspevku, a nebudú strácať čas opätovným importom používateľov a nastaveniami celého webu. Rád pracujem naživo, aby som sa ubezpečil, že sa neprepisujú žiadne výrobné údaje. Tu uvádzam príklad nastavenia, ak používate databázu WP Sync DB (ďalšie návody sú k dispozícii na webe github WP Sync DB ):

1. Na živom webe: Nastavte WP Sync DB s povoleným nastavením „Allow Pull from this repository“.
2. Na oddychovej stránke: Nastavte WP Sync DB pomocou nastavení Pull from Live. Pomenujte to „živé vysielanie“.
3. V miestnom nastavení pre vývojárov: Nastavte WP Sync DB pomocou nastavení Pull from Live. Pomenujte to „live-to-dev“.

Možno budete tiež chcieť nastaviť posúvacie pravidlo „dev-to-staging“ a skontrolovať nastavenie pracovnej stránky, aby bolo možné databázu prepísať.

Balenie

Zistil som, že tieto metódy majú tendenciu fungovať vo väčšine prípadov použitia, a to pri vývoji nových webových stránok WordPress, ako aj pri prepracovaní / zmene konfigurácie už zverejnených webových stránok.

Umožňuje nasadenie kódu, ktoré udržiava všetky verzie servera v aktualizovanom stave bez dodatočného času a úsilia a úmyselnej a bezpečnej logiky migrácie databázy pre prácu medzi servermi. Aktualizácia doplnkov sa vykonáva aj v rámci riadenia zdroja, takže aktualizácie aktualizácií je možné bezpečne skontrolovať pri príprave pred potvrdením o zverejnení na živom webe, čím sa minimalizujú prestávky produkčného webu.

Aj keď určite existuje priestor na zlepšenie, aby sa do správy databáz dostal viac pracovného toku riadenia zdrojov, až kým sa v produkčných prostrediach nebude viac používať nástroj ako VersionPress, zdá sa, že táto metóda selektívnych ťahov / ťahov databázy cez WP Sync DB alebo WP Migrate DB Pro najbezpečnejšou metódou riešenia tohto problému. Zaujíma vás, čo funguje pre váš pracovný postup WordPress, alebo ak po tom všetkom radšej chytíte laso a kódujete kovboja!

Pochopenie základov

Má WordPress kontrolu verzie?

WordPress nemá zabudovanú žiadnu kontrolu verzie, preto je potrebné vlastné riešenie.

Môžete používať GitHub s WordPress?

Môžete použiť GitHub alebo iné riešenie na správu verzií (GitLab, Bitbucket) s WordPress, ktoré vám umožní využívať moderné vývojové funkcie správy verzií s WordPress.

Aký je rozdiel medzi bitbucketom a bitbucket serverom?

Bitbucket a Bitbucket Server sú riešenia na správu verzií. Bitbucket je štandardná ponuka a vyžaduje minimálne nastavenie, zatiaľ čo server Bitbucket Server poskytuje tímom viac prispôsobenia a kontroly.

Prečo používame Bitbucket?

Bitbucket je dôveryhodné riešenie na správu verzií od spoločnosti Atlassian a dávno pred GitHubom poskytlo neobmedzené bezplatné súkromné ​​úložiská. Integruje sa s ich službou Pipelines CI / CD (umožňujúcou nastavenie nepretržitej integrácie a nasadenia v priebehu niekoľkých minút) a ich softvérom Jira, nástrojom číslo 1 na sledovanie a sledovanie projektov.

Aký je zmysel riadenia verzií?

Kontrola verzií umožňuje vývojárom a tímom bezpečne aktualizovať kód a vidieť zmeny na prvý pohľad. Udržuje zálohy starého kódu a umožňuje vývojárom „vetviť“ hlavný kód tak, aby pracoval na určitých funkciách alebo opravách chýb, a zlúčiť sa s funkčnou verziou a nasadiť ich bude možné až po schválení všetkých.

Ako funguje správa verzií?

Riadenie verzií zaznamenáva zmeny v súbore (alebo v súbore súborov), aby bolo možné v prípade potreby ich históriu neskôr skontrolovať. Môže zvýrazniť rozdiely medzi rôznymi verziami, aby vývojári mohli rýchlo zistiť, čo sa zmenilo.