Penerapan Modern untuk Situs WordPress Anda

Diterbitkan: 2022-06-30

Jika Anda seperti saya, pengalaman pertama Anda memasukkan file ke server web adalah melalui pengelola file berbasis web seperti cPanel atau klien File Transfer Protocol (FTP) seperti Transmit atau Filezilla. Sambungkan ke server, seret file Anda, dan tunggu transfer selesai.

Mudah, bukan?

Namun, segera setelah saya mulai bekerja dengan sesuatu yang lebih kompleks daripada file HTML statis, penerapan kode saya menjadi jauh lebih kompleks: apa yang terjadi jika saya melewatkan file yang dibutuhkan oleh orang lain, atau titik koma dalam penyertaan global dan itu menyaring putih seluruh situs? Bagaimana jika langkah penting terlewatkan selama proses?

Masalah "pengkodean koboi" ini hanya menjadi lebih buruk karena lebih banyak orang, lingkungan, dan ketergantungan terlibat. Akibatnya, semakin sulit untuk terus membuat kemajuan sambil menyulap semua bagian yang bergerak ini. Yang terburuk, merilis kode menjadi masalah besar dan sumber kecemasan yang konstan.

Saat aplikasi, situs, dan toko kami menjadi lebih modern, kami juga harus memodernisasi penerapan kami. Dari kontrol versi hingga pengiriman berkelanjutan, proses rilis modern dapat meredakan kecemasan seputar penerapan.

Melacak Perubahan Dengan Kontrol Versi

Langkah pertama untuk menjauh dari pembaruan ad-hoc dan pengkodean koboi adalah dengan membuat situs Anda di bawah kendali versi, menggunakan alat seperti Git.

Menggunakan kontrol versi berarti Anda akan dapat melihat apa yang telah berubah, siapa yang membuat perubahan, dan bahkan mengerjakan beberapa set perubahan secara bersamaan dengan menggunakan cabang. Akibatnya, pekerjaan tidak ditimpa dan konflik apa pun di antara file disorot dengan jelas.

Jika Anda belum pernah bekerja dengan Git sebelumnya, jangan takut: kami telah menulis pengantar untuk Git serta posting tentang alur kerja Git yang lebih maju.

Memutuskan Apa yang Akan Dilacak

Saat kami memindahkan situs kami di bawah kontrol versi, apa yang tidak kami lacak hampir sama pentingnya dengan apa yang kami lakukan:

Secara umum, kontrol versi adalah untuk melacak kode sumber, bukan aset yang dihasilkan oleh alat atau proses . Ini mencakup hal-hal seperti CSS dan JavaScript yang digabungkan/diperkecil, dependensi eksternal, dll. Secara kolektif, kami menyebut item ini sebagai artefak .

Misalnya, jika Anda menggunakan praprosesor CSS seperti Sass, file CSS yang dihasilkan tidak boleh dilacak di bawah kontrol versi. Tidak hanya mereka mudah direproduksi, mereka sulit dibaca dan sumber umum konflik gabungan ketika banyak pengembang terlibat.

Dalam hal dependensi (perpustakaan, plugin WordPress, dll.), manfaatkan alat seperti Composer dan WPackagist daripada menggabungkan kode yang tidak bertanggung jawab dalam repositori Anda.

Selain itu, repositori Git tidak boleh berisi hal-hal seperti kata sandi, kunci SSH pribadi, atau informasi rahasia lainnya yang akan dianggap rahasia , karena setiap pengembang dengan salinan repositori akan memiliki informasi sensitif tersebut di komputer mereka.

Penataan Repositori Anda

Saat menyiapkan repositori Git untuk situs WordPress atau WooCommerce, biasanya yang terbaik adalah memperlakukan wp-content/ sebagai root repositori, karena Anda biasanya tidak akan menyentuh file di atas direktori ini.

Plugin dan tema yang digunakan situs Anda tetapi Anda tidak memelihara kodenya harus dimuat melalui Composer, karena keduanya merupakan dependensi eksternal. Demikian juga, file CSS dan JavaScript yang diproses harus dikecualikan melalui file .gitignore, karena artefak ini akan dibuat untuk kami sebagai bagian dari proses rilis kami.

