Okei, ihmiset. Aika 'nousta ylös.

Jos olet jotain minun kaltaista, vietit ensimmäisen osuutesi WordPress-kehitys vuoden 'cowboy-koodaus' - toisin sanoen muutosten tekeminen rajusti live-sivustoissa, testaaminen ja käynnistäminen kiireellisesti FTP: llä, mikä johtaa usein 500 sisäisen palvelimen virheilmoitukseen ja sivuston laajuiseen rikkoutumiseen, jotka kaikki näkevät arvostetuille vierailijoille.

Vaikka tämä oli aivan jännittävää, kun adrenaliini pumpattiin sormiesi läpi, jyskyttäen unohdetussa puolipisteessä, sivustoissa, joissa on yli 0 kävijää (jotka todella huomasivat seisokit), tästä tulisi ongelma. Jos puu putoaa eikä kukaan ole siellä kuulemassa, tuottaakö se äänen? Riippuu tilaamastasi ihmiskunnan teoriasta.

Kuitenkin, jos sivusto kaatuu ja joku on siellä katsomassa sitä, hän varmasti antaa äänen.

WordPressin jatkuva käyttöönotto on tehty väärin

Mene vaiheistussivustoille, kopioi WordPress-asennuksia (ainakin teoriassa), joihin muutoksia voidaan tehdä, ja tee sitten uudelleen suoralla sivustolla, kun kaikki on vahvistettu toimivan. Vaikka tämä hiljaisti kävijöitä, se alkoi aiheuttaa meille kehittäjille melua. Yhtäkkiä meidän piti seurata kahta sivustoa, varmistaa, että koodi synkronoidaan manuaalisesti niiden välillä, ja testata kaikki uudestaan ​​varmistaaksemme, että se toimii suoralla sivustolla. Pitkät, sotkuiset luettelot 'varmista, että vaihdat tämän suorana lähetyksenä' ja 'muista vaihtaa tämä lavastussivustolla ennen koodin kopiointia' olivat lievästi sanottuna hermostavia. Tämän järjestelmän varmuuskopiot olivat myös painajainen - joukko kansioita nimeltä 'oma teema-lavastus-1' ja 'oma teema-live-ennen-valikkoa-restyle-3' ja niin edelleen.

Piti olla parempi tapa, ja oli.

Siellä oli Git, joka antaa täydellisen lähdekontrollin ja muita ominaisuuksia kehittäjille. Versionhallinnan käyttäminen WordPress-asennuksissa vauhditti ja siisti kehityksen heti, koska tuntikausia ei enää käytetty kehittäjäkohtaiseen varmuuskopiointiin, vaan itse koodaukseen. Muutokset tallennettiin, ja voin vihdoin lisätä mielekkäitä viestejä työhöni, maailmoja, jotka eroavat toisistaan ​​”my-theme-4-v2”.

Vaikka koodikanta oli paljon puhtaampi, ongelma säilyi edelleen varsinaisessa käyttöönotossa ja varmistettiin, että kyseinen sivusto käyttää uusinta koodia - kirjoita mahdollisuus ihmisille-virheeksi. Edellisen koodin korvaavan manuaalisen FTP-latauksen turvaaminen ei tuntunut hyvältä. Vaikka muita CI / CD-palveluja oli olemassa, monilla niistä oli huomattava hintalappu ja suuri määrä asetuksia - palvelimen uudelleenkäynnistys, luottaen vielä yksinkertaisimmankin verkkosivuston palveluun, oppimalla toisen palvelun koko 'toimintatapa' ja kaikki sen mukana olevat erikoisuudet.

