Apa alur kerja yang disarankan untuk migrasi (CMI) konfigurasi dari dev -> stage -> produksi?

41

Kami memiliki drupalcamp beberapa bulan yang lalu dan seseorang bertanya tentang mengelola penyebaran dengan sistem konfigurasi baru (CMI). Salah satu alur kerja ideal yang mungkin akan melibatkan menjaga konfigurasi dalam kontrol versi dan masih dapat melakukan migrasi konfigurasi antara anggota tim.

Hal terbaik yang kami dapat ketahui (sebagian berdasarkan presentasi di DrupalCon Portland) adalah:

  • Beri tahu kontrol versi untuk mengabaikan direktori konfigurasi aktif.
  • Salin semua Konfigurasi ke direktori pementasan dan komit ke kontrol versi.

Dan gunakan settings.php untuk membalik direktori aktif / staging antara 2 lingkungan. Namun, sementara mencari tahu alur kerja penyebaran dari satu server ke yang berikutnya adalah rumit tapi bisa dilakukan, apa alur kerja yang disarankan dari beberapa lingkungan lokal (yaitu beberapa pengembang) menjadi dev (atau antara satu sama lain) - Masalah yang mungkin terjadi adalah setiap anggota tim akan berbagi lingkungan yang sama atau serupa jadi bagaimana perubahan pada mesin satu rekan tim datang?

migration 8 version-control btmash
sumber
5
Saya benar-benar tidak setuju dengan suara dekat saat ini. Karena CMI adalah fokus untuk Drupal 8, saya pikir kita dapat memiliki beberapa jawaban yang baik di sini.
mpdonadio
3
Setuju, ini pertanyaan yang sangat bagus. Saya percaya tugas penting drupal.org/node/1703168 adalah tentang ini dan topik lainnya dan belum sepenuhnya terselesaikan, jadi jawaban di sini dapat membantu mendorong masalah itu ke depan.
Berdir
Saya minta maaf jika pertanyaan saya dianggap negatif terhadap inisiatif CMI (yang sama sekali bukan maksud saya). Saya telah memperbarui pertanyaan sehingga kedengarannya lebih netral.
btmash
2
saya hampir akan mengatakan "Sudahkah Anda mencoba fitur". Mungkin "D8" harus masuk dalam judul pertanyaan? Tag "8" sedikit tidak terlihat.
donquixote
1
Revisi judul sehingga pertanyaan dapat dilihat baik dengan tag atau melalui judul :)
btmash

Jawaban:

19

Setelah berbicara sedikit dengan pengelola CMI, diskusi tentang apa pendekatan terbaik belum selesai tetapi berikut ini adalah apa yang paling masuk akal saat ini.

Mencoba untuk tetap singkat untuk saat ini, akan mencoba untuk memperluas berdasarkan pertanyaan / ketika masalah yang dirujuk diselesaikan dengan jawaban resmi.

Jadi, pertama, faktanya ...

  • Seperti yang telah disebutkan, ada direktori aktif dan pementasan. Aktif sepenuhnya dikelola oleh Drupal, membuat perubahan langsung di sana (langsung atau tidak langsung dengan beralih ke lokasi lain) tidak didukung.
  • Pementasan adalah tempat Drupal mencari konfigurasi untuk diimpor dan apakah tidak peduli tentang hal itu.
  • Proses impor penting, perubahan konfigurasi dapat memengaruhi situs dengan cara tertentu dan perlu diperiksa validitasnya. Anda tidak dapat mengubah jenis bidang bidang teks ke referensi entitas, misalnya, yang tidak berfungsi.
  • Impor config selalu perlu dijalankan di semua konfigurasi, Anda tidak bisa mengimpor satu tampilan atau jenis node. Itu sudah dicoba, tetapi mencoba untuk mengatasi ketergantungan, menghapus / mengganti nama dan sebagainya menghasilkan sistem yang sangat rumit dan tidak berhasil.
  • Satu-satunya cara untuk menginstal ulang konfigurasi default, adalah menginstal ulang modul itu. Yang berarti bahwa itu pertama-tama akan mencoba untuk menghapus semua konfigurasi (seperti bidang). Jadi itu bukan pilihan. Manual, perubahan spesifik dalam fungsi pembaruan dimungkinkan tetapi terlalu membosankan untuk ini saya pikir.
  • Seperti yang dijelaskan modul fitur, modul ini akan difokuskan pada penyediaan fungsionalitas yang dapat digunakan kembali, bukan penyebaran konfigurasi yang berkelanjutan. Ini adalah apa yang dirancang untuk tempat pertama.

Mengingat itu, rekomendasi saat ini adalah menempatkan direktori pementasan ke dalam kontrol versi. Setiap pengembang kemudian memiliki kontrol penuh atas apa yang dia tempatkan di sana, baik dengan menyalin seluruh direktori aktif, atau hanya file konfigurasi tertentu. Perubahan direktori pementasan kemudian dilakukan, didorong ke produksi dan impor konfigurasi dijalankan (di UI atau dengan drush).

Berdir
sumber
Direktori pementasan dalam kontrol versi, saya mendapatkan bagian itu. Bagian-bagian lain adalah apa yang coba saya pikirkan untuk diproses. Jadi, jika seseorang membuat perubahan, mereka menyalin perubahan mereka ke direktori pementasan dan melakukan itu. Setelah itu, pengembang lain / server berikutnya mendapatkan perubahan dan menyinkronkan perubahan tersebut ke direktori aktif. Dan bilas dan ulangi untuk rantai server lain di sepanjang jalan (pementasan, produksi, dll). Dan itu selalu melewati pementasan sehingga tidak ada saklar direktori yang terjadi lagi. Apakah itu akurat?
btmash
Iya nih. Tidak boleh ada pengalihan direktori. Setiap perubahan konfigurasi harus melalui proses impor atau Anda mungkin berakhir dengan situs yang rusak. Sebagai contoh, daftar modul juga merupakan konfigurasi. Menyebarkannya berarti modul harus diinstal / dihapus (Catatan: Ini belum berfungsi, tetapi ada masalah untuk memperbaikinya).
Berdir
Ok, jadi lebih banyak pertanyaan sekarang (dibagi menjadi 2 komentar) :) Pertama, Anda menyebutkan modul adalah konfigurasi. Jadi, bahkan jika modul ditambahkan ke repo dan tidak diaktifkan / dinonaktifkan, perlu diinstal / dihapus untuk hanya duduk di sana?
btmash
Dan tindak lanjutnya: (A) Apakah akan ada mekanisme untuk menyalin perubahan dari direktori aktif -> staging (untuk menyederhanakan versus seseorang yang masuk ke direktori config untuk komponen-komponen ini - mungkin cara untuk memilih variabel tertentu). (B) Apakah direktori pementasan dikosongkan setelah perubahan disinkronkan dari pementasan -> aktif? (B1) Jika demikian, apakah strategi dari sudut pandang devops untuk mereset direktori itu sebelum tarikan git? (B2) Jika tidak, apakah benar untuk menganggap bahwa ketika pementasan-> sinkronisasi aktif terjadi, seharusnya tidak ada pengaruh pada konfigurasi yang belum berubah?
btmash
Status pemasangan modul adalah konfigurasi. Bukan modul itu sendiri :) Itu yang Anda gunakan. a) Ada UI untuk mengunduh tar.gz dari direktori aktif, satu untuk mengunggah kata tar.gz ke direktori pementasan dan satu untuk benar-benar melakukan Impor, dengan ikhtisar dan perubahan yang berbeda. B) Saya percaya saat ini sudah dikosongkan, tapi saya berasumsi Anda dapat dengan mudah mengembalikannya dengan git. Tidak yakin, mudah diperiksa. Semua itu bisa dicolokkan, jadi mungkin ada implementasi yang sedikit berbeda yang tidak dihapus. B2) Saya tidak mendapatkan yang ini tapi saya pikir ya.
Berdir
4

Jawaban bagus sejauh ini. Terima kasih semuanya!

Kami memulai proyek Drupal 8 baru-baru ini dan menerapkan alur kerja berikut.

Kami memiliki tiga folder aktif, pementasan dan ekspor. Pengembang membuangnya untuk diekspor. Saya tidak ingin menyimpannya di panggung. Saya pikir ini lebih mudah untuk dikerjakan ketika konfigurasi bersama tidak secara langsung disimpan dalam folder pementasan. Itu hanya penebangan saya tidak punya fakta keras tentang ini ...

Templat proyek drupal 8 kami saat ini tersedia di github. Saya juga menulis beberapa perintah drush berguna untuk mempercepat aliran devleoper. Tidak diperlukan penyalinan manual dari aktif ke ekspor.

webflo
sumber
1
Sejauh ini, saya setuju dengan pendekatan ini. Saya telah menambahkan semua fitur dari tautan dalam posting ini ke perintah Drush config-export dan config-import. Saya berharap orang lain akan bergabung dengan saya dan @ florian dalam menjelajahi solusi direktori 3 ini.
Moshe Weitzman
Bagaimana Anda menangani sites/default/files/config_HASHfolder config yang memiliki akhiran hash, mis. Config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr
therobyouknow
@therobyouknow Anda dapat mengganti lokasi folder-folder ini. Cari saja "Lokasi file konfigurasi situs." di settings.php saya menggunakan cuplikan berikut. Ini berarti, konfigurasi disimpan di luar direktori root Drupals. $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);
webflo
Terima kasih @ webflo saya melihat ini. Apa manfaat mengelola basis kode dan konfigurasi secara terpisah? Saya pikir pemisahan ini sedikit buatan karena baik kode dan konfigurasi (dalam yaml) menentukan perilaku dan saling bergantung satu sama lain. Dalam Drupal 7, konfigurasi-dalam-kode (atau dapat dilacak oleh Git) dilakukan dengan modul Fitur yang membuat modul untuk setiap konfigurasi tertentu yang harus dilacak dalam kode. Dalam Drupal 8, ada Fitur 3.x yang seperti yang saya mengerti, melakukan hal yang sama tetapi menggunakan YAML untuk menyimpan konfigurasi dan modul yang dihasilkan tidak tergantung pada modul Fitur.
therobyouknow
Saya pikir Anda salah paham, konfigurasi dir masih di git, tetapi situs Drupal saya tidak di root git repo. Situs ini disimpan / web. Jadi / config dan / web berada pada level yang sama.
webflo
2

Saya belum mencoba ini, tetapi rencana saya adalah membuat modul khusus yang berisi file konfigurasi "default" yang hanya berisi konfigurasi yang saya pedulikan. Saya percaya modul lain dapat berisi konfigurasi yang menimpa modul lain. (Jika tidak ini harus dimungkinkan).

Saya pikir Anda harus meninggalkan folder konfigurasi sendiri. Abaikan itu. Itu otomatis dihasilkan saat menginstal dari semua file konfigurasi modul individu. Jalannya panjang dan acak. Jika Anda menyimpan semua itu dalam sebuah repo, Anda akan memerlukan repo yang terpisah dan Anda akan membawanya berton-ton file konfigurasi default yang tidak dibutuhkan.

Menempatkan konfigurasi dalam modul khusus menjadikannya bagian dari basis kode utama Anda.

Proses penyebaran akan:

  1. Git pull atau apa pun untuk mendapatkan file baru.
  2. Bersihkan cache.
  3. Setel ulang konfigurasi default. (Dari file modul khusus Anda)

Anda dapat membuat modul khusus (dengan konfigurasi itu sendiri) untuk setiap lingkungan jika Anda mau.

Jonpugh
sumber
Ini kedengarannya seperti fitur, bukan? Atau ada perbedaan signifikan yang saya lewatkan?
Letharion
Ini pendekatan yang menarik dan saya suka ide itu. Namun, salah satu keuntungan terbesar yang telah disebutkan sebagai bagian dari inisiatif CMI adalah kemampuan untuk berpindah konfigurasi dari direktori konfigurasi. Dan dari apa yang saya lihat, file settings.php memungkinkan Anda menentukan di mana direktori aktif / staging berada (mis. Mereka tidak perlu jalur yang dibuat secara otomatis). Oleh karena itu, saya pikir alur kerja dengan konfigurasi saat ini harus dimungkinkan tanpa perlu membuat fitur seperti @Letharion menyebutkan di atas.
btmash
2

Catatan: Saya menghargai bahwa ini bukan jawaban dalam arti yang paling ketat dalam kaitannya dengan pertanyaan, tapi saya sudah memasukkannya di sini dan saya akan kembali dan mengedit / menghapus begitu Fitur memiliki rilis 8.x dan debu telah menetap sedikit lebih. Ini terlalu besar untuk komentar dan saya ingin mendapatkan £ 0,02 saya di :-)

Sebagai penggemar besar Fitur , saya sarankan mengawasi inkarnasi modul Fitur D8.

Diambil dari halaman proyek

Versi 3.x Fitur direncanakan untuk Drupal 8 untuk diintegrasikan dengan sistem manajemen konfigurasi baru. Jika Anda hanya perlu mengekspor konfigurasi situs sederhana, sistem manajemen konfigurasi D8 harus digunakan alih-alih Fitur. Anda akan menggunakan Fitur di D8 untuk mengekspor fungsionalitas yang dibundel (seperti "fitur galeri foto").

Cara saya agak melihatnya adalah bahwa ide ini membuatnya lebih mudah bagi tim dev untuk bekerja pada bagian yang lebih kecil dari sebuah situs. Saya tidak akan masuk ke alur kerja namun karena masih ada terlalu banyak variabel yang tidak diketahui, tapi saya tidak bisa melihatnya yang jauh berbeda dari prosedur penyebaran Fitur saat ini.

Saya tidak bisa tidak berpikir ya, CMI luar biasa; tetapi sebagian besar situs saya masih akan berakhir dengan modul Fitur (walaupun jumlahnya lebih sedikit karena tidak harus mengekspor SETIAP jenis konten, izin dll)

Chapabu
sumber
Meskipun saya setuju bahwa fitur akan sedikit mengubah perannya dan (semoga) menjadi alat untuk menggabungkan komponen konfigurasi bersama (seperti fitur galeri foto yang Anda sebutkan), konfigurasi (sejauh yang saya mengerti) masih akan dipertahankan melalui aktif direktori konfigurasi. Jadi Fitur dapat menyelesaikan komponen tertentu tetapi bagaimana alur kerja direktori konfigurasi dikelola di seluruh lingkungan adalah masalah sebenarnya. Prosedur penyebaran sedikit berbeda dari prosedur penyebaran fitur saat ini terutama karena data activestore ada di db dan datastore adalah file.
btmash
... prosedur penyebaran fitur d7 melibatkan data activestore dalam database dan datastore dalam file. Kami beralih ke keduanya menjadi file dan hanya perlu memastikan bagaimana itu mempengaruhi perubahan alur kerja.
btmash
Perhatikan bahwa fitur benar-benar tidak memiliki konsep aktif dan datastore / staging. Atau setidaknya tidak konsisten, itu semua tergantung pada kait / hal tertentu yang mengintegrasikannya. Tampilan default langsung dalam kode, misalnya, perubahan segera aktif (terlepas dari caching), tidak ada proses penyebaran terkontrol dengan fitur. Itu selalu menjadi salah satu masalah utama saat menggunakan fitur untuk penyebaran.
Berdir
Kamu benar. Saya tidak tahu bagaimana saya mendapatkan modul konfigurasi untuk D7 yang bercampur dengan Fitur, tetapi saya melakukannya.
btmash