Penerapan Berkelanjutan WordPress dan Kontrol Versi dengan Bitbucket

Oke, teman-teman. Saatnya untuk 'mengaku.

Jika Anda seperti saya, Anda menghabiskan bagian pertama dari tahun pengembangan WordPress Anda "pengkodean koboi"—yaitu, membuat perubahan liar di situs langsung, segera menguji dan mengaktifkannya dengan FTP, sering kali menghasilkan 500 pesan Kesalahan Server Internal dan istirahat di seluruh situs semua terlihat oleh pengunjung Anda yang terhormat.

Sementara ini benar-benar mendebarkan saat adrenalin dipompa melalui jari-jari Anda, berdebar kencang di titik koma yang terlupakan itu, di situs dengan lebih dari 0 pengunjung (yang benar-benar memperhatikan waktu henti) ini akan mulai menjadi masalah. Jika pohon tumbang dan tidak ada orang yang mendengarnya, apakah itu mengeluarkan suara? Tergantung pada teori kemanusiaan yang Anda ikuti.

Namun, jika sebuah situs mogok dan seseorang ada di sana untuk melihatnya, mereka pasti akan mengeluarkan suara.

Penerapan Berkelanjutan WordPress Dilakukan dengan Salah

Masuk ke situs pementasan, duplikat instalasi WordPress (setidaknya secara teori) di mana perubahan dapat dilakukan, lalu buat lagi di situs langsung setelah semuanya dipastikan berfungsi. Sementara ini menenangkan pengunjung, itu mulai membuat kami para pengembang membuat keributan. Tiba-tiba, kami perlu melacak dua situs, memastikan bahwa kode disinkronkan secara manual di antara keduanya, dan menguji semuanya lagi untuk memastikan itu berfungsi di situs langsung. Daftar panjang dan berantakan dari "pastikan untuk mengubah ini secara langsung" dan "pastikan untuk mengaktifkan ini di situs pementasan sebelum menyalin kode" sangat menegangkan, untuk sedikitnya. Pencadangan sistem ini juga merupakan mimpi buruk—banyak folder bernama "my-theme-staging-1" dan "my-theme-live-before-menu-restyle-3" dan seterusnya.

Pasti ada cara yang lebih baik, dan memang ada.

Ada Git, yang memberikan kontrol sumber yang sempurna dan fitur lainnya kepada pengembang. Menggunakan kontrol versi untuk instalasi WordPress secara instan mempercepat dan membersihkan pengembangan, karena berjam-jam tidak lagi dihabiskan untuk mencadangkan dalam sistem per-pengembang tetapi sebenarnya untuk pengkodean. Perubahan disimpan dan saya akhirnya dapat menambahkan pesan yang bermakna ke pekerjaan saya, dunia yang berbeda dari "tema-saya-4-v2."

Meskipun basis kode jauh lebih bersih, masalahnya masih ada pada penerapan aktual dan memastikan situs yang dimaksud menggunakan kode terbaru—masukkan peluang untuk kesalahan manusia. Masih mengandalkan unggahan FTP manual yang menimpa kode sebelumnya tidak terasa hebat. Sementara layanan CI/CD lainnya ada, banyak dari mereka datang dengan label harga yang substansial dan sejumlah besar pengaturan—pengaturan ulang server, mengandalkan layanan lain bahkan untuk situs web yang paling sederhana, mempelajari seluruh "cara melakukan sesuatu" layanan lain dan semua keistimewaan yang menyertainya.

Meskipun pengaturan serupa dengan tutorial ini dapat dilakukan dengan GitHub/GitLab dan layanan lainnya, saya telah meletakkan telur saya di keranjang Atlassian sejak awal karena repositori pribadi gratis mereka (yang hanya merupakan penawaran terbaru dari GitHub). Ketika Bitbucket memperkenalkan layanan Pipelines dan Deployment mereka, itu memungkinkan kode baru untuk secara otomatis diterapkan ke staging atau situs produksi (atau situs lain di antaranya) tanpa mengunggah ulang melalui FTP atau menggunakan layanan eksternal. Pengembang sekarang dapat menggunakan semua nilai kontrol sumber dalam pengembangan WordPress mereka dan secara instan mengirim perubahan tersebut ke tujuan yang sesuai tanpa klik atau penekanan tombol tambahan, dengan status semuanya terlihat melalui satu dasbor. Ini memastikan semuanya tetap sinkron dan, sekilas, memungkinkan Anda mengetahui dengan tepat kode apa yang dijalankan setiap situs. Selain itu, harga untuk menit pembuatan Bitbucket sangat terjangkau—dengan 50 menit gratis per bulan dan opsi untuk paket “Gratis dengan Kelebihan”.

