Kontrol versi dan file konfigurasi pribadi


36

Proyek kami menggunakan file konfigurasi khusus pengguna. File ini saat ini tidak dalam kontrol versi, karena ini berbeda untuk setiap pengguna. Masalahnya adalah, setiap kali pengembang menambahkan modul baru yang memerlukan konfigurasi, atau mengubah nama modul yang ada, pengembang lain mendapatkan kesalahan karena file konfigurasi pribadi mereka tidak diperbarui.

Untuk mengatasi masalah ini, kami berpikir untuk bekerja dengan dua file konfigurasi: file konfigurasi global / standar yang akan berada dalam kontrol versi dan akan diperbarui secara berkala oleh setiap pengembang yang menambahkan modul baru, dan file konfigurasi pribadi yang akan dijauhkan kontrol versi dan hanya akan berisi perubahan spesifik pengguna.

Namun, ini sepertinya solusi ad-hoc.

Bisakah Anda mengusulkan solusi yang lebih baik?

Apa yang dilakukan para profesional?



4
Boggle ... Mengapa Anda bahkan memungkinkan pengembang untuk mengganti nama modul dan memutus konfigurasi pelanggan di setiap titik selain peningkatan besar ?
Mark Booth

@ jk ya, bahkan ada kecocokan yang lebih baik: stackoverflow.com/questions/1974886/…
Erel Segal-Halevi

Saya bingung. Bagaimana ini bukan masalah saat Anda menginstal pemutakhiran.
Joshua

6
Ini bukan solusi ad-hoc sama sekali. File konfigurasi utama hidup dalam kontrol versi, diganti seperti yang disyaratkan oleh file konfigurasi khusus pengguna. Tentu saja, jumlah konfigurasi khusus pengguna perlu diminimalkan, tetapi sejumlah kecil mungkin tidak dapat dihindari.
William Payne

Jawaban:


22

Meskipun Anda sudah mendapatkan jawaban yang bagus di sini, kebanyakan dari mereka melewatkan akar penyebab masalah Anda: file konfigurasi pengguna Anda tampaknya berisi lebih dari sekadar informasi spesifik pengguna, mereka juga mengandung informasi (mungkin berlebihan) yang berada di bawah kendali versi di tempat lain , mungkin dalam file yang berbeda, seperti nama modul.

Saya dapat memikirkan dua solusi yang mungkin di sini:

  • coba pisahkan informasi itu dengan ketat. Misalnya, jangan gunakan nama modul apa pun di konfigurasi pengguna Anda. Gunakan nomor id (misalnya, GUID) untuk merujuk ke modul, dan biarkan nomor id itu tidak pernah berubah setelah ditugaskan ke modul. Tentu saja, itu mungkin memiliki kelemahan bahwa file konfigurasi pengguna Anda kehilangan beberapa kesederhanaan yang mungkin mereka miliki sekarang. Anda mungkin perlu membuat alat GUI untuk mengedit file konfigurasi Anda alih-alih menggunakan editor teks biasa.

  • berikan file konfigurasi Anda nomor versi, dan setiap kali sesuatu seperti nama modul diubah, berikan nomor versi baru kepada mereka. Kemudian Anda bisa memberikan skrip pemutakhiran yang memeriksa nomor versi, dan jika file konfigurasi tidak mutakhir, itu mengubah semua nama modul yang ditemukan dalam file dan meningkatkan nomor versi setelahnya. Ini bisa otomatis, sehingga proses peningkatan tidak akan mengganggu rekan tim Anda dalam pekerjaan sehari-hari.

EDIT: setelah membaca posting Anda lagi, saya pikir solusi yang Anda anggap wajar, asalkan modul baru ditambahkan, tetapi tidak diganti namanya. Apa yang saya tulis di atas akan memungkinkan untuk mengubah nama modul atau struktur konfigurasi modul yang ada sesudahnya. Tetapi jika Anda tidak membutuhkan itu, saya akan tetap pada solusi yang paling sederhana.


11

Ini solusi yang masuk akal.

Anda perlu cara menentukan nilai awal dari setiap elemen konfigurasi baru. Ini harus disimpan di suatu tempat dan file konfigurasi global, hanya-baca, adalah pilihan yang jelas.

Kemudian ketika setiap pengguna mengubah konfigurasi pribadi mereka, Anda menulis perubahan ini ke salinan lokal mereka.

Kode Anda perlu membaca konfigurasi global terlebih dahulu dan yang spesifik pengguna untuk menimpa nilai yang diubah. Ini akan jauh lebih mudah daripada membaca yang lokal dan kemudian mencoba mencari tahu mana yang belum ditetapkan dan karenanya perlu membaca dari file pengaturan global.

Jika Anda menggunakan sesuatu seperti XML untuk penyimpanan maka Anda tidak perlu khawatir tentang menangani case di mana Anda menghapus pengaturan. Mereka tidak akan diminta dari salinan pengguna file dan jika Anda membuat ulang file di save mereka akan dihapus saat aplikasi pertama kali digunakan setelah perubahan.


3

Kami memiliki solusi yang agak menarik, kami terutama pengembang PHP, jadi kami menggunakan Phing yang memungkinkan Anda untuk membuat tugas otomatis yang ditulis dalam PHP, jadi alih-alih melakukan pembaruan svn normal kami, kami melakukan "pembaruan phing" yang memanggil pembaruan svn, dan kemudian mengganti konfigurasi kami dengan variabel yang tepat, misalnya, konfigurasi:

$db_user = "${test.db_user}";

Jadi file konfigurasi semua versi dengan sintaks yang menarik, dan kemudian kita menghasilkan file konfigurasi adhoc, tidak berversi untuk contoh spesifik saya, yang menggantikan "variabel" dengan pengaturan tidak berversi yang ditentukan dalam file ini tidak berversi. Dengan cara ini kita dapat memodifikasi file khusus pengguna dan membuat perubahan mengisi seluruh copy pekerjaan lainnya.


2

Program harus memiliki pengaturan default dalam kode ketika nilai tidak ditemukan dalam file konfigurasi. Dengan cara ini, hal-hal baru ditambahkan tidak akan rusak, jalur peningkatan Anda akan lebih lancar, dan pengguna Anda akan mundur ketika mereka mengacaukan file konfigurasi juga.

Contoh lain yang lebih kompleks adalah saat startup program atau titik kunci lainnya, buka file konfigurasi menggunakan modul inisialisasi dan tambahkan semua default yang hilang, tetapi ini tampaknya cukup berat.


+1 untuk menyebutkan bahwa ini bukan hanya masalah bagi pengembang, tetapi masalah penerapan umum.
sleske

2

Masukkan nomor versi ke dalam file konfigurasi pribadi (nomor versi dari format file config).

Buat kode yang memproses file konfigurasi pribadi periksa nomor versi, dan jika itu sudah ketinggalan zaman, jalankan melalui prosedur pembaruan. Jadi, pada dasarnya, siapa pun yang membuat perubahan yang akan memecah file konfigurasi yang ada perlu menabrak nomor versi dari format file konfigurasi, dan menulis prosedur untuk memperbarui file konfigurasi dari versi sebelumnya (mengganti nama bagian, dll.) Dan menyimpan kembali mereka.

Anda mungkin ingin beberapa proses seperti ini untuk pengguna akhir, jadi sebaiknya Anda menggunakannya untuk membuat hidup pengembang Anda lebih mudah.


1

Biasanya cara saya melihatnya dilakukan adalah memiliki file konfigurasi dengan nilai default diperiksa ke dalam repositori. Ini bisa, sebagai contoh, nilai-nilai yang diperlukan pada server pengujian. Kemudian, ketika pengembang memeriksa file, mereka akan memiliki semua nilai. Jika bidang baru ditambahkan atau bidang dihapus, ini ditangani dalam gabungan. Pengembang akan memeriksa nilai yang diperlukan untuk server target dan tidak memeriksa perubahan lain apa pun pada bidang yang ditujukan untuk lingkungan pengembangan pribadinya.

Perlu dipastikan bahwa penggabungan dilakukan dengan benar, tetapi tampaknya cukup aman bagi saya.


Tampaknya agak rentan kesalahan; Saya telah melihat ini dilakukan, tetapi devs terus memeriksa pengaturan pribadi secara tidak sengaja, yang kemudian menimpa pengaturan devs lain yang digunakan :-(. Juga, ini berarti seluruh pohon akan selalu muncul sebagai "dimodifikasi" dalam alat VCS, yang sangat nyaman
sleske

@sleske Itu memang membutuhkan sejumlah disiplin. Tapi jujur, saya berharap kemampuan untuk melakukan ini dengan baik dari kebanyakan pengembang.
Thomas Owens

1

Apa yang kami lakukan di sini adalah membuat blok pengaturan. Ini bisa dilakukan di Zend seperti ini:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

Ini berarti bahwa pengujian mewarisi produksi dan memperluasnya dengan key3. Yang perlu dilakukan setiap pengembang adalah mengatur lingkungannya (pengujian atau produksi dalam kasus ini)


Pengaturan lebih spesifik untuk pengguna. Mereka termasuk hal-hal seperti folder instalasi aplikasi, preferensi pribadi, dll. Jadi, tidak cukup hanya dengan memilih antara dua lingkungan yang telah ditentukan sebelumnya.
Erel Segal-Halevi

Bergantung pada berapa banyak pengaturan dan bagaimana mereka digunakan, Anda dapat menggunakan sumber daya di file ini untuk Zend. Tidak yakin apakah ini juga berlaku untuk masalah Anda.
Agilix

Saya membutuhkan solusi yang lebih umum, yang dapat menangani semua jenis preferensi khusus pengguna, bukan hanya sumber daya.
Erel Segal-Halevi

Pikirkan saja di sini, tetapi bukankah lebih baik menyimpannya di basis data? Setidaknya preferensi. Dan kemudian Anda dapat memasangkan mereka pengguna. Jika tidak, itu hanya pemikiran;)
Agilix

0

Ini adalah solusi yang berguna berdasarkan pos: Mempertahankan kata sandi dalam kontrol sumber

Singkatnya, strateginya adalah untuk "menyimpan versi terenkripsi file konfigurasi dalam kontrol sumber dan kemudian menyediakan sarana yang dengannya pengguna dapat mengenkripsi dan mendekripsi data itu."

  1. Buat file comfig dummy dan .gitignore.
  2. Buat makefile yang dapat mengenkripsi dan mendekripsi file konfigurasi
  3. Simpan makefile dan file konfigurasi terenkripsi dalam repositori
  4. Makefile meminta kata sandi, dan bagaimana menghubungi pengarang untuk kata sandi.
  5. Saat membangun proyek, jika makefile belum berjalan, sarankan pengguna dengan console.error ("File config [conf / settings.json] hilang! Apakah Anda lupa menjalankannya?) make decrypt_conf ?");
  6. Cek dijelaskan untuk memastikan file konfigurasi up to date.

1
-1 karena ini tidak menjawab pertanyaan asli sama sekali. Juga, jawaban yang sedikit lebih dari sebuah tautan dan tidak ada penjelasan tidak berguna untuk format Tanya Jawab Stack Exchange, karena tautan eksternal mungkin hilang pada beberapa titik, tanpa meninggalkan referensi untuk apa jawaban yang disarankan itu.
Derek

1
Ini adalah postingan yang menarik.
Erel Segal-Halevi

0

Kami membangun alat yang disebut Config yang menangani masalah konfigurasi seperti ini. Apa yang akan Anda lakukan adalah membuat (atau mengimpor) 1 file konfigurasi utama. Kemudian buat lingkungan yang disebut Lokal. Di lingkungan lokal, buat beberapa instance, 1 instance per pengguna. Jika Anda perlu membuat perubahan yang umum di seluruh papan, seperti menambahkan entri konfigurasi baru atau memodifikasi nama modul, buat saja perubahan, dan itu akan diterapkan di seluruh papan. Jika Anda ingin membuat perubahan instance / pengguna, buat nilai konfigurasi itu sebagai variabel, lalu ubah variabelnya. Perubahan ini hanya akan diterapkan pada instance / pengguna Anda. Semua ini di bawah kontrol versi. Anda menggunakan file konfigurasi melalui push atau pull. Opsi tarikan mirip dengan git pull, tetapi untuk instance / pengguna tertentu.

Config memberi Anda fitur tambahan seperti membandingkan konfigurasi antara pengguna, pencarian, penandaan, validasi, dan alur kerja. Ini SaaS, jadi tidak benar-benar untuk mereka yang belum siap untuk cloud, tetapi kami memiliki rencana di tempat.


Saya pikir memasukkan SaaS untuk mengelola konfigurasi pengembang akan menjadi kerja keras ... Tapi itu hanya, seperti, pendapat saya. Juga, jika konfigurasi berisi data sensitif (tidak mungkin, karena mungkin untuk pengujian pada workstation mereka sendiri) itu adalah no-go instan.
Mael

Saya tidak berpikir Config adalah kerja keras jika Anda mempertimbangkan betapa mudahnya untuk mengatur versus waktu yang dihabiskan untuk mencari tahu solusinya, bertanya kepada masyarakat, mengimplementasikan, dan memeliharanya. Config berfungsi pada semua platform, format, bahasa, perpustakaan, sehingga Anda hanya mempelajarinya sekali saja. Pada data sensitif, ada opsi enkripsi sisi klien, kubah lokal jika Anda mau. Pengguna yang masuk semua dapat menginstal di rumah atau menggunakan VPC.
Bienvenido David
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.