Bagaimana mengatur proses pengembangan basis data lokal untuk tim web kecil?

Latar Belakang

Saya sedang berupaya menciptakan proses pengembangan baru untuk tim web kecil yang terdiri dari sekitar 4 programmer dan 4 desainer, dengan potensi yang jelas untuk menumbuhkan tim di masa depan. Produk kami adalah aplikasi utama yang mendukung situs web klien yang juga kami desain dan host.

Sebelumnya, kami semua bekerja melalui FTP pada server dev, dengan database dev tunggal. Itu "bekerja" ^* untuk sementara waktu, tetapi kami bergerak ke arah yang baru, jadi sekarang saatnya untuk mematangkan proses kami.

Kami menggunakan Percona Server 5.5, tetapi ini haruslah agnostik basis data, dengan gagasan menjaga biaya tetap rendah.

Tujuan :

Saya melihat ke dalam menciptakan proses integrasi berkelanjutan (CI) untuk pengembangan database dengan pemikiran sebagai berikut:

1. Pengembang memiliki salinan data lokal untuk menjalankan kode pengembangan
2. Dapat mengembalikan struktur database ke perubahan sebelumnya
3. Dapat memisahkan perubahan skema fitur baru vs perubahan perbaikan desain skema
4. Mampu mengubah struktur basis data secara lokal untuk pengujian

Konsep Awal

Saya telah membuat sketsa proses di bawah ini menggunakan SVN dan LiquiBase, meskipun itu benar-benar menghapus #4.