Vaikka samankaltaiset asetukset tähän opetusohjelmaan voidaan tehdä GitHub / GitLab ja muut palvelut, olin asettanut munani Atlassian koriin aikaisin niiden ilmaisten yksityisten arkistojen vuoksi (mikä on ollut vasta äskettäinen tarjous GitHubilta). Kun Bitbucket esitteli heidän Putket ja käyttöönotot palveluiden avulla se antoi uuden koodin automaattisesti käyttöön lavastus- tai tuotantosivustoille (tai mille tahansa muulle välissä olevalle sivustolle) lataamatta sitä uudelleen FTP: n kautta tai käyttämättä ulkoista palvelua. Kehittäjät voisivat nyt käyttää kaikkia lähdekontrollin arvoja WordPress-kehityksessään ja lähettää muutokset välittömästi sopiviin kohteisiin ilman ylimääräisiä napsautuksia tai näppäilyjä, ja kaiken tilan näkyi yhden kojelaudan kautta. Tämä varmistaa, että kaikki pysyy synkronoituna ja antaa yhdellä silmäyksellä tietää tarkalleen, mitä koodia kukin sivusto käyttää. Lisäksi hinnoittelu Bitbucketin rakennusminuuteille on uskomattoman edullinen - 50 minuuttia ilmaiseksi kuukaudessa ja mahdollisuus 'Free with Overages' -suunnitelmaan.

Kesti vähän käynnistysaikaa selvittääksesi, kuinka parhaiten käyttää haaroja ja muita lähteenhallinnan ominaisuuksia tässä uudessa mallissa ja Bitbucket Pipelines -asennuksen yksityiskohdissa. Tässä on prosessi, jota käytän uusien WordPress-projektien aloittamiseen. En aio käsitellä kaikkia hölynpölyä git- ja WordPress-asennusten määrittämisessä, koska suuret resurssit ovat vain Google-haun päässä. Loppujen lopuksi sisältövirta on jotain tällaista:

Alexa Green WordPress Depoyment -rutiini

Tässä esitetyt vaiheet tulisi suorittaa tarpeen mukaan:

Asiakkaan palvelimella

Määritä verkkotunnus live-sivustolle (esim. Clientsite.com) ja aliverkkotunnus vaiheistusta varten (esim. Staging.clientsite.com).

Asenna WordPress sekä live-sivustoon että vaiheiden aliverkkotunnukseen. Tämä voidaan tehdä cPanel / Softaculous-palvelun kautta (jos asiakkaan isännöintipalvelussa on tämä) tai lataamalla osoitteesta wordpress.org. Varmista, että on olemassa erilliset tietokannat suoraa ja lavastusta varten.

Sivustolla Bitbucket.com

Määritä uusi arkisto. Sisällytä .RADME saadaksesi meidät ylös ja menemään.

Arkistossa Asetukset> Putkilinjat> Asetukset tarkista sitten Ota putkilinjat käyttöön .

Sisään Asetukset> Putkilinjat> Varastomuuttujat , Kirjoita seuraava:

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

Palata takaisin Putkilinjat> Asetukset ja napsauta Määritä bitbucket-pipelines.yml -painiketta. Valitse PHP kielenä seuraavalla sivulla. Haluat käyttää jotain seuraavan koodin kaltaista. Muista korvata PHP-versio kaikilla, joita käytät asiakkaan palvelimella, ja URL-osoitteet / FTP-palvelimet varsinaisilla asiakassivustojen (tuotanto- ja vaiheistus) URL-osoitteilla / FTP-palvelimilla.

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

Klikkaus Suorita tiedosto . Pipelines-asennus sitoutuu nyt ja suoritetaan.

Jos kaikki toimii onnistuneesti, palaa takaisin ja muokkaa bitbucket-pipelines.yml-tiedostoa (pääset sinne läpi Putkilinjat> Asetukset ja Näytä bitbucket-pipelines.yml ). Haluat korvata molemmat paikat, joissa lukee git ftp init kanssa git ftp push ja tallenna / sitoutu. Tämä varmistaa, että vain muuttuneet tiedostot latautuvat, mikä säästää rakennuksen minuutteja. Bitbucket-pipelines.yml-tiedostosi pitäisi nyt lukea:

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

Lisää haara main-dev.

Paikallisella koneellasi

Kloonaa arkisto tyhjään hakemistoon, jota haluat käyttää paikalliseen asennukseen. Katso main-dev haara.

Määritä paikallinen WP-asennus tähän hakemistoon. Tähän on monia työkaluja - Paikallinen vauhtipyörällä , MAMP , Satamatyöläinen Varmista, että kaikki on sama (WordPress-versio, PHP-versio, Apache / Nginx jne.) kuin asiakkaan palvelimella.

