Ortamlar Arasında WordPress Veritabanı Değişikliklerini Senkronize Etme: 2022'de Birleşmeyi Nasıl Yönetiyoruz?

Veritabanı senkronizasyonu, parçası olduğum yerel WordPress topluluklarında neredeyse her ay gündeme gelen bir sorundur – “yerel sitemde değişiklik yapıyorsam, canlı sitede yapılan güncellemelere ne olur, yerel sitemi zorlarsam veritabanı yeniden hayata mı döndü?”

9 ay sonra ilk #WordPress Buluşması, konuştuğum ilk kişi, konuştukları ilk sorun: veritabanı birleştirme

— Iain Poulson (@polevaultweb) 28 Haziran 2018

WordPress resmi olarak yetişkin hale geldiğinde, bu şimdiye kadar çözmemiz gereken bir şey değil mi? Brad'in 2014'te WordCamp Miami'de bu sorun hakkında konuşmasından bu yana herhangi bir değişiklik oldu mu? Bu gönderide, sorunu yeniden ele alacağım, sahip olduğunuz seçeneklere bakacağım, sitelerimiz için bununla nasıl başa çıktığımızı paylaşacağım ve mevcut hazır seçenekleri gözden geçireceğim.

Sorun nedir?

Bu, canlı bir sürümü de çalışan bir WordPress sitesinin yerel geliştirme kopyası üzerinde çalışan hemen hemen tüm geliştiriciler için var olan bir sorundur. Geliştirici yerel olarak değişiklikler yapar, tema ayarlarını yapılandırır, yeni sayfalar ekler, Gelişmiş Özel Alanlar ekler, eklenti seçeneklerini düzenler, vb. Bu arada, canlı sürüm sürekli değişim altındadır. Ya müşteri tarafından, belki yeni blog gönderileri yazarak ya da e-ticaret siteleri söz konusu olduğunda, yeni ürünler ekleyerek ya da sipariş veren müşteriler tarafından. Geliştirici, yerel değişikliklerini canlı siteye aktarmaya hazır olduğunda, canlı sitedeki herhangi bir değişikliğin üzerine yazma şansı vardır. Bu, veritabanına dayalı tüm içerik yönetim sistemlerini etkileyen bir sorundur ve WordPress site geliştirmenin en zor kısımlarından biridir. Halihazırda, bu değişiklikleri güzel ve basit bir birleştirme ile uzlaştırmanın kolay bir yolu yoktur.

Ugh… Geliştirme ortamı ve üretim arasındaki veritabanı değişikliklerini birleştirmekten nefret ediyorum. #wordpress #dba #devlife

— Shawn Hooper (@ShawnHooper) 4 Ocak 2015

Geçici Çözümler Çalışmadığında

Basit broşür veya pazarlama siteleri için veri birleştirme ve çakışma çözümü gerekli değildir. Herhangi bir geliştirme döngüsü sırasında, canlı sitedeki veriler büyük ölçüde değişmeden kalır. WP Migrate DB Pro gibi bir eklenti kullanarak, herhangi bir yeni medya dosyasının kopyalanması ve MySQL veritabanındaki tabloların değişikliklerle kısmi olarak itilmesi yeterli olacaktır. Daha karmaşık sitelerde, WordPress'in kullandığı (ve geliştiricilerin kullanmaya teşvik ettiği) veri mimarisi, seçici veri geçişleri gerçekleştirmeyi son derece zorlaştırır.

Örneğin, canlı sitede değişen tek verinin mağaza sahiplerinin ürünleri ve müşterilerden gelen siparişler olduğu e-ticaret mağazalarında, teorik olarak kısmi bir veri geçişi çalışmalıdır. İdeal olarak, bu veri parçalarını depolayan veri tabloları, site geliştirme sırasında yapılan diğer veri değişiklikleri gönderilirken göz ardı edilebilir. WordPress ile tek bir sorun var – özel gönderi türleri.

Özel Gönderi Türleri Neden Sorunu Karmaşıklaştırıyor?

WordPress, farklı türlerdeki veri nesnelerinin wp_posts tablosunda saklanmasına izin veren son derece esnek bir veri yapısına sahiptir. Farklı veri nesneleri, özel gönderi türleri olarak bilinir ve türleri, wp_posts tablosundaki post_type sütunu tarafından tanımlanır. Bu, yalnızca gönderiler için değil, aynı zamanda sayfalar, menüler, ekler, revizyonlar, menü öğeleri ve özel gönderi türü olarak kaydedilen herhangi bir özel veri nesnesi için veri kayıtlarını tutan tablo için en sezgisel ad değildir. Bir emlak sitesi için 'ev', bir hayvan kurtarma sitesi için 'hayvan' veya bir ürün sitesinin dokümantasyon kısmı için sadece 'doküman' olarak düşünün.

