Bekerja pada sebuah proyek, menggunakan banyak Fitur , kadang-kadang ada 3 devs untuk aplikasi ini.

Kami telah mencoba beberapa pendekatan, tetapi ketika kami menggabungkan cabang-cabang git kami, sepertinya kami sering 'saling menulis' perubahan fitur masing-masing. Konflik berlimpah, melanggar modul fitur membuatnya menyakitkan untuk digunakan, tampaknya.

Fitur sebenarnya penghemat waktu yang luar biasa untuk konfigurasi untuk satu proyek, dan saya cukup yakin ada cara untuk mengatasi ini.

Apakah ada alur kerja atau prosedur yang mengurangi risiko konflik dan menimpa?

Semua petunjuk tentang fitur dipersilahkan.

Selamat datang di tanah F eatures C onfiguration M anajemen, alias FCM ! Ini bukan hanya tentang Fitur , dan bukan tentang Manajemen Konfigurasi (seperti yang diperkenalkan dalam Drupal versi 8). Sebaliknya, itu adalah kasus khusus dari S oftware C onfiguration M anajemen , alias SCM . Sebagian besar karena Fitur dapat dianggap sebagai pembuat kode, sedangkan kode yang dihasilkan perlu dimigrasi melalui beberapa lingkungan. Baca terus untuk detail lebih lanjut.

1 - Pro dan kontra menggunakan Fitur

Keuntungan menggunakan Fitur

• Mengotomatiskan penyebaran perubahan yang diterapkan ke situs pengembangan Drupal ke satu atau lebih target situs Drupal (pra-) produksi (bukan penyebaran manual).
• Memfasilitasi berbagi (pengiriman) pengembangan Drupal yang sedang berlangsung antara pengembang Drupal / pembangun situs (misalnya untuk membuat beberapa View (s) yang dibuat oleh ahli pandangan yang tersedia untuk Drupal Themer yang bekerja di situs pengembangan lain untuk tema yang melihat tampilan).
• Integrasi hebat dengan GIT dan Drush untuk mengirimkan salinan kode yang dihasilkan oleh Fitur (di situs pengembangan) ke target (pra-) lokasi produksi yang dipilih.

Kerugian menggunakan Fitur

• Menghindari Konflik Fitur dan / atau mengelola Dependensi Fitur dapat menjadi tantangan!
• Tidak mudah untuk mulai menggunakan Fitur di situs (produksi) yang ada.
• Instal / aktifkan modul Fitur itu mudah (hanya modul), tetapi belajar menggunakan Fitur dengan benar adalah tantangan utama.

2 - Teknik untuk pengemasan fitur

Menggunakan Fitur terserah pada imajinasi Anda sendiri bagaimana mengemas (menyusun) konten fitur. Berikut beberapa teknik yang bisa digunakan untuk itu.

Fitur super tunggal

Ini adalah teknik pengemasan yang cukup sederhana: semuanya dikemas bersama dalam satu fitur (beberapa menyebutnya fitur "Dewa" ...). Tampak mudah, cukup maju, dll. Tetapi teknik ini juga mengarah pada "konflik" (seperti yang dijelaskan di bawah) segera atau kurang ...

Sebuah usecase yang baik untuk ini tampaknya ketika membuat "distribusi Drupal", di mana semua pengguna diasumsikan menggunakan set modul yang sama, konfigurasi, dll. Namun, jika distribusi tersebut terdiri dari beberapa fungsi situs web (tidak menggunakan kata "fitur" ...), tampaknya lebih tepat untuk memecah fitur-fitur tersebut dalam banyak fitur, seperti yang dijelaskan di bawah ini.

Berdasarkan fungsionalitas situs web

Teknik pengemasan ini menciptakan fitur terpisah untuk setiap fungsi situs web, seperti:

• Fitur A = mengimplementasikan " * Galeri ".
• Fitur B = implementg a " * Blog ".
• Fitur C = menerapkan " * Kalender Acara ".

Berdasarkan bagian admin Drupal

Teknik pengemasan ini membuat fitur terpisah untuk setiap bagian admin (utama) dari situs web Drupal yang digunakan untuk membuat situs, seperti:

• Semua modul yang diperlukan terkandung dalam fitur A,
• Semua definisi bidang dasar terkandung dalam fitur B,
• Semua jenis konten terkandung dalam fitur C,
• Semua izin terkandung dalam fitur D,
• Semua peran terkandung dalam fitur E,
• Semua variabel terkandung dalam fitur F,
• Semua Tampilan (khusus) terdapat dalam fitur G,
• Semua (kustom) Aturan terkandung dalam fitur H,
• Dll