Lisää .gitignore joka näyttää tältä. Pohjimmiltaan haluamme, että Git ohittaa kaiken paitsi wp-sisällön (jotta asennusongelmat voidaan estää asennusten välillä). Voit myös lisätä omia sääntöjä suurten varmuuskopiotiedostojen sekä järjestelmän luomien kuvakkeiden ja DS_Store-tiedostojen ohittamiseksi.

# 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

Tallenna ja sitoudu .gitignore.

Tee muutoksia ja sitoudu vastaavasti.

Aina kun sitoutut main-dev: ään, se käynnistää FTP-latauksen lavastussivustolle. Aina kun sitoutut hallitsemaan, se käynnistää FTP-latauksen tuotantosivustolle. Huomaa, että tämä käyttää koontiminuutteja, joten kannattaa ehkä tehdä suurin osa paikallisista muutoksista main-dev: n haaralla ja sitten yhdistää main-dev: iin, kun olet valmis päivälle.

Main-dev: n yhdistäminen masteriksi tuo kaikki vaiheittaiset muutokset eloon. Voit tarkistaa putkilinjojen ja käyttöönottojen tilan reposta osoitteessa Bitbucket.org.

WordPress-tietokantojen synkronointi asennusten välillä

Huomaa, että yllä oleva synkronoi vain tiedostot (teemat, laajennukset jne.). Tietokannan synkronoinnista tuotannon ja lavastamisen välillä tulee eri asia, koska asiakkaat tekevät usein live-sivustossa muutoksia, jotka eivät näy lavastussivustossa, ja päinvastoin.