Özel gönderi türleri WordPress 3.0'a geldiğinde, WordPress kurulumlarının sadece bloglardan daha fazlası olmasını sağlayan bir özellik çok sevindiriciydi. Ancak, özel gönderi türlerinin ve veri modeli uygulamalarının WordPress ekosistemi için zararlı hale geldiğine inanıyorum.

Bir yandan, bu, yeni veri nesnelerini yalnızca birkaç satır kodla kaydetmek için basit bir PHP API'sine sahip, güzel, basit ve esnek bir sistemdir. Özel bir gönderi türü kaydettiğinizde, kendiniz kodlamak zorunda kalmadan birçok işlevselliğe ücretsiz olarak sahip olursunuz; yeni bir menü seçeneği, nesnelerin basit CRUD yönetimi, listeleme ve toplu işlemler için bir tablo arayüzü ve hatta REST API uç noktaları.

Öte yandan, yeni türlerin kaydedilme kolaylığı, bazen yanlış türde veri nesnelerinin bu şekilde depolandığı anlamına gelir. Daha önceki e-ticaret ürünleri ve siparişleri örneğim gibi – bir mağaza sahibi için en kritik veriler, diğer tüm gönderi türleriyle aynı tabloda tutulur. Canlı site, yeni siparişler oluşturuldukça wp_posts eklenen yeni kayıtları almaya devam edecek. Yerel sitedeki gönderilerde veya sayfalarda herhangi bir değişiklik yapılırsa, wp_posts tablosu artık bu siparişleri kaybetmeden yayına geri alınamaz!

Özel gönderi türleri, bir WordPress sitesi için başka sorunlar da oluşturabilir. Her tür veriyi depolamak için bunları kullanmak performans sorunlarına neden olabilir. WordPress, sitenin ön ucunda gönderileri, sayfaları ve diğer gönderi türlerini görüntülerken sürekli olarak wp_posts tablosunu sorgular ve bu tablo büyüdükçe bu sorgular daha yavaş olur. Elbette önbelleğe alma yardımcı olabilir, ancak potansiyel olarak büyük bir boyuta ulaşabilecek verilerin nerede depolanacağına karar verirken daha fazla özen gösterilmelidir.

Örneğin, Easy Digital Downloads şu anda bir öğenin her indirilmesini kaydeden bir 'edd_log' gönderi türünü kaydeder. Günlük kaydı, potansiyel olarak wp_posts tablosunda gereksiz olan çok sayıda satıra ölçeklenebileceğinden, kendi tablosuna sahip olması gereken bir işlem verisidir. Bunun olduğunu ilk elden gördüm:

@eddwp Easy Digital Downloads 3.0 hakkında heyecanlandığımı söylemek yetersiz kalır!

Özel gönderi türlerini özel veritabanı tabloları lehine değiştirecek ve umarım sitemdeki bazı performans iyileştirmelerini geri alacaktır. pic.twitter.com/IMVaeRs2UR

— Iain Poulson (@polevaultweb) 16 Mayıs 2019

Neyse ki eklenti mağazaları bu sorunların farkında ve yaklaşımlarını değiştiriyor.

WooCommerce, 2016'dan beri ürün ve ürün metalarını özel tablolara taşımak için çalışıyor. Siparişleri kendi masasına taşıma çalışmaları 2018'de durdu, ancak bu yılın başlarında özel bir sipariş tablosu için resmi bir plan duyurdular. Şu anda bunun ne zaman uygulanacağına dair bir ETA yok, ancak ilgilenen herkes GitHub proje panosunu takip edebilir.

EDD ekibi, tüm özel gönderi türlerini özel tablolara tamamen taşıyacak olan büyük 3.0 güncellemesi üzerinde çalışıyor. John James Jacoby (JJJ), WordCamp Europe 2019'da özel tabloları yönetme ve bunlara erişmeye yönelik yeni bir yaklaşım hakkında konuştu. Ancak, EDD 3.0 hala genel beta sürümündedir ve üretim siteleri için henüz hazır değildir.

