Apakah dapat diterima untuk menyebarkan aplikasi web ke produksi langsung dari SVN

Pertanyaan

Apakah ada alasan sah untuk TIDAK menggunakan SVN untuk penyebaran produksi, atau apakah ini semata-mata kasus preferensi pribadi dan tidak ada kasus nyata terhadap SVN?

Latar Belakang

Tempat kerja saya memiliki budaya pelepasan tag pada SVN dan kemudian menyebarkan rilis tersebut langsung ke berbagai server web menggunakan svn coatau svn switchtermasuk langsung ke produksi.

Saya pribadi memiliki masalah dengan ini karena saya percaya bahwa tanpa menggunakan skrip build dan deploy atau bentuk atau deploy otomatis Anda kehilangan pengaturan lingkungan integrasi karena tidak terdokumentasi. Namun lebih dari itu saya punya firasat bahwa mungkin ada bahaya tersembunyi untuk melakukan apa yang telah diabaikan, sesuatu yang belum membesarkan kepalanya yang jelek.

Saya telah menyampaikan kekhawatiran saya kepada staf operasi yang bertanggung jawab untuk menyebarkan kode ke berbagai lingkungan kami (pementasan, pra-prod, produksi), dll. Argumen mereka cukup banyak sehingga ini bekerja cukup baik sejauh ini, tidak ada alasan untuk berubah.

Edit:

Apa yang saya maksud tentang membangun dan menggunakan:

Misalnya, jika pengembang memerlukan pengaturan web.config ditambahkan untuk lingkungan tertentu. Web.config umumnya tidak disimpan di svn sehingga file-file ini diperbarui secara manual tanpa bentuk skrip build otomatis. Jadi, jika mereka hilang atau OPS lupa menambahkan bidang ke web.config untuk rilis maka Anda memiliki masalah.

Skrip build yang mengatakan menggunakan XMLPoke untuk secara otomatis menghasilkan web.config yang sesuai untuk lingkungan tertentu sangat ideal karena Anda memiliki skrip versi yang mendokumentasikan semua perubahan yang diperlukan untuk setiap lingkungan Anda.

Metode Pembuatan dan Penyebaran Saat Ini

Untuk proyek yang dipermasalahkan pengembang membuat rilis secara manual, proyek lain memiliki langkah pembuatan terotomatisasi baik dengan NANT, atau MSBuild yang OK.

Migrasi database untuk sebagian besar proyek adalah melalui skrip DB, atau skrip migrasi (Migrator.NET), atau Paket CMS.

CI biasanya dilakukan oleh Team City berdasarkan basis per checkin, kami memiliki proses peninjauan kode bahwa semua tiket dilakukan di cabang dan kemudian peer review untuk validasi dan kebenaran / kualitas sebelum memeriksa ke dalam bagasi (berfungsi dengan baik).

Namun penyebaran kode aktual hampir selalu melalui SVN, baik melalui checkout dari rilis yang ditandai atau lebih umum lagi SVN Switch. Ini adalah sesuatu yang aneh dengan saya bahwa kami menggunakan repositori kami sebagai bagian dari proses penyebaran.

Konfigurasi umumnya tidak berubah sangat sering, satu-satunya hal yang akan ada di file konfigurasi adalah informasi khusus lingkungan. Yang lainnya ada di db.

Jangan salah paham ini berfungsi, ini bekerja dengan baik. Namun saya ingin mencoba dan mendorong untuk membangun dan menyebarkan otomatis. Saya telah menggunakan ini dengan Rails dan Capistrano, dan untuk proyek pribadi menggunakan Cygwin, Nant dan SSH.

Lebih penting lagi, saya akan memerlukan argumen valid yang sangat spesifik untuk membuat kolega saya berubah menggunakan Automate build and deploy.

Atau adakah TIDAK ADA argumen yang sahih yang menentang penggunaan SVN secara khusus untuk digunakan untuk produksi?

Dari pengalaman saya, ada kelebihan dan kekurangan:

Pro:

• Terkadang Anda membuat perbaikan panas yang mendesak di server produksi, lalu Anda dapat memeriksanya kembali langsung dari sana. (Meskipun secara teoritis, untuk alasan keamanan selalu merupakan ide bagus untuk menggunakan akses read-only ke repo dari server produksi.)

• Kesederhanaan: Anda mengirim dengan cepat, meskipun seperti yang disebutkan di sini, beralih ke skema skrip pembaruan bisa semudah.

Cons:

