Hazırlanmış bir ortamda bir modül nasıl doğru şekilde kaldırılır?

Bazı modüllerin kurulum rutinleri vardır. Genellikle bu modül için veritabanı tablolarını, değişken tablosundaki değişkenleri ve modül tarafından tanıtılan yerel ayarları kaldırır. Bu rutinler .installbu modülün içinde yaşar .

Bu nedenle, bu modül mevcut olmadan çalıştırılamazlar. İşte mevcut adımlarımız. Sorum şu: bu daha basit ve daha etkili bir şekilde yapılabilir mi? Foo_bar modülünü kaldırdığımı varsayalım.

1. RCS'de yeni bir sürüm hazırlayın, burada:
   • Foo_bar öğesinin üstündeki veya üzerinde oluşturulan tüm css ve tema geçersiz kılma işlemleri kaldırılır.
   • Foo_bar'a bağlı modüller için tüm css ve tema geçersiz kılma işlemleri kaldırılır.
2. Bu sürümü kabul etmek için itin. Kurulumun (admin / modüllerden) üretim veritabanının son bir kopyasıyla testini yapın.
3. Her şey yolunda giderse, yeni kod tabanını üretime dağıtın ve foo_bar ve onun bağımlılıklarını oradan kaldırın. Bu işlem, çeşitli modüllerde kaldırmayı başlatır ve veritabanını temizler.
4. RCS'de (git), kodun gerçekten kaldırıldığı yeni bir sürüm hazırlayın.
5. Bunu yanlışlıkla buna bağlı bir şey olup olmadığını test ettiğimiz yere kabul etmek için dağıtın (bazı çirkin modüller veya tema işlevleri doğrudan diğer modüllerden dosyalar içerir. En önemlisi CSS, JS veya görüntü dosyaları).
6. Kabul edilirse, üretime yeni sürüm dağıtın. üretim artık temiz bir veritabanı ve temiz bir kod tabanına sahip .

Nasıl çözüleceğini göremediğim sorun, bunun her zaman iki sürüm gerektirmesidir. Drupal'da bir sürüm sitenin çevrimdışı olmasını gerektirdiğinden, bu sadece bir modülü kaldırmak için iki kez kesinti anlamına gelir. Ayrıca, profesyonel barındırma ortamlarında çok pahalı, zaman alıcı veya sinir bozucu olabilecek iki sürüm prosedürü gerektirir.

İlk yinelemede modülü kod tabanından kaldırırsak, kaldırma kancalarını çalıştıramazız ve veritabanında çok sayıda tüy bırakmaz; sadece birkaç tablo değil, çoğunlukla değişkenler ve yerel ayarlar. Modülü kod tabanından kaldırmazsak, kod tabanı eski, kullanılmayan kodla büyüyecektir; bu, performans yükü vermez, ancak kodun bakımını zorlaştırır.

Nasıl anlaştın onunla birlikte?

[değiştir: dağıtımın genellikle zor bir prosedür olduğu hakkında not eklendi]

Veritabanınızı ve kodunuzu senkronize tutma konusunda çok dikkatli olun; Sorunuzda belirttiğiniz gibi, kaldırılacak modüllerin kaldırma kancaları canlı veritabanında çalışana kadar kod tabanında kalmaları gerekir. Bu sadece bir git çekme iş akışının çözemeyeceği bir Drupal sınırlamasıdır.

İşleminizi ayarlamaya çalışmak yerine, güncellemelerinizi işlemek için gereken kapalı kalma süresini azaltmanın yollarını aramanızı öneririm. Bu sorunu çözmek için bir ying / yang multisite evreleme ortamı kurmanızı tavsiye ederim . nb Önceki linkte yer alan komut dosyalarını kullanmadım; dağıtım sırasında canlı ve sahne alanlarınızı değiştirebileceğiniz fikrini izleyerek işleri farklı şekilde ayarlamak isteyebilirsiniz .

Aşağıdaki düzenlemelerle sorunuzda belirttiğiniz prosedürün aynısını izlemeye devam edin:

a. Dev'den aşamaya (yang) her zamanki gibi senkronize edin. Kaldırılacak modüllerin kaldırılmasını takiben kod kaldırma, vb. Yaparak test edin. Git iş akışı notları: bir etiket oluşturun veya kodunuzun farklı durumlarının karmasını not edin: kaldırmadan önceki tüm modüller, kod modülleri kaldırıldı, geçersiz kılmalar & c. gerektiği gibi kaldırıldı. Belki de sadece iki referans gereklidir.

b. Test tamamlandığında ve kabul edildiğinde, sahne (yang) kodunu canlı duruma (ying) geri yükleyin.

c. Herhangi bir kullanıcının sistemdeki içeriği değiştirme yeteneğini devre dışı bırakarak canlı (ying) siteyi güncellemeye hazırlayın. İzin tablosunda bir sql güncellemesi genellikle burada yapılır. Bu noktada, kullanıcılar hala canlı sitedeki içeriği okuyabilecek, ancak içeriği güncellemeye çalışırlarsa izin reddedildi hatası alırlar. (Serinseniz, işlevin geçici olarak kullanılamadığına dair uygun bir bildirim yazdırmak için izin verilmediği işleyiciyi değiştirebilirsiniz).

d. Şimdi canlı (ying) veritabanını, izinler tablosunu güncelleştirmeden hariç tutarak sahne (yang) veritabanına geri itin.

e. Adım a'yı tekrarlayın. tekrar. Hashtag'leriniz elinizin altındaysa, kaldırılacak modüllerin bulunduğu duruma geri yüklemeniz, veritabanındaki kaldırma kancalarını çalıştırmanız ve ardından 1. adımdaki öğelerinizin birleştirildiği kodun durumuna geri dönmeniz kolay olmalıdır. geri.

f. Artık ying ve yang'ı değiştirmeye hazırsınız. Bunu Apache yapılandırma yönergelerinizi ayarlayarak yapın. Bunu yaparsanız /etc/init.d/apache restart, bazı bağlantıların kesilebileceğini, ancak /etc/init.d/apache reloadtemiz bir değişime izin vereceğini unutmayın.

g. Canlı şimdi 'yang'; burada izin tablosu değiştirilmez, böylece kullanıcılar içerik oluşturabilir. E adımlarını otomatik hale getirirseniz. ve f., mevcut olmayan zaman çok düşük olmalıdır.

h. Canlı (yang) 'ı hem kod hem de veritabanı olarak sahneye (ying) veya gerektiğinde dev'den itin. Artık bir sonraki yinelemeniz için temiz bir ortam hazır.