Daftar di atas sebenarnya tidak terbatas: pada akhirnya Anda bahkan dapat menganggapnya sebagai 1 fitur untuk setiap opsi menu admin Drupal ... jika Anda ingin melangkah sejauh itu.

IMO juga merupakan pendekatan yang paling direkomendasikan untuk fitur paket.

3 - Mengurangi kemungkinan konflik dalam Fitur dan / atau GIT

Jangan menggunakan kembali bidang

Beberapa konflik tampaknya disebabkan oleh penggunaan kembali bidang di antara beberapa jenis konten. Misalnya dalam tipe konten A Anda memiliki bidang dengan nama mesin field_somefield, yang juga digunakan sebagai bidang dalam tipe konten B dengan nama mesin yang sama field_somefieldtetapi yang sebagai jenis bidang lain dan / atau beberapa pengaturan bidang lain yang berbeda.

Dengan tidak menggunakan kembali bidang di antara jenis konten, Anda menghindari berjalan dalam masalah ini. Lihatlah konvensi penamaan yang menarik untuk nama mesin dari jenis dan bidang konten Anda seperti yang ditunjukkan dalam tabel Wrapping Information Architecture and Documentation , yang merupakan bagian dari artikel tentang " Model Relativitas untuk Drupal ". Untuk detail lebih lanjut, lihat jawaban saya untuk " Bagaimana cara saya memodelkan konten (jenis) dari sudut pandang basis data-sentris? ".

Membagi fitur tergantung pada siapa yang bekerja pada apa

Jika beberapa orang bekerja di satu situs, jumlah konflik dapat dikurangi dengan mengatur fitur (= membuat terpisah) berdasarkan siapa yang mengerjakan apa. Sebuah ilustrasi tentang ini bisa seperti dalam contoh ini:

• Tampilan masuk dalam fitur A,
• Aturan berlaku di fitur B,
• Grafik masuk dalam fitur C,
• Apa-apa tentang Theming masuk fitur D,

4 - Lingkungan Drupal yang disarankan

Segala sesuatu di atas seharusnya membantu memfasilitasi penggunaan Fitur . Namun, untuk memastikan semuanya berjalan sesuai harapan (dirancang), Anda juga perlu memiliki serangkaian lingkungan yang sesuai (situs web Drupal yang terkait secara logis) karena alasan-alasan berikut:

• menggabungkan fungsionalitas yang disediakan oleh banyak fitur.
• memprediksi dan menyelesaikan konflik.
• pengujian pengguna akhir atas semua fitur yang digabung yang disertifikasi tidak memiliki konflik.

Di dunia ideal, situs web Drupal yang terkait secara logis ini harus dikonfigurasi, dan digunakan, seperti:

1. Situs Dev Pribadi - setiap pengembang situs web memiliki situs pengembang terpisah. Ketika beberapa bagian dari pengembangan siap untuk dibagikan dengan orang lain, fitur yang sesuai dibuat, yang dikirimkan ke lingkungan pementasan.
2. Situs Sandbox - ini adalah lingkungan Drupal yang hanya berisi inti Drupal, yang digunakan untuk menguji unit kelengkapan fitur tunggal. Jika suatu fitur, secara tidak sengaja, memiliki beberapa dependensi yang tidak terduga (mis. Beberapa modul tergantung pada fitur, yang tidak diaktifkan di Sandbox), maka disinilah ketergantungan akan menjadi jelas.
3. Staging Site - di sinilah satu atau lebih fitur (dibuat di situs dev) dikirimkan ke. Ini bisa berupa perbaikan terbaru untuk beberapa masalah produksi, atau bisa juga di mana semua pengembangan untuk rilis baru situs web dikonsolidasikan. Jika ada konflik antara beberapa fitur yang ada, maka ini adalah lingkungan di mana mereka akan muncul pertama kali ... dan perlu dipecahkan.
4. Situs QA - setelah lingkungan Pementasan dianggap stabil, sekarang saatnya untuk beralih dengan fitur-fitur yang relevan dan membuatnya tersedia di beberapa tingkat yang lebih tinggi di mana mereka dapat digunakan untuk pengujian QA, pengujian penerimaan, pengujian volume, dll. Pada level ini Anda harus sangat berhati-hati dalam mengizinkan perubahan tambahan (jika ada). Karena perubahan semacam itu dapat membatalkan semua upaya pengujian sebelumnya yang telah diselesaikan dalam lingkungan ini.
5. Situs Produksi Shadow - Untuk mempersiapkan aktivasi dalam produksi nyata, Anda mungkin ingin terlebih dahulu mempromosikan fitur yang relevan ke lingkungan yang dianggap sebagai salinan (bayangan) dari lingkungan produksi nyata Anda. Jika pada saat ini selama proses migrasi masih ada yang rusak, maka itu adalah bendera merah untuk mengembalikan beberapa langkah Anda sebelumnya. Perbaiki, dan coba lagi, sampai semua pihak yang terlibat menyetujui perubahan.
6. Situs Produksi - Jika Anda menyelesaikan semua langkah sebelumnya, maka langkah ini harus menjelaskan sendiri, dan cukup mudah. Tergantung pada kebutuhan Anda, ini bisa berupa satu situs, atau sesuatu yang setara dengan Multi-situs Drupal sedangkan semua situs yang terlibat menjalankan versi semua fitur yang sama.
7. Situs Dasar - Dalam pengalaman saya, tidak banyak (jika ada) implementasi Drupal di mana jenis situs ini digunakan (juga). Ini hanyalah salinan dari Situs Produksi, tetapi tersedia untuk pengembang Drupal, penguji, dll yang dapat digunakan untuk memverifikasi seperti apa lokasi produksi, atau untuk melakukan pelatihan pengguna, dll. Dan setiap saat pengembangan baru siklus dimulai, komponen situs yang akan terkena dampak (perlu diubah) harus "disalin entah bagaimana" menggunakan Situs Baseline ini sebagai input, dengan sebagai target Situs Pengembangan Pribadi .