• Sistem Anda dapat menjadi tidak stabil selama svn uppembaruan Anda dan DB. Untuk situs dengan lalu lintas tinggi, ini berarti beberapa pengguna akan mendapatkan pesan kesalahan, halaman rusak, atau halaman kosong terbaik. Nah, itulah yang sangat sering kita lihat di berbagai layanan sosial. Namun, layanan yang baik tidak "secara atomis" dalam arti bahwa itu menempatkan sistem ke mode pemeliharaan selama pembaruan. ( Kamu mematahkan reddit! )

• Konflik: menyelesaikan konflik tiba-tiba pada server produksi adalah ide yang buruk: sekali lagi, layanan menjadi tidak stabil saat Anda memperbaikinya.

• File yang tidak terkait pada server produksi yang mungkin atau mungkin bukan milik Anda, meskipun tentu saja Anda dapat menghindarinya dengan memeriksa subtree yang tepat dalam repo.

• Keamanan: seseorang yang mendapatkan akses ke server produksi Anda, sah atau tidak, juga mendapatkan akses ke repo Anda, mungkin juga produk lain, dan mungkin juga dengan akses tulis! Secara keseluruhan membuka server SVN internal Anda ke dunia luar adalah ide yang buruk. Repositori sumber Anda harus berada di belakang firewall perusahaan, titik.

• Akan ada skrip pembaruan, misalnya untuk memperbarui struktur DB, mengelola cronjobs, dll, jadi mengapa tidak memiliki skrip yang melakukan semuanya? - yaitu menarik rilis pra-paket terbaru, beralih ke mode pemeliharaan, memperbarui sumber, menjalankan skrip khusus rilis dll.

Sunting: untuk yang masih dalam skema SVN, jangan lupa ini di konfigurasi apache Anda:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

Saya telah menyiapkan server CI di tempat kerja saya yang secara otomatis membuat installer kami dengan asumsi bahwa unit test berhasil dilewati. Butuh sekitar satu hari kerja dan itu telah menyelamatkan saya lebih dari itu sejak saya mengaturnya.

Jika ada proses manual dalam mengonfigurasi situs web rilis / pemasang / produksi Anda, maka Anda akan selalu menghemat waktu dan perusahaan Anda. Ini sesuai untuk Anda karena dari pertanyaan Anda sepertinya ada langkah-langkah konfigurasi manual dalam proses pengaturan Anda.

Untuk referensi, lihat Joel sendiri berbicara tentang bagaimana proses membangun satu klik menyelamatkan Anda dalam jangka pendek hingga menengah.

Pastikan Anda memiliki kontrol checkin yang sesuai di SVN. Sebagai contoh, pertimbangkan ini -

• Fitur diperiksa untuk rilis
• Kode digunakan untuk pementasan, QA melakukan tugasnya
• Bug diperbaiki, putaran pengujian berikutnya (namun berhasil di tim Anda)
• Ditto untuk pre-prod
• Menyebarkan ke produksi

Jika seseorang secara tidak sengaja membuat checkin setelah tahap pra-prod, ada risiko melanggar sesuatu. Jika ini dikontrol - seperti tidak ada checkin diizinkan selama pra-prod kecuali untuk perbaikan bug - Saya tidak melihat risiko.

Pembaruan: Anda memiliki masalah menunggu untuk terjadi jika Anda tidak checkin file konfigurasi Anda. Saya benar-benar tidak dapat memberikan saran untuk ini selain "tolong lakukan, dan cepat!"

Sepertinya ok asalkan tidak ada apa-apa di luar repositori. Infact, saya percaya seseorang seharusnya tidak menginvestasikan waktu dalam alat penyebaran beberapa bulan pertama proyek. Karena akan ada terlalu banyak penggelaran, tidak cukup banyak pelanggan untuk diganggu tentang proses rilis resmi.

Tapi begitu proyek itu berumur sekitar satu tahun nilainya mempertimbangkan investasi dalam alat penyebaran. Alasannya sederhana

• Bisnis tumbuh sehingga Anda berencana untuk menyimpannya di lebih dari satu server
• Mungkin ada bug di lingkungan tertentu dan Anda tidak punya tempat untuk mereplikasi bug. Tidak ada cara mudah untuk mengaturnya tanpa proses tar-untar-forget_about_home_for_a_week.
• Seseorang mungkin akan merusak bangunan. Siapa yang merusak bangunan

Jika Anda ingin meyakinkan mereka, minta mereka untuk menyiapkan server lain untuk pengujian internal atau QA.