F eatures C onfiguration M anagement, aka FCM ülkesine hoş geldiniz ! Konfigürasyon Yönetimi ile ilgili değil, sadece Özellikler ile ilgili değildir (Drupal sürüm 8'de tanıtıldığı gibi). Bunun yerine, özel bir durumdur S oftware C TARAFINDAN YAPILANDIRILABİLİR E anagement , namı SCM . Çoğunlukla Unsurlar bir kod üreticisi olarak düşünülebilirken, üretilen kodun birden fazla ortamdan geçirilmesi gerekir. Daha fazla bilgi için okumaya devam edin.
1 - Özellikleri kullanmanın artıları ve eksileri
Özellikleri kullanmanın avantajları
- Bir Drupal geliştirme sitesine uygulanan değişikliklerin bir veya daha fazla hedef Drupal (üretim öncesi) üretim sitesine (manuel dağıtım yerine) dağıtımını otomatikleştirin.
- Drupal geliştiricileri / site üreticileri arasında devam eden Drupal gelişiminin paylaşılmasını (gönderilmesini) kolaylaştırır (örneğin, bir görünüm uzmanı tarafından oluşturulan görünümleri başka bir geliştirme sitesinde çalışan bir Drupal Themer tarafından bu temayı teması için kullanılabilir hale getirmek).
- Özellikler (geliştirme sitesinde) tarafından üretilen kodun bir kopyasını seçilen hedef (ön) üretim yerlerine göndermek için hem GIT hem de Drush ile mükemmel entegrasyon .
Özellikleri kullanmanın dezavantajları
- Özellik Çatışmalarından Kaçınmak ve / veya Özellik Bağımlılıklarını yönetmek zor olabilir!
- Mevcut (üretim) bir sitede Özellikler kullanmaya başlamak kolay değildir .
- Özellikler modülünün yüklenmesi / etkinleştirilmesi kolaydır (sadece bir modül), ancak Özellikleri doğru kullanmayı öğrenmek büyük bir sorundur.
2 - Özellik paketleme teknikleri
Özellikler'i kullanmak , bir özelliğin içeriğini nasıl paketleyeceğinizi (oluşturacağınız) kendi hayal gücünüze bağlıdır. İşte bunun için kullanılabilecek bazı teknikler.
Tek bir süper özellik
Bu oldukça basit bir paketleme tekniğidir: her şey tek bir özellikte bir araya getirilmiştir (bazıları "Tanrı" özelliği olarak adlandırılır ...). Kolay, oldukça ileri, vb. Gibi görünüyor. Ancak bu teknik aynı zamanda (aşağıda açıklandığı gibi) aşağı yukarı hemen "çatışmalara" yol açar ...
Bunun için iyi bir kullanıcı tabanı, "Drupal dağıtımı" oluştururken, tüm kullanıcılarının aynı modülleri, yapılandırmayı, vb. Kullandıkları varsayılır gibi görünmektedir. "özellikler" ...), bu özellikleri aşağıda açıklandığı gibi birden çok özelliğe ayırmak daha uygun görünmektedir.
Web sitesi işlevselliğine dayalı
Bu paketleme tekniği, bir web sitesinin her işlevselliği için ayrı bir özellik oluşturur, örneğin:
- Özellik A = bir " * Galeri " uygulayın.
- Özellik B = bir " * Blog " uygulayın.
- Özellik C = " * Etkinlik Takvimi " uygulayın.
Drupal yönetici bölümlerini temel alır
Bu paketleme tekniği, siteyi oluşturmak için kullanılan bir Drupal web sitesinin (ana) yönetici bölümlerinin her biri için ayrı özellikler oluşturur, örneğin:
- Gerekli tüm modüller A özelliğinde bulunur,
- Tüm temel alan tanımları B özelliğinde,
- Tüm içerik türleri C özelliğinde bulunur,
- Tüm izinler D özelliğinde bulunur,
- Tüm roller E özelliğinde bulunur,
- Tüm değişkenler F özelliğinde bulunur,
- Tüm (özel) Görünümler G özelliğinde bulunur,
- Tüm (özel) Kurallar H özelliğinde bulunur,
- Vb.
Yukarıdaki liste neredeyse sınırsızdır: sonunda her Drupal yönetici menüsü seçeneği için 1 özellik olarak düşünebilirsiniz ... o kadar ileri gitmek istiyorsanız.
IMO aynı zamanda paket özelliklerine en çok önerilen yaklaşımdır.
3 - Özelliklerde ve / veya GIT'te çatışma olasılığını azaltmak
Alanları tekrar kullanma
Alanların birden fazla içerik türü arasında yeniden kullanılmasından kaynaklanıyor. Örneğin, A içerik türünde, makine adı field_somefieldB olan ve aynı makine adıyla içerik türü B'de alan olarak kullanılan, field_somefieldancak başka bir alan türü ve / veya farklı başka bir alan ayarı (ayarları) olan bir alanınız vardır.
Alanları içerik türleri arasında yeniden kullanmadığınızda, bu sayıda çalışmaktan kaçınabilirsiniz. " Drupal için Görelilik Modeli " ile ilgili makalelerin bir parçası olan Sargı Bilgi Mimarisi ve Belgeleri tablosunda gösterildiği gibi, içerik türlerinizin ve alanlarınızın makine adı için ilginç bir adlandırma kuralına bakın . Bununla ilgili daha fazla ayrıntı için, " İçeriği (türleri) veritabanı merkezli bir bakış açısından nasıl modelleyebilirim? "
Kimin neyin üzerinde çalıştığına bağlı olarak özellikleri böl
Birden çok kişi tek bir sitede çalışıyorsa, kimin üzerinde çalıştığına bağlı olarak özellikler düzenleyerek (= ayrı ayrı) düzenleyerek çakışma miktarı azaltılabilir. Bunun bir örneği bu örnekteki gibi olabilir:
- Görünümler A özelliğine girer,
- Kurallar B özelliğine girer,
- Grafikler C özelliğine girer,
- Hakkında bir şey Theming , özellik D'de gider
4 - Önerilen Drupal ortamları
Yukarıdaki her şey, Özelliklerin kullanımını bir şekilde kolaylaştırmaya yardımcı olmalıdır . Ancak, işlerin beklendiği gibi çalışmasını sağlamak için (tasarlanmış), temel olarak şu nedenlerle uygun ortamlara (mantıksal olarak ilgili Drupal web siteleri) sahip olmanız gerekir:
- birden çok özellik tarafından sağlanan birleştirme işlevi.
- çatışmaları tahmin etmek ve çözmek.
- Çakışma olmadığı onaylanan tüm birleştirilmiş özelliklerin son kullanıcı testleri.
İdeal dünyada, bu mantıksal olarak ilgili Drupal web siteleri şu şekilde yapılandırılmalı ve kullanılmalıdır:
- Kişisel Geliştirici Sitesi - her web sitesi geliştiricisinin ayrı bir geliştirme sitesi vardır. Geliştirmenin bir kısmı başka biriyle paylaşılmaya hazır olduğunda, hazırlama ortamına gönderilen uygun bir özellik oluşturulur.
- Sandbox Site - Bu, tek bir özelliğin bütünlüğünü test etmek için kullanılan sadece Drupal çekirdeği içeren bir Drupal ortamıdır. Bir özellik yanlışlıkla beklenmedik bağımlılıklara sahipse (örneğin, özellik Sandbox'ta etkin olmayan bazı modül bağımlıdır), o zaman bu bağımlılık netleşecektir.
- Staging Site - burada bir veya daha fazla özelliğin (geliştirici sitesinde oluşturulmuş) teslim edildiği yer. Bazı üretim sorunları için sadece bir düzeltme olabilir veya web sitesinin yeni bir sürümü için tüm geliştirmelerin birleştirildiği yer olabilir. Birden fazla özellik arasında herhangi bir çelişki varsa, bu ilk ortaya çıkacakları ortamdır ... ve bir şekilde çözülmesi gerekir.
- KG Sitesi - Evreleme ortamı kararlı olarak kabul edildikten sonra, ilgili özelliklere devam etme ve bunları KG testi, kabul testi, hacim testi vb. ek değişikliklere (varsa) izin verirken son derece dikkatli olunmalıdır. Çünkü bu tür değişiklikler bu ortamda daha önce tamamlanmış olan tüm test çabalarını geçersiz kılabilir.
- Gölge Üretim Sitesi - Gerçek üretimde aktivasyonu hazırlamak için, önce ilgili özellikleri gerçek üretim ortamınızın bir kopyası (gölge) olarak kabul edilen bir ortama daha da tanıtmak isteyebilirsiniz. Geçiş işlemi sırasında bu noktada hala bir şey kırılırsa, o zaman önceki adımlarınızdan bazılarını geri almak için kırmızı bir bayraktır. Düzeltin ve ilgili tüm taraflar değişiklikleri onaylayana kadar tekrar deneyin.
- Üretim Tesisleri - Önceki tüm adımları tamamladıysanız, bu adım kendi kendini açıklamalı ve oldukça kolay olmalıdır. İhtiyaçlarınıza bağlı olarak, bu tek bir site veya Drupal'ın Çoklu Sitelerine eşdeğer bir şey olabilirken, ilgili tüm siteler tüm özelliklerin aynı sürümlerini çalıştırıyor olabilir.
- Temel Site - Deneyimlerime göre, bu tür bir sitenin kullanıldığı çok fazla (varsa) Drupal uygulaması yoktur (ayrıca). Bu sadece Üretim Sahalarının bir kopyasıdır, ancak üretim yerlerinin neye benzediğini doğrulamak veya kullanıcı eğitimi vb. Yapmak için kullanılabilen Drupal geliştiricileri, test uzmanları vb. döngüsü başlatıldığında, etkilenecek bir sitenin bileşenleri (değiştirilmesi gerekir), bu Temel Siteyi giriş olarak, bir Kişisel Gelişim Sitesi olarak hedeflenerek "bir şekilde kopyalanmalıdır" .
Açıkçası, Drupal sitesi türlerinin yukarıdaki envanteri ideal dünya gibidir. Geliştirme ekibinizin büyüklüğüne ve / veya bunları oluşturmak ve bakımını yapmak için mevcut bütçelere bağlı olarak, bunların tümü kullanılamaz (veya uygun fiyatlı). Bu envanter, çoğunlukla tüm büyük / küresel şirketlerde (bankalar, havayolları vb.) Kullanılan SCM alanındaki en iyi uygulamalardan sonra modellenmiştir.
5 - İlgili modüller
Güçlü kol
Strongarm modülü modülü sahiptir ile (değişkenlerde ayarlarını depolamak modüllerin) değişkenleri ihracat için izin verir.
Düğüm Dışa Aktarma
Düğüm ihracat modülü ihracat düğümlerine yapmasını sağlar ve daha sonra başka Drupal kurulum içe.
Rol Dışa Aktarma
Rol İhracat modülü rolleri machine_names olmasını sağlar ve machine_name dışına göre benzersiz bir rol kimliği (kurtulmak) üretir. Roller Özellikler ile dışa aktarılabilir ve diğer sitelere aktarılırsa tamamen aynı şekilde kaldırılabilir .
Özellikler Banish
Defetmek Özellikleri modül tamamen kullanıcı arayüzü ve özellikleri ihracatını özellikleri tek tek özellikler bileşenleri hariç sağlar. İşte proje sayfasından bir alıntı:
Bu modül, ASLA dışa aktarılmadığından emin olmak istediğiniz özellikler bileşenleri olduğunda kullanışlıdır. Site oluşturma veya dağıtım için özellikler kullanıyorsanız, muhtemelen yanlışlıkla cron_last veya update_last_check gibi zaman damgası değişkenlerini dışa aktaran biriyle karşılaştınız. Ayrıca, dışa aktarmak istediğiniz site izinlerinin geri kalanına yetişmemek için geliştirici modülleri için izinleri yasaklamak isteyebilirsiniz. Yok olan öğeler özellik modülünüzde VEYA DİĞER ÖZELLİKLER MODÜLÜNDE görünmez, bu yüzden dikkatli kullanın. Asla dışa aktarılmaması gereken özelliklerin merkezi bir listesi için bkz. Https://www.drupal.org/node/2400531
FASULYE
Fasulye modülü bloklar ihraç yapar. İşte proje sayfasından bir alıntı:
Bir Bean'i yeni türler sağlama yöntemi olarak düşünün (düğümle karşılaştırıldığında bu bir içerik türü olacaktır), daha sonra istediğiniz sayıda blok oluşturmak için bir içerik ekleme arabirimi sağlar (aşağıdaki ekran görüntüsüne bakın). Fasulye içeriği daha sonra diğer bloklar gibi sitenin etrafına yerleştirilebilir.
Bu modül ayrıca UUID ve UUID Özellikleri Entegrasyon modülleriyle birlikte harika çalışır . Bu modül sadece D7'den itibaren başladı, ancak zaten Drupal 8 çekirdeğine dahil edildi. Video öğretici Drupal Bean modülü öğretici - Bean Admin UI kullanarak bu modülün gücünü ve onunla yapabileceğiniz şeyleri gerçekten anlamak için harika bir giriş sağlar (sadece site oluşturma teknikleri kullanarak, özel kodlama dahil değildir).
Yetişme ortamı
Habitat bir modül en mantıklı Özellikleri tabanlı iş akışı. İşte proje sayfasından bir alıntı:
Çok ortamlı bir kurulumda (örn. Prod, test, dev, local) belirli ortamlarda her zaman etkinleştirilmesini veya devre dışı bırakılmasını istediğiniz bazı modüller vardır. Bir veritabanını her eşitlediğinizde, aynı modülleri yeniden etkinleştirmeniz / devre dışı bırakmanız gerekir. Daha da kötüsü, tembelleşir ve geliştirme modüllerini üretimde etkin tutarsınız.
Habitat, her ortamdaki (habitat) belirli modülleri etkinleştirmek veya devre dışı bırakmak için ayarlar sağlar. Sadece $ conf ['habitat'] = 'local' ile bir değişken ayarlayın; settings.php dosyanızda (orada kullanılacak gerçek değişken geçerli iş akışınız için yapılandırılabilir). Devre dışı bırakma / etkinleştirme modülleri hook_init üzerinde yapılır.
6 - Önerilen kaynaklar:
7 - Özelliklerin kullanılmasının olası alternatifleri
Özellikler'i kullanamıyorsanız veya (henüz) istemiyorsanız, aşağıdaki yaklaşımların / modüllerin ne tür bir alternatif sunabileceğini kontrol etmek isteyebilirsiniz.
Manuel Dışa Aktarma / İçe Aktarma
Bunlar, Kurallar , Görünümler , vb. Gibi modüller için yönetici kullanıcı arayüzü aracılığıyla yaygın olarak bilinen tesislerdir (kelime özelliklerinden kaçınmak için ...) (eksik liste!).
Paket kopyası
Bazı insanlar Bundle kopya modülünü olası bir alternatif olarak görür. Aşağıdakiler için ihracat / ithalat desteği vardır:
- Düğüm tipleri.
- Taksonomi.
- Kullanıcı.
- Alan API alanları.
- Alan grupları.