Jelas, inventaris jenis situs Drupal di atas seperti dunia yang ideal. Bergantung pada ukuran tim pengembangan Anda, dan / atau anggaran yang tersedia untuk membuat dan memeliharanya, tidak semuanya dapat digunakan (atau terjangkau). Inventaris ini dimodelkan setelah praktik terbaik di bidang SCM, yang digunakan di sebagian besar semua perusahaan besar / global (bank, maskapai penerbangan, dll).

5 - Modul terkait

Lengan kuat

The StrongArm modul memungkinkan untuk mengekspor variabel (modul yang menyimpan pengaturan mereka dalam variabel) dengan Fitur modul.

Ekspor Node

The ekspor Node modul memungkinkan pengguna untuk node ekspor dan kemudian impor ke instalasi Drupal lain.

Ekspor Peran

The Role Ekspor modul memungkinkan peran untuk memiliki machine_names dan menghasilkan peran id yang unik (menyingkirkan) didasarkan dari machine_name tersebut. Peran dapat diekspor dengan Fitur dan mendapatkan cara yang sama persis jika diimpor di situs lain.

Fitur Usir

The Fitur Usir modul memungkinkan untuk benar-benar tidak termasuk fitur individu komponen dari fitur UI dan fitur ekspor. Berikut ini kutipan dari halaman proyeknya:

 Modul ini berguna ketika ada komponen fitur yang Anda ingin memastikan TIDAK PERNAH diekspor. Jika Anda menggunakan fitur untuk membangun atau penyebaran situs, maka Anda mungkin mengalami masalah seseorang yang secara tidak sengaja mengekspor variabel stempel waktu seperti cron_last atau update_last_check. Anda mungkin juga ingin membuang izin untuk modul pengembang agar tidak terjebak dengan izin situs lainnya yang ingin Anda ekspor. Item yang dibuang tidak akan muncul di modul fitur Anda ATAU MODUL LAINNYA, jadi gunakan dengan hati-hati. Untuk daftar pusat fitur yang tidak boleh diekspor, lihat https://www.drupal.org/node/2400531

KACANG

The Bean modul membuat blok Anda diekspor. Berikut ini kutipan dari halaman proyeknya:

Pikirkan Bean sebagai metode untuk menyediakan tipe baru (dibandingkan dengan node, ini akan menjadi tipe konten) yang kemudian menyediakan antarmuka konten tambahan untuk membuat sebanyak mungkin blok yang Anda perlukan (lihat tangkapan layar di bawah). Konten kacang kemudian dapat ditempatkan di sekitar situs sama seperti blok lainnya.

Modul ini juga karya besar dalam kombinasi dengan UUID dan UUID Fitur Integrasi modul. Modul ini baru dimulai pada D7, tetapi sudah disertakan dengan Drupal 8 core. Video tutorial tutorial modul Drupal Bean - menggunakan Bean Admin UI memberikan pengantar yang bagus untuk benar-benar memahami kekuatan modul ini, dan hal-hal yang dapat Anda lakukan dengannya (dengan hanya menggunakan teknik pembangunan situs, tidak ada pengkodean kustom yang terlibat).