Tietokantojen synkronointiin WordPress-asennusten välillä on useita vaihtoehtoja. Perinteisesti voit päivittää tietokantoja tuomalla / viemällä kautta phpmyadmin . Tämä on kuitenkin hankalaa, koska se ei voi päivittää tiettyjä päivitettäviä asioita, kuten pysyviä linkkejä postisisällössä. Tätä menetelmää käyttämällä suosikkityökalu on Velvet Blues Update URLs -laajennus , jonka avulla voit sitten etsiä / korvata vanhan sivuston URL-osoitteen (esim. https://staging.clientsite.com) esiintymät uudelle sivuston URL-osoitteelle (esim. https://clientsite.com ). Voit käyttää tätä myös suhteellisten polkujen ja merkkijonojen kanssa. Tämä menetelmä lopulta jättää paljon tilaa inhimillisille virheille - jos korvattu merkkijono kirjoitetaan väärin, se voi aiheuttaa koko sivuston rikkoutumisen eikä pysty käyttämään laajennusta / pääsyä hallintapaneeliin.

Vaikka plugin kuten Kaikki yhdessä WP-siirto tarjoaa haku- / korvausominaisuuden heti laatikosta ja on uskomattoman käyttäjäystävällinen, se tuo myös tiedostot yli, kumoten siten koko Pipelines-työnkulun arvot. Lisäksi, koska se tuo kaikki wp-lataukset uudelleen, se voi johtaa valtaviin tiedostoihin ja latausaikoihin (joten se ei sovellu muutosten siirtämiseen asennusten välillä). Tällainen laajennus on parhaiten varattu koko sivuston varmuuskopioille arkistointia / turvallisuutta varten.

VersionPress näyttää mielenkiintoiselta ratkaisulta, mutta sitä ei vielä ole osoitettu monissa tuotantoympäristöissä. Toistaiseksi plugins kuten WP Sync -tietokanta tai WP Migrate DB Pro näyttävät olevan parhaat ratkaisut tietokantojen hallintaan. Ne mahdollistavat tietokantojen vetämisen / siirtämisen asennusten yli samalla, kun ne tarjoavat mahdollisuuden päivittää URL-osoitteet ja polut automaattisesti. He voivat siirtää vain tietyt taulukot, kuten wp_posts vain postisisällölle, eivätkä tuhlaa aikaa käyttäjien uudelleentuotantoon ja sivuston laajuisiin asetuksiin. Tykkään aina vetää livenä varmistaaksesi, että tuotantotietoja ei korvata. Tässä on esimerkki asennuksesta, jos käytät WP Sync DB: tä (lisää läpikäyntejä saatavilla osoitteessa WP Sync DB github ):

1. Live-sivustolla: Määritä WP Sync -tietokanta valitsemalla Salli vetäminen tästä arkistosta -asetus.
2. Lavastuspaikalla: Määritä WP Sync DB with Pull Live-asetuksista. Nimeä se 'live-to-lavastus'.
3. Paikallisessa kehittäjän asetuksissa: Määritä WP Sync DB with Pull Live-asetuksista. Nimeä se 'live-to-dev'.

Saatat myös haluta asettaa push-dev-to-staging-säännön ja tarkistaa pysäytyspaikan asetukset, jotta tietokanta voidaan korvata.

Käärimistä

Olen havainnut, että nämä menetelmät toimivat yleensä useimmissa käyttötapauksissa, sekä uuden WordPress-verkkosivuston kehittämisessä että jo käytössä olevan sivuston uudelleensuunnittelussa / uudelleenjärjestelyssä.

Se mahdollistaa koodin käyttöönoton, joka pitää kaikki sivustoversiot ajan tasalla ilman lisäaikaa / vaivaa ja tarkoituksellista, turvallista tietokannan siirtologiikkaa sivustojen välillä työskentelyyn. Laajennusten päivittäminen tapahtuu myös lähdekontrollissa, joten laajennusten päivitykset voidaan tarkistaa turvallisesti vaiheittaisesti ennen sitoutumista live-sivustoon, mikä minimoi tuotantopaikan tauot.

Vaikka parantamisen varaa onkin lähteen hallinnan työnkulun lisääminen tietokannan hallintaan, kunnes VersionPressin kaltaista työkalua käytetään enemmän tuotantoympäristöissä, tämä menetelmä tietokannan valikoivasta vetämisestä / työntämisestä WP Sync DB: n tai WP Migrate DB Pron kautta vaikuttaa olla turvallisin tapa käsitellä tätä. On utelias kuulla, mikä toimii WordPress-työnkulullesi, tai jos kaiken tämän jälkeen haluat mieluummin vain tarttua lassoosi ja cowboy-koodiin!

Perustietojen ymmärtäminen

Onko WordPressillä versionhallinta?

WordPressillä ei ole sisäänrakennettua versionhallintaa, joten tarvitaan mukautettu ratkaisu.

Voitteko käyttää GitHubia WordPressin kanssa?

Voit käyttää GitHubia tai muuta versionhallintaratkaisua (GitLab, Bitbucket) WordPressin kanssa, jonka avulla voit käyttää versionhallinnan moderneja kehitysominaisuuksia WordPressin kanssa.

Mikä on ero Bitbucketin ja Bitbucket-palvelimen välillä?

Bitbucket ja Bitbucket Server ovat molemmat versionhallintaratkaisut. Bitbucket on vakiotarjous ja vaatii vähän asennusta, kun taas Bitbucket Server tarjoaa tiimeille enemmän mukautusta ja hallintaa.

Miksi käytämme Bitbucketia?

Bitbucket on luotettu versionhallintaratkaisu Atlassianilta, ja se on tarjonnut rajoittamattomia ilmaisia ​​yksityisiä repoja kauan ennen GitHubia. Se integroituu heidän Pipelines CI / CD -palveluunsa (mikä mahdollistaa jatkuvan integroinnin ja käyttöönoton muutamassa minuutissa) ja heidän Jira-ohjelmistonsa, # 1 -ongelman ja projektin seurantatyökalun.

Mikä on versionhallinnan tarkoitus?

Versiohallinnan avulla kehittäjät ja tiimit voivat päivittää koodin turvallisesti ja nähdä muutokset yhdellä silmäyksellä. Se pitää varmuuskopiot vanhasta koodista ja antaa kehittäjien haarautua pääkoodista toimimaan tiettyjen ominaisuuksien tai virhekorjausten kanssa ja sulautumaan työversioon ja ottaa käyttöön vasta, kun kaikki on hyväksytty.

Kuinka versionhallinta toimii?

Versiohallinta tallentaa tiedostoon (tai tiedostojoukkoon) tehdyt muutokset, jotta niiden historiaa voidaan tarvittaessa tarkistaa myöhemmin. Se voi tuoda esiin eroja eri versioiden välillä, jotta kehittäjät näkevät nopeasti, mikä on muuttunut.