Elbette, bu iyileştirmeler yardımcı olurken, veritabanı birleştirme sorununu hiçbir zaman tam olarak çözmeyecektir. Bir veritabanı geçişinden belirli tabloları yok saymak sizi yalnızca bir yere kadar götürür. Çoğu zaman, canlı siteler, bir geliştirme sitesinde yapılan herhangi bir değişikliğin otomatik olarak yeniden birleştirilemeyeceği şekilde değişiyor ve manuel yaklaşımın muhtemelen hala en iyisi olduğu yer burası.

Hangi Alternatiflere Sahipsiniz?

Artık emekli olan Mergebot'u inşa ettiğimizde geldiğimiz gerçek buydu. Veritabanına yazan her eklenti veya tema için, kimlikleri ve çakışmaları doğru bir şekilde işleyebilmeniz için verilerini nasıl sakladığını bilmeniz gerekir. Tüm bu çatışmaları çözmeye çalışmak çok karmaşık hale geliyor. Tüm ana eklentileri ve temaları destekleyen bir çözümle bile, geliştiricilerin desteklenmeyen eklentileri/temaları manuel olarak yapılandırmaları gerekir, bu da genellikle veritabanı konuşlandırma sorununun kendisinden daha zahmetlidir. Bunu yalnızca bir kez yapmanız gerekseydi, o kadar da kötü olmazdı, ancak bir eklenti veya tema her güncellendiğinde, verileri depolama şeklini değiştirebilir. Hiç bitmeyen büyük bir güçlük.

Bu çatışmaları azaltmanın birkaç yolu vardır.

SQL Komut Dosyaları

Çözümlerden biri, herhangi bir veri değişikliğini yerel geliştirme ortamınızda SQL komut dosyaları olarak kaydetmektir. Basit bir örneğe bakalım. WooCommerce'i yüklemek, örneğin ödeme ve hesabım sayfaları gibi birkaç sayfa oluşturmanızı gerektirir. Bu sayfalar oluşturulur oluşturulmaz, bu sayfaları oluşturmak için kullanılan sorguları içeren bir SQL dosyası oluşturmak için verileri veritabanından dışa aktarabilirsiniz:

 INSERT INTO `wp_posts` (`ID`, `post_author`, `post_date`, `post_date_gmt`, `post_content`, `post_title`, `post_excerpt`, `post_status`, `comment_status`, `ping_status`, `post_password`, `post_name`, `to_ping`, `pinged`, `post_modified`, `post_modified_gmt`, `post_content_filtered`, `post_parent`, `guid`, `menu_order`, `post_type`, `post_mime_type`, `comment_count`) VALUES (NULL, 1, '2013-02-27 21:03:13', '2013-02-28 01:03:13', '[woocommerce_checkout]', 'Checkout', '', 'publish', 'closed', 'closed', '', 'checkout', '', '', '2013-11-04 09:52:16', '2013-11-04 13:52:16', '', 0, 'http://yourwebsite.com/checkout/', 0, 'page', '', 0), (NULL, 1, '2013-02-27 21:03:13', '2013-02-28 01:03:13', '[woocommerce_my_account]', 'My Account', '', 'publish', 'closed', 'closed', '', 'my-account', '', '', '2013-11-04 09:52:50', '2013-11-04 13:52:50', '', 0, 'http://yourwebsite.com/my-account/', 0, 'page', '', 0);

Değişikliklerinizi dağıtmaya hazır olduğunuzda, SQL komut dosyalarınızı üretim veritabanına aktarın ve artık hazırsınız.

PHP Komut Dosyaları