Habitat

The Habitat modul yang paling masuk akal dalam Fitur alur kerja berbasis. Berikut ini kutipan dari halaman proyeknya:

Dalam pengaturan multi-lingkungan (mis. Prod, test, dev, local) ada beberapa modul yang Anda ingin selalu diaktifkan atau dinonaktifkan pada lingkungan tertentu. Setiap kali Anda menyinkronkan basis data meskipun Anda harus mengaktifkan kembali / menonaktifkan modul yang sama. Lebih buruk lagi, Anda menjadi malas dan terus mengaktifkan modul pengembangan pada produksi.

Habitat menyediakan pengaturan untuk mengaktifkan atau menonaktifkan modul tertentu pada setiap lingkungan (habitat). Cukup tetapkan variabel dengan misalnya $ conf ['habitat'] = 'lokal'; dalam file settings.php Anda (variabel aktual untuk digunakan ada dapat dikonfigurasi untuk alur kerja Anda saat ini). Modul penonaktifan / pengaktifan dilakukan pada hook_init.

6 - Sumber daya yang disarankan:

• Dokumentasi komunitas tentang Fitur.
• Bagian dari jawaban ini didasarkan pada (luar biasa saya pikir) Fitur debat .
• Tutorial video:
  • Menciptakan Fitur .
  • Mengembalikan Fitur .
  • Memperbarui Fitur .
  • Membuat fitur dengan cara yang benar .
  • Keterbatasan Fitur .

7 - Alternatif yang memungkinkan untuk menggunakan Fitur

Jika Anda tidak dapat, atau bersedia (belum), menggunakan Fitur , maka Anda mungkin ingin memeriksa sejauh mana pendekatan / modul di bawah ini dapat memberikan beberapa jenis alternatif.

Ekspor / Impor Manual

Ini adalah fasilitas yang umum dikenal (untuk menghindari fitur kata ...) tersedia melalui UI admin, untuk modul seperti Aturan , Tampilan , dll. (Daftar tidak lengkap!)

Salinan bundel

Beberapa orang menganggap modul salinan Bundle sebagai alternatif yang memungkinkan. Ini memiliki dukungan ekspor / impor untuk:

• Jenis node.
• Taksonomi.
• Pengguna.
• Bidang API bidang.
• Kelompok lapangan.

Konflik gabungan mungkin akan diberikan ketika beberapa pengembang mengintegrasikan konfigurasi mereka ke dalam Fitur. Saya menulis beberapa pedoman untuk meninjau kode fitur, tetapi saya pikir yang paling penting adalah ini:

Hanya komit perubahan kode yang dimaksudkan.

Apa artinya ini? Ini berarti bahwa setiap pengembang harus meninjau kode sebelum melakukan. Tidak ada "keajaiban" untuk mencegah perubahan kode yang tidak diinginkan tanpa pengembang berhati-hati.

• Tinjau perubahan kode dengan git diff.
• Buat tambalan diff cepat menggunakan git diff > blah.patch, dan ubah tambalan secara manual untuk hanya menyertakan perubahan konfigurasi yang dimaksudkan.
  • Hal-hal seperti "mtime", komentar dalam tampilan ekspor dalam file info tidak perlu dimasukkan dalam komit.
  • Saya menjadi cukup mahir dalam meninjau blok kode konfigurasi yang berbeda dari waktu ke waktu. Lebih mudah sekarang untuk melihat perubahan berlebihan pada tampilan atau panel, dan 10ddvim cepat menghilangkan perubahan dalam tambalan (misalnya).
  • Saya pikir, "Oh, hei, saya tidak mengubah apa pun yang berkaitan dengan bidang, jadi saya tidak akan melakukan featurename.features.field_base.inc."
• Tidak pernah digunakan git commit -a. Ini adalah praktik mengerikan yang harus dilanda penggunaan. Selalu tambahkan dan komit secara eksplisit!
• Gunakan git rebasepada cabang git lokal untuk memastikan fitur ini paling mutakhir.
• Strategi git merge juga dapat membantu ketika benar-benar melakukan penggabungan:
  • git merge -s recursive -X patience (membutuhkan git 1.7+ iirc).

Akhirnya pertimbangkan untuk menambahkan batasan sosial untuk pengembang sehingga pengembang harus meninjau kode mereka sebelum bergabung ke dalam trunk / stable baik dengan ulasan patch atau permintaan tarik. Orang-orang akan marah tentang batasan sosial, tetapi mereka harus marah pada diri mereka sendiri karena tidak meninjau kode mereka.