Butuh sedikit waktu startup untuk mencari tahu cara terbaik menggunakan cabang dan fitur lain dari kontrol sumber dalam model baru ini dan rincian penyiapan Bitbucket Pipelines. Inilah proses yang saya gunakan untuk memulai proyek WordPress baru. Saya tidak akan membahas semua seluk beluk dalam menyiapkan instalasi git dan WordPress karena sumber daya yang bagus untuk itu hanya berjarak pencarian Google. Pada akhirnya, aliran konten akan menjadi seperti ini:

Rutinitas Penyebaran WordPress Alexa Green

Langkah-langkah yang diuraikan di sini harus dilakukan sesuai kebutuhan:

Di Server Klien

Siapkan domain untuk situs langsung (misalnya, clientsite.com) dan subdomain untuk staging (misalnya, staging.clientsite.com).

Instal WordPress di situs langsung dan subdomain pementasan. Ini dapat dilakukan melalui cPanel/Softaculous (jika hosting klien memilikinya) atau dengan mengunduh dari wordpress.org. Pastikan bahwa ada database terpisah untuk live dan staging masing-masing.

Di Bitbucket.com

Siapkan repositori baru. Sertakan .README untuk membuat kami aktif dan maju.

Di repositori, Settings > Pipelines > Settings lalu centang Enable Pipelines .

Di Pengaturan > Saluran > Variabel repositori , masukkan yang berikut ini:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Kembali ke Pipelines > Settings dan klik tombol Configure bitbucket-pipelines.yml . Pilih PHP sebagai bahasa pada halaman berikut. Anda akan ingin menggunakan sesuatu seperti kode berikut. Pastikan untuk mengganti versi PHP dengan apa pun yang Anda gunakan di server klien, dan URL/server FTP dengan URL/server FTP situs klien yang sebenarnya (produksi dan staging).

 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 

Klik Komit file . Pengaturan Pipelines sekarang akan dilakukan dan dijalankan.

Jika semuanya berhasil disebarkan, kembali dan edit file bitbucket-pipelines.yml (Anda bisa mendapatkannya melalui Pipelines > Settings dan View bitbucket-pipelines.yml ). Anda akan ingin mengganti kedua tempat di mana dikatakan git ftp init dengan git ftp push dan save/commit. Ini akan memastikan bahwa hanya file yang diubah yang diunggah, sehingga menghemat menit pembuatan. File bitbucket-pipelines.yml Anda sekarang seharusnya terbaca:

 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 

Tambahkan cabang bernama main-dev .

Di Mesin Lokal Anda

Kloning repositori ke direktori kosong yang ingin Anda gunakan untuk instalasi lokal. Lihat cabang main-dev .

Siapkan instalasi WP lokal di direktori ini. Ada banyak alat untuk ini—Lokal oleh Flywheel, MAMP, Docker, dll. Pastikan semuanya sama (versi WordPress, versi PHP, Apache/Nginx, dll.) dengan yang berjalan di server klien.

Tambahkan .gitignore yang terlihat seperti ini. Pada dasarnya kami ingin agar Git mengabaikan semuanya kecuali konten-wp (untuk mencegah masalah penginstalan di antara penginstalan). Anda mungkin juga ingin menambahkan aturan Anda sendiri untuk mengabaikan file cadangan besar dan ikon yang dibuat sistem dan file 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

Simpan dan komit .gitignore .

Buat perubahan dan komit sesuai dengan itu.

Setiap kali Anda berkomitmen untuk main-dev, itu akan mengaktifkan unggahan FTP ke situs pementasan. Setiap kali Anda berkomitmen untuk menguasai, itu akan mengaktifkan unggahan FTP ke situs produksi. Perhatikan bahwa ini akan menggunakan menit pembuatan, jadi Anda mungkin ingin melakukan sebagian besar perubahan lokal pada cabang dari dev utama, lalu bergabung ke dev utama setelah Anda selesai untuk hari itu.

Menggabungkan main-dev menjadi master akan membawa semua perubahan staging secara langsung. Anda dapat memeriksa status Pipelines dan Deployment pada repo di Bitbucket.org.

Menyinkronkan Basis Data WordPress di Seluruh Instalasi

Perhatikan bahwa di atas hanya akan menyinkronkan file (tema, plugin, dll). Menyinkronkan database antara produksi dan pementasan menjadi masalah yang berbeda, karena sering kali klien membuat perubahan di situs langsung yang tidak tercermin di situs pementasan, dan sebaliknya.

Untuk menyinkronkan database di seluruh instalasi WordPress, ada beberapa opsi. Secara tradisional, Anda dapat memperbarui database dengan mengimpor/mengekspor melalui phpmyadmin . Ini rumit, karena tidak dapat memperbarui hal-hal tertentu yang perlu diperbarui, seperti tautan permanen di konten posting. Dengan menggunakan metode ini, alat favorit adalah plugin Velvet Blues Update URLs, yang kemudian dapat Anda gunakan untuk mencari/mengganti semua contoh URL situs lama (misalnya, https://staging.clientsite.com) ke URL situs baru ( misalnya, https://clientsite.com). Anda juga dapat menggunakan ini dengan jalur dan string relatif. Metode ini akhirnya meninggalkan banyak ruang untuk kesalahan manusia—jika string yang diganti salah ditulis, dapat menyebabkan seluruh situs rusak dan tidak dapat menggunakan plugin/mengakses dasbor.

Sementara plugin seperti All-in-One WP Migration menawarkan fitur pencarian/penggantian di luar kotak dan sangat ramah pengguna, plugin ini juga membawa file, sehingga membatalkan nilai seluruh alur kerja Pipeline kami. Plus, karena mengimpor ulang semua unggahan wp, ini dapat menghasilkan file besar dan waktu pemuatan (sehingga tidak layak untuk memindahkan perubahan di seluruh instalasi). Plugin seperti ini paling baik disediakan untuk cadangan seluruh situs untuk tujuan pengarsipan/keamanan.

VersionPress sepertinya merupakan solusi yang menarik, tetapi belum terbukti di banyak lingkungan produksi. Untuk saat ini, plugin seperti WP Sync DB atau WP Migrate DB Pro tampaknya menjadi solusi terbaik untuk manajemen database. Mereka memungkinkan untuk menarik/mendorong database di seluruh instalasi sambil memberikan opsi untuk memperbarui URL dan jalur secara otomatis. Mereka hanya dapat memigrasikan tabel tertentu, seperti wp_posts untuk konten posting saja, tidak membuang waktu untuk mengimpor ulang pengguna dan pengaturan di seluruh situs. Saya suka selalu menarik dari siaran langsung untuk memastikan tidak ada data produksi yang ditimpa. Berikut ini contoh pengaturan jika Anda menggunakan WP Sync DB (lebih banyak panduan tersedia di github WP Sync DB):

1. Di situs langsung: Siapkan WP Sync DB dengan pengaturan "Izinkan Tarik dari repositori ini" diaktifkan.
2. Di situs pementasan: Siapkan WP Sync DB dengan Tarik dari pengaturan Langsung. Beri nama "langsung-ke-pementasan."
3. Pada pengaturan dev lokal Anda: Siapkan WP Sync DB dengan Tarik dari pengaturan Live. Beri nama "live-to-dev."

Anda mungkin juga ingin menyiapkan aturan "dev-to-staging" yang mendorong, dan memeriksa pengaturan situs staging untuk mengizinkan database ditimpa.

Membungkus

Saya telah menemukan metode ini cenderung berfungsi untuk sebagian besar kasus penggunaan, baik dalam mengembangkan situs web WordPress baru dan untuk mendesain ulang/mengatur ulang situs yang sudah aktif.

Ini memungkinkan penerapan kode yang membuat semua versi situs tetap mutakhir tanpa tambahan waktu/usaha dev dan logika migrasi basis data yang disengaja dan aman untuk bekerja antar situs. Memperbarui plugin juga dilakukan di dalam kontrol sumber, sehingga pembaruan plugin dapat diperiksa dengan aman pada staging sebelum berkomitmen ke situs langsung, sehingga meminimalkan jeda situs produksi.

Meskipun ada ruang untuk perbaikan untuk membawa lebih banyak alur kerja kontrol sumber ke manajemen basis data, hingga alat seperti VersionPress lebih banyak digunakan di lingkungan produksi, metode penarikan/pendorongan selektif basis data ini melalui WP Sync DB atau WP Migrate DB Pro tampaknya menjadi metode yang paling aman untuk menangani hal ini. Ingin tahu apa yang berhasil untuk alur kerja WordPress Anda, atau jika setelah semua ini Anda lebih suka mengambil kode laso dan koboi Anda!