Kami memiliki template repositori gratis yang tersedia di GitHub untuk membantu Anda memulai.

Pengantar CI/CD

Ketika datang untuk menyebarkan perangkat lunak, ada dua istilah penting untuk dipahami: Continuous Integration (CI) dan Continuous Delivery (CD).

Kedua istilah ini terkait erat, sehingga sering disebut secara kolektif sebagai "CI/CD", dan jalur yang dilalui perubahan kita menjadi "pipa CI/CD". Pipa ini biasanya mengambil bentuk berikut:

  1. Bangun rilis: instal dependensi (Komposer, npm, dll.), lalu buat artefak (Webpack, Grunt, Sass, dll.)
  2. Uji build: jalankan pengujian unit, periksa standar pengkodean, lakukan analisis kode statis, dll.
  3. Terapkan rilis ke satu atau beberapa lingkungan

Integrasi Berkelanjutan adalah proses pengujian kode kami secara terus-menerus untuk memastikan bahwa perubahan tidak merusak fungsionalitas yang ada, sehingga perubahan baru kami terintegrasi dengan rapi dengan basis kode yang ada. Setiap kali perubahan baru didorong, pemeriksaan dijalankan untuk memastikan kami tidak "melanggar pembangunan".

Agar integrasi berkelanjutan bermanfaat, pemeriksaan ini harus otomatis. Misalnya, jika Anda memiliki rangkaian pengujian unit, Anda dapat memilih untuk menjalankan rangkaian pengujian ini setiap kali permintaan tarik baru dibuka, yang memperingatkan Anda tentang kemungkinan kerusakan sebelum kode masuk ke produksi.

Integrasi berkelanjutan tidak terbatas pada pengujian unit, karena ada sejumlah pemeriksaan "bebas kode" yang dapat dijalankan secara otomatis terhadap kode Anda, termasuk:

  • Pemeriksaan standar pengkodean (PHP_CodeSniffer, Pemecah Standar Pengkodean PHP)
  • Analisis kode statis (PHPStan, Psalm)

Menjalankan pemeriksaan ini secara otomatis pada setiap push juga memastikan bahwa semua kode dijalankan melalui pemeriksaan yang sama, mencegah kode yang tidak lolos dirilis.

Pengiriman Berkelanjutan , di sisi lain, adalah gagasan bahwa kita harus dapat "menyampaikan" (menyebarkan) kode kita pada saat tertentu. Untuk mencapai ini, kita harus memiliki proses penerapan skrip yang, dengan mengklik tombol, akan dengan mulus memindahkan kode kita ke dalam produksi.

Memiliki skrip penerapan berarti Anda dapat menerapkan secara teratur dan konsisten ; setiap penerapan harus bekerja sama seperti yang sebelumnya. Hasilnya, tim Anda dapat menerapkan lebih teratur dengan tingkat kepercayaan yang lebih tinggi dan lebih sedikit kekhawatiran bahwa seseorang melewatkan satu langkah di sepanjang jalan. Untuk beberapa tim, tidak jarang menggunakan lusinan (atau bahkan ratusan) kali sehari!

Tergantung pada situs Anda, Anda bahkan mungkin ingin melihat ke "CD lain", Continuous Deployment ; ini sangat mirip dengan pengiriman berkelanjutan, tetapi di bawah model ini setiap dorongan ke cabang akan disebarkan secara otomatis. Ini bisa menjadi sangat kuat saat menggunakan skema kontrol versi bercabang (seperti Github Flow), tetapi mungkin tidak diinginkan jika Anda perlu menjadwalkan jendela rilis atau melakukan semua pekerjaan di cabang utama.

Menyebarkan Situs WordPress atau WooCommerce Dengan CI/CD

Sekarang setelah kita memahami terminologi dasar, mari kita lihat penerapan situs WordPress atau WooCommerce yang khas:

Untuk latihan ini, kita akan menggunakan Branch, alat CI/CD yang dirancang untuk memenuhi kebutuhan pengembang WordPress dari orang yang sama di belakang WP Pusher. Yang terbaik dari semuanya, Branch memiliki dukungan bawaan untuk penerapan ke Nexcess!

Untuk memulai, daftar ke Cabang dengan menghubungkan akun GitHub, GitLab, atau Bitbucket Anda, lalu buat situs pertama Anda.

Selanjutnya, kami ingin mengonfigurasi semua langkah yang diperlukan untuk membangun situs kami. Branch menawarkan sejumlah "resep" untuk tindakan umum (menginstal dependensi Composer, menjalankan Webpack, dll.), tetapi juga memberi kita kemampuan untuk menambahkan sejumlah langkah kustom.

Setelah kami menguraikan langkah-langkah yang diperlukan untuk membangun situs kami, kami dapat melanjutkan ke tahap berikutnya dari saluran kami: pengujian.

Jika Anda sudah memiliki rangkaian pengujian otomatis untuk situs Anda, Anda cukup memberi tahu Branch untuk menjalankan perintah apa pun yang diperlukan. Bahkan jika Anda belum memiliki pengujian, Branch memudahkan Anda untuk menambahkan linting, standar pengkodean, dan pemeriksaan kompatibilitas.

Sekarang kita telah menginstal dependensi kita, membangun semuanya, dan lulus pengujian, saatnya untuk memasukkan kode kita ke dalam produksi!

Cabang berisi resep untuk menyebarkan ke Nexcess (serta penyedia hosting utama lainnya), dan menghubungkan kedua platform tidak menyakitkan:

  1. Pilih situs Anda di dasbor Cabang, klik "Pengaturan", lalu ambil kunci SSH publik situs Cabang Anda
  2. Tambahkan kunci publik ini ke daftar kunci dalam portal Nexcess

Setelah Branch dapat berkomunikasi dengan situs Nexcess Anda, kami dapat memilih resep penerapan "Nexcess" dan mengisi beberapa detail:

  1. Nama host dan nama pengguna untuk situs (tersedia melalui portal Nexcess di layar "Akses" situs Anda)
  2. Akar web tempat kami menerapkan. Jika git repo kami dimaksudkan untuk berfungsi sebagai direktori wp-content/, nilai ini harus "public_html/wp-content".
  3. File yang ingin kami gunakan (umumnya default, "*", sudah cukup)
  4. Cabang git untuk diterapkan ke lingkungan ini

Pengaturan "Cabang Git" sangat penting, karena ini memungkinkan Anda menentukan penerapan yang berbeda untuk cabang yang berbeda. Misalnya, Anda mungkin memiliki cabang "pementasan" yang diterapkan ke lingkungan pementasan Anda, memungkinkan Anda menguji perubahan sebelum membuatnya aktif.

Perlu dicatat bahwa Branch menggunakan model continuous deployment secara default, di mana pipeline berjalan dengan setiap push ke cabang yang diberikan. Jika Anda lebih menyukai model pengiriman berkelanjutan (di mana beberapa tindakan manual harus dilakukan), Anda dapat mempertimbangkan untuk mempertahankan cabang "produksi" yang hanya akan digabungkan saat Anda siap untuk merilis.

Pada titik ini, Branch harus dikonfigurasi untuk membangun dan menyebarkan repositori git Anda ke Nexcess! Anda dapat memicu penerapan pertama Anda dengan mengklik tombol "Jalankan Penerapan" di halaman "Pipa" situs Anda atau dengan mendorong ke repositori Git Anda.

Menyesuaikan Proses Rilis Anda

Salah satu fitur yang sangat bagus dari Branch adalah kemampuan untuk mengonfigurasi langkah-langkah tambahan setelah penerapan yang berhasil, seperti membersihkan cache objek situs Anda secara otomatis setelah penerapan. Ini dapat dicapai dengan menggunakan resep WP-CLI di bawah "Lainnya."

Host dan nama pengguna umumnya akan sama seperti yang kita gunakan pada langkah penerapan, dan Anda dapat merangkai perintah sebanyak yang diperlukan.

Kesimpulan

Jika Anda masih berjuang dengan kejenakaan pengkodean koboi dan/atau rilis yang penuh kecemasan, lihat Branch dan buat penerapan menjadi mudah!