Daha sonra SQL sorgularını kaydetmek yerine, verileri oluşturan bir PHP betiği yazabilirsiniz. Tabii ki, SQL sorgularını da buraya dahil edebilirsiniz, ancak daha fazlasını da yapabilirsiniz. Örnek olarak yukarıdaki senaryoyu tekrar kullanalım, ancak bunun yerine değişiklikleri dağıtmak için bir fonksiyon yazacağım.

 /* * To run the deployment * 1. Log in as an administrator * 2. Go to http://hellfish.media/?deploy_changes=1 */ add_action( 'template_redirect', 'deploy_changes' ); function deploy_changes() { // If the request is not our deployment if ( !isset( $_GET['deploy_changes'] ) ) { return; } // Only allow a logged in admin to run the deployment if ( !current_user_can( 'install_themes' ) ) { echo 'Not logged in.'; exit; } // Run script for 5 mins max set_time_limit(60*5); $pages = array( array( 'content' => '[woocommerce_checkout]', 'title' => 'Checkout' ), array( 'content' => '[woocommerce_my_account]', 'title' => 'My Account' ) ); foreach ( $pages as $page ) { $new_page = array( 'post_type' => 'page', 'post_title' => $page['title'], 'post_content' => $page['content'], ); wp_insert_post( $new_page ); } echo 'Deployment complete.'; exit; }

Bu kodu özel bir maintenance.php dosyasına koyabilir ve bunu functions.php dosyasından temanıza ekleyebilir veya temaya eklemek yerine özel bir WordPress eklentisi olarak ekleyebilirsiniz, ancak her iki şekilde de çalışır. Dağıtıma hazır olduğunuzda, bu kodu canlı sitenize gönderin ve yönetici olarak oturum açın. Ardından, deploy_changes sorgu dizesini etki alanınızın sonuna ekleyerek kodu çalıştırın, örneğin:

 http://hellfish.media/?deploy_changes=1

Değişiklikleri yaptıktan sonra, dağıtımı yanlışlıkla yeniden çalıştırmadığınızdan emin olmak için işlevi dosyadan kaldırın (veya eklentiyi devre dışı bırakın). Kaynak denetimi (Git gibi), bir daha ihtiyaç duymanız durumunda her zaman eski dağıtım kodunun geçmişini tutmanızı sağlar.

Bunu bir adım daha ileri götürebilirsiniz. Özel bir eklentide, veritabanında eklenti için bir sürüm numarası saklayabilir ve yalnızca sürüm numarasına bağlı olarak belirli değişiklikleri çalıştırabilirsiniz. Bu şekilde, sürüm numarasına göre çalışan yeni bir kod eklemeniz ve her kod bölümü çalıştırıldıktan sonra sürüm numarasını güncellemeniz yeterlidir. Bu sürüm kontrol yöntemini kullanarak yeni bir sayfa eklemek için yukarıdaki örneği genişletelim.

 /* * To run the deployment * 1. Log in as an administrator * 2. Go to http://hellfish.media/?deploy_changes=1 */ add_action( 'template_redirect', 'deploy_changes' ); function deploy_changes() { // If the request is not our deployment if ( ! isset( $_GET['deploy_changes'] ) ) { return; } // Only allow a logged in admin to run the deployment if ( ! current_user_can( 'install_themes' ) ) { echo 'Not logged in.'; exit; } // Run script for 5 mins max set_time_limit( 60 * 5 ); // get the version number form the wp_options table, or default to 0 $version = get_option( 'hellfish_custom_plugin_version', '0' ); // only run if the $version is 0 if ( version_compare( $version, '0', '=' ) ) { $pages = array( array( 'content' => '[woocommerce_checkout]', 'title' => 'Checkout' ), array( 'content' => '[woocommerce_my_account]', 'title' => 'My Account' ) ); deploy_pages( $pages ); // update the version stored in the wp_options table update_option( 'hellfish_custom_plugin_version', '1' ); echo 'Deployment complete.'; exit; } // only run if the $version is 1 if ( version_compare( get_bloginfo( 'version' ), '1', '=' ) ) { $pages = array( array( 'content' => '[woocommerce_cart]', 'title' => 'Cart' ) ); deploy_pages( $pages ); update_option( 'hellfish_custom_plugin_version', '2' ); echo 'Deployment complete.'; } } // deploy any pages set up in the deploy_changes function function deploy_pages( $pages ) { foreach ( $pages as $page ) { $new_page = array( 'post_type' => 'page', 'post_title' => $page['title'], 'post_content' => $page['content'], ); wp_insert_post( $new_page ); } }

Bunu özel bir eklentinin parçası olarak oluşturmak, gerekebilecek tüm veritabanı güncellemelerini her eklenti sürümünde güncellediğiniz eklenti sürüm numarasına bağlayabileceğiniz anlamına gelir.

Ne Yapıyoruz

Esasen, biz burada Delicious Brains'de benzer bir yaklaşım kullanıyoruz, ancak buna biraz daha kontrol ve süreç ekledim. Laravel'in veritabanı geçişlerinden ve tohumlama sisteminden esinlenerek, geliştirme sırasında tablo ve veri değişiklikleri yapmak için komut dosyaları yazmama yardımcı olan bir geçiş kitaplığı oluşturdum. Burada JJJ'nin çalışmasıyla ve mevcut wp-table-migrations paketiyle oldukça fazla örtüşme var, ancak sitelerimizde kullanılabilecek özel bir şey istedim; lezzetlibrains.com ve spinupwp.com.

Bu süreç:

1. Bir tablo eklemek/düzenlemek/silmek için kodun yanı sıra veritabanından veri ekleme/güncelleme/silme kodunu içeren yeni bir geçiş sınıfı dosyası oluşturun
2. Bir kez çalıştırılan her taşıma dosyası, tekrar çalıştırılmamasını sağlamak için bir migrations tablosuna kaydedilir.
3. Bu dosya, bir özellik dalının parçası olarak Git'e kaydedilebilir
4. Canlı site için dağıtım işlemi, özel bir wp dbi migrate WP-CLI komutu aracılığıyla veritabanı geçişlerini çalıştırmak için dosyalar sunucuya kopyalandıktan sonra bir derleme adımı içerir.

Bu, yeni bir özellik veya hata düzeltmesi için herhangi bir kod değişikliğinin parçası olarak tabloları değiştirmek ve verileri değiştirmek için PHP kodu yazmama izin veriyor. Bu değişiklikler Git'te depolanır ve gözden geçirilen, birleştirilen ve sonunda dağıtılan GitHub çekme isteğinin bir parçasını oluşturur. Bu işlemi kullanmak, şunun gibi bir kod kullanarak şema değişiklikleri yapabilmem için WordPress kodunun veritabanını nasıl değiştirdiğini bilmem gerektiği anlamına gelir:

 <?php namespace DeliciousBrains\WPMigrations\Database\Migrations; use DeliciousBrains\WPMigrations\Database\AbstractMigration; class ComposerStatsTable extends AbstractMigration { public function run() { global $wpdb; $sql = " CREATE TABLE " . $wpdb->prefix . "woocommerce_software_composer_download_statistics ( id bigint(20) NOT NULL auto_increment, composer_key varchar(50) NOT NULL, package varchar(50) NOT NULL, version varchar(16) NOT NULL, original_package varchar(50) NOT NULL, download_time datetime DEFAULT CURRENT_TIMESTAMP NOT NULL, PRIMARY KEY (id) ) {$this->get_collation()}; "; dbDelta( $sql ); } }

Bunun gibi verilerde değişiklik yapmanın yanı sıra:

 <?php namespace DeliciousBrains\WPMigrations\Database\Migrations; use DeliciousBrains\WPMigrations\Database\AbstractMigration; class AddWpSesLandingPage extends AbstractMigration { public function run() { $page_id = wp_insert_post( array( 'post_title' => 'WP SES is Now WP Offload SES Lite', 'post_status' => 'publish', 'post_name' => 'wp-ses-now-wp-offload-ses-lite', 'post_type' => 'page', 'post_parent' => 49760, ) ); update_post_meta( $page_id, '_wp_page_template', 'page-wp-ses-landing.php' ); update_post_meta( $page_id, '_yoast_wpseo_metadesc', 'Looking for WP-SES.com? WP SES is now WP Offload SES Lite. See what improvements we\'ve made to the free version and what you can get when you upgrade.' ); } }

Herhangi bir veritabanı değişikliğini manuel olarak kodlamak için WordPress PHP kodunu kullanıyorum, bu komut satırında wp dbi migrate kullanılarak test edilebilir. Geçiş sınıfının rollback yöntemine herhangi bir geri alma kodu eklersem, son geçişi de geri alabilirim. Bunun gibi komut dosyası oluşturma ile veritabanında yaptığım değişikliklerin kontrolü bende, ancak bazen, Mergebot ile mümkün olacağını umduğumuz gibi, değişikliklerimi yapmak ve bir birleştirme gerçekleştirmek için WordPress yönetici kullanıcı arayüzünü kullanabilmeyi diliyorum.

Piyasadaki diğer birleştirme çözümleri ne olacak?

Mansiyon: VersionPress

Mergebot üzerinde çalışmaya başladığımızda, WordPress dosyalarındaki ve VersionPress adlı veritabanındaki değişiklikleri izlemek için Git'i kullanan benzer bir eklenti vardı.

Ne yazık ki, Haziran 2020'de geliştirme ekibi VersionPress'in geliştirilmesinin sona erdiğini duyurdu.

WPBirleştirme

Mergebot'u kapatmaya karar vermemizden kısa bir süre sonra, yeni bir birleştirme çözümü beta sürümüne girdi. WPMerge, Mergebot'un birçok yönden nasıl çalıştığına benzer. Geliştirme veritabanınızın canlı ile senkronize edildiğinden emin olun, kaydetmeye başlayın ve ardından geliştirme sitenizde daha sonra hayata geçirilmek üzere değişiklikler yapın.

Lansmanından bir süre sonra WPMerge, WordPress ve WooCommerce barındırma müşterilerine daha fazla değer katmak için Nexcess ile ortaklık kurdu.

WPMerge'e hızlı bir yol testi yaptım ve iyi çalıştı. Uygulamasında Mergebot'tan bazı farklılıklar fark ettim. Yürütülen tüm sorguları WordPress 'sorgu' filtresini kullanarak kaydetmek yerine kaydetmek için geliştirme sitesinin veritabanındaki veritabanı tetikleyicilerini kullanır.

Kısa testlerimde aşağıdakileri yaptım:

• Geliştirmeye yeni bir gönderi eklemek ve canlı siteye dağıtıldığında, dağıtılan gönderi kimliğiyle doğru sonrası meta ilişkisine sahip olduğundan emin olmak
• Gönderi içeriğine eklenen galeri kısa kodundaki medya gönderi kimliklerinin dağıtım sırasında doğru bir şekilde değiştirilip değiştirilmediğini görmek için yeni yüklenen resimlerden oluşan bir galeriyle yeni bir gönderi ekleme – bunlar 🎉
• Geliştirme sitemde mevcut bir gönderi başlığını düzenlemek ve başlığın da değiştiği yerde yaşamak için dağıtmak – geliştirme düzenlemesi sorulmadan kullanıldı 😬

Ne yazık ki, WPMerge çakışma çözümünü de işlemez:

Şimdilik, tıpkı Git gibi, geliştirme değişiklikleri önceliklidir. Hangi değişiklikleri tutacağınızı seçebileceğiniz bir çakışma çözme modülü geliştirmek istiyoruz.

Örneğin, geliştirme ortamınızda 'Hakkında' olan bir sayfa başlığını 'Hakkımızda' olarak değiştirdiğinizi, ancak değişiklikleri dağıtmadan önce müşterinizin başlığı da 'Hakkında'dan 'Takım' gibi başka bir şeye değiştirdiğini varsayalım. Bu durumda, WPMerge istemcinin değişikliğini yok sayar ve değişikliğinizi yeni değer olarak kullanır.

Eski bir rakibin geliştiricisi olarak bile, WPMerge'den ve kutudan çıktığı haliyle nasıl çalıştığından çok etkilendim. UI/UX'in geliştiricilerin iş akışını daha iyi kullanmasını ve anlamasını kolaylaştırmak için biraz cila ile yapabileceğini düşünüyorum. Mevcut geliştirme değişikliklerimi canlı ortama uygulamak için doğru eylemin ne olduğu konusunda kafam çok karıştı. Ayrıca, yaptığım değişiklikler için gereksiz olan kaç sorgunun kaydedildiğini ve dağıtıldığını da fark ettim. Yukarıda anlattığım basit test turundan sonra, eklenti 400'den fazla sorguyu kaydediyordu! Bu, çok sayıda eklentinin kurulu olduğu büyük ölçekli sitelerde bunu kullanma konusunda beni gerginleştirdi.

WPMerge hala aktif geliştirme aşamasında olsa da, temel teklifin yanı sıra herhangi bir yeni özellik ekleyecek gibi görünmüyor. En son değişiklik günlüğü girdileri yalnızca birkaç hata düzeltmesini ve PHP 8 desteği için bir güncellemeyi yansıtır.

Toplama

WordPress'te veritabanı birleştirme için sihirli bir kurşun çözümü olduğuna hala inanmıyorum. Bu, geliştiricilerin, kendilerini senkronize olmayan yerel ve canlı veritabanları ile bir duruma sokmamaları için farkında olmaları gereken bir sorundur. Değişiklik yapmadan önce hazırlıklı olun, ne yaptığınızı kaydedin ve daha sonra dağıtım zamanında bu değişiklikleri oynatın. Benim için bu süreci olabildiğince sistematik ve otomatik tutmak, geliştirme iş akışımı iyileştirmenin anahtarıdır. Ayrıca, her veri değişikliği sürüm kontrolüne bağlı olduğundan, özellikle ekip ortamında insan hatasını azaltır.

Geliştirme veritabanı değişikliklerini canlı bir siteye uygulamak için tercih ettiğiniz yöntem nedir? Veritabanı birleştirme işlemini gerçekleştirmek için memnun olduğunuz bir araç buldunuz mu? Yorumlarda bize bildirin.