• buat cabang 'development' dari trunk
• pusat 'pengembangan' db server lari dari cabang 'pengembangan'
• pengembang lokal ditetapkan sebagai budak ke cabang pengembangan (menyediakan di #1atas)
• perubahan liquibase dilakukan secara teratur ke cabang pengembangan, yang mengeksekusi kait pasca-komitmen untuk memperbarui basis data pengembangan pusat (yang akan mengalir ke mesin lokal yang berjalan sebagai budak ke server pengembangan ini) (liquibase menyediakan di #2atas)
• ketika fitur atau perbaikan skema siap untuk menuju ke QA, DBA (saya) akan menggabungkan perubahan yang sesuai dari cabang pengembangan menjadi trunk. Tindakan ini akan membuat skrip sql untuk diterapkan ke server basis data pementasan.
• Staging server harus mencerminkan TRUNK, yang harus memiliki struktur yang sama dengan Produksi, ditambah perubahan yang ada di QA
• setelah mengeksekusi skrip sql pada server staging, lakukan beberapa QA pada perubahan.
• Jika semua terlihat bagus, TAG strukturnya. Ini akan menghasilkan skrip .sql untuk dijalankan dalam produksi secara manual oleh DBA (untuk jam-jam di luar jam sibuk jika diperlukan)

Proses ini mengharuskan semua pengembang menjalankan cabang 'pengembangan' yang sama, artinya hanya ada satu versi skema database pada waktu tertentu (tidak yakin bahwa saya menginginkan ini).

Ini juga berarti bahwa setiap perubahan pada skema tidak dapat diuji secara lokal dan dapat mempengaruhi pengembang lain jika tidak dilakukan dengan benar. Di lingkungan kami, pengembang mungkin menambahkan tabel baru tetapi jarang memodifikasi struktur yang ada. Sebagai DBA, perbaikan desain dilakukan oleh saya. Tetapi ketidakmampuan untuk menguji perbaikan secara lokal adalah kegagalan terbesar saya dari proses.

Bagaimana proses di atas dapat diubah untuk memungkinkan pengembangan lokal, sambil tetap mempertahankan salinan data yang relatif terbaru (sebagaimana disediakan oleh replikasi dalam proses yang saya usulkan)? Saya tidak memerlukan data terkini hingga minggu lalu.

---

^* Dengan 'berhasil', maksud saya sudah cukup tetapi adalah PITA.

Mengelola lingkungan

Saya pikir Anda pasti tidak ingin dipaksa menjadi versi database tunggal. Anda memiliki cukup pengembang sehingga Anda pasti akan memiliki beberapa alur kerja pengembangan, dan persyaratan untuk menerapkan tambalan ke lingkungan produksi saat ini terlepas dari alur kerja pengembangan.

Anda dapat menggunakan Liquibase atau proses manual untuk menghasilkan skrip tambalan untuk meningkatkan versi. Saya sarankan memulai dengan proses manual dan menggunakan alat perbandingan skema untuk QA di patch. Sinkronisasi yang bersih, otomatis, transparan dari basis data yang kompleks nontrivial sedikit utopia.

Model data pusat Anda dapat disimpan dalam sistem apa pun yang Anda inginkan. Saya telah menggunakan semuanya dari alat repositori perusahaan yang membosankan untuk membuat skrip tabel. Membuat skrip tabel bermain dengan baik dengan alat kontrol sumber biasa seperti subversi dan tidak semua alat repositori melakukan pekerjaan yang baik untuk versi.

Apa pun yang Anda gunakan sebagai repositori model data master, Anda memerlukan mekanisme yang cukup bersih untuk menggunakan lingkungan dari model itu. Ini harus terstruktur sehingga peluncuran ke lingkungan mudah. Anda juga memerlukan mekanisme untuk menambal dari satu versi yang dirilis ke yang berikutnya.

Apa yang telah kulakukan

Saya telah melakukan yang berikut di masa lalu ketika saya mengelola lingkungan pengembangan. Ini tidak terlalu berteknologi tinggi, tetapi dapat menerima kontrol versi dan pembuatan otomatis, sehingga membuatnya mudah untuk meluncurkan lingkungan ke versi tertentu, dan mempertahankan sejumlah besar lingkungan cukup praktis.

Mempertahankan repositori pusat: Ini bisa berupa sekumpulan skrip pembuatan basis data yang disimpan dalam sistem kontrol versi, atau model repositori dalam alat pemodelan data. Ambil pilihanmu. Model ini harus memiliki mekanisme pembangunan yang memungkinkan lingkungan untuk diluncurkan dari skrip tanpa banyak intervensi manual.

Jika Anda memiliki banyak data referensi, Anda akan memerlukan mekanisme memuatnya. Bergantung pada bagaimana Anda ingin melakukannya, Anda bisa menyimpannya dalam basis data atau kumpulan file. Keuntungan file adalah bahwa mereka juga dapat diversi dan dilabeli dari sistem kontrol versi yang sama dengan basis kode Anda. Sekelompok file CSV dan skrip pemuat massal dalam repositori kontrol sumber dapat melakukannya dengan cukup mudah.

Salah satu opsi untuk menyebarkan lingkungan pengembangan adalah untuk mengambil cadangan dari basis data produksi yang ditambal ke versi yang sesuai dan membuatnya tersedia untuk dev untuk dipulihkan ke lingkungan pengembangan.

Memudahkan untuk diluncurkan: Seperti proses pembangunan CI apa pun, basis data harus dapat digunakan dari satu skrip. Atur agar koneksi database dapat dipisah-pisahkan, atau skrip independen dari lokasi dan hanya dapat dijalankan melalui koneksi.

Script tambalan: Anda perlu menggulung maju dan mungkin memutar kembali skrip dari setiap versi yang dirilis.

Membangun lingkungan pengujian dari model repositori: Ini memastikan bahwa pengembangan pada lingkungan yang tidak sinkron dengan repositori terperangkap dalam pengujian.

Tes proses penyebaran: Script patching otomatis, namun mereka dibuat harus dapat diuji. Alat perbandingan skema cukup bagus untuk ini, bahkan jika Anda tidak menggunakannya untuk menghasilkan skrip tambalan.

• Buat lingkungan referensi dengan model repositori yang Anda uji

• Buat lingkungan uji asap dengan cadangan rilis produksi Anda atau build berdasarkan versi yang dirilis saat ini.

• Jalankan skrip tambalan terhadap lingkungan tes asap.

• Gunakan alat perbandingan skema untuk membandingkan lingkungan uji asap dengan lingkungan referensi. Skrip tambalan harus menghasilkan dua database yang identik, sehingga Anda dapat menyelidiki perbedaan apa pun.

Apa yang saya sukai dari proses ini

Ini agak kelas berat, dan dirancang untuk digunakan dalam lingkungan produksi yang cukup birokratis dan buram. Namun, ia memiliki kekuatan sebagai berikut:

• Pengembang dapat bermain-main di mana pun mereka butuhkan.

• Beberapa cabang dan aliran pembangunan dapat ditampung.

• Script deployment sendiri dapat diuji secara berulang. Ini sangat membantu untuk menutup penyebaran bunfight, karena pengulangan dapat ditunjukkan.

• Alat perbandingan skema menyediakan QA pada penyebaran itu sendiri.

• Pengujian selalu dilakukan terhadap apa yang diharapkan akan dirilis, dan ini akan menangkap masalah yang timbul dari lingkungan yang tidak sinkron.

• Penyebaran berdasarkan model repositori dan skrip tambalan berarti bahwa sampah yang tidak terkontrol tidak secara tidak sengaja dimigrasi dari lingkungan pengembangan ke produksi.

• Banyak proses dapat diotomatisasi, meskipun seringkali diinginkan untuk mempersiapkan dan menguji skrip tempel penerapan secara manual.

• Lingkungan murah dan mudah digunakan tanpa harus melewati rintangan.

• Pengembang dipaksa untuk membuat sistem yang dapat menerima proses pembangunan dan penyebaran yang sederhana.

• Pengembang dipaksa untuk mempelajari tugas administrasi basis data, tetapi lingkungan pengujian dan produksi terisolasi dari kesalahan noob.

Bagaimana mengatasi kebutuhan Anda

1. Pengembang memiliki salinan data lokal untuk menjalankan kode pengembangan terhadap
   
   Skrip penempatan atau gambar DB berarti bahwa mereka dapat mengatur lingkungan dari versi apa pun yang tersedia.

2. Mampu mengembalikan struktur basis data ke perubahan sebelumnya
   
   Sekali lagi, diurutkan berdasarkan skrip penerapan. Baik melalui DDL atau menguji gambar cadangan basis data yang dibuat melalui proses terkontrol, pengembang dapat memunculkan lingkungan ke versi spesifik apa pun yang Anda miliki.

3. Dapat memisahkan perubahan skema fitur baru vs perubahan memperbaiki desain skema
   
   Patch untuk versi umum dapat dipertahankan dalam garpu terpisah di pohon svn. Jika cadangan database digunakan sebagai lingkungan referensi, mereka perlu disimpan di suatu tempat dengan struktur folder yang sama dengan percabangan proyek kontrol sumber.

4. Mampu memodifikasi struktur basis data secara lokal untuk pengujian
   
   . Proses penyebaran yang sederhana memungkinkan devs untuk mengotak-atik, dan dengan mudah mengembalikan lingkungan ke keadaan lokal, atau membuka lingkungan referensi untuk melakukan perbandingan dan membuat set perubahan melawan.