Berkembang di server produksi

Hari ini saya dimarahi karena mengembangkan aplikasi pada server produksi. Kutipan, " mengembangkan pada server produksi tidak dapat diterima - selamanya! "

Inilah situasinya.

1. Saya membuat contoh pengembangan: http://example.com:3000
2. Contoh produksi adalah: http://example.com
3. Saya menyelesaikan semua pekerjaan pengembangan saya http://example.com:3000dan ketika klien puas dengan perubahannya, saya memindahkannya ke http://example.com.

Aplikasi yang saya gunakan adalah aplikasi Ruby on Rails yang lama , dan saya harus mengatakan bahwa pada awalnya, saya mencoba untuk mengatur lingkungan pengembangan secara lokal, tetapi saya tidak pernah bisa menjalankannya. Setelah mencoba sebentar, saya menyerah dan memutuskan untuk mengembangkan server produksi.

Lagi-lagi, apakah saya idiot? Mungkin begitu, tapi saya sudah melakukan pengembangan web selama beberapa tahun sekarang, dan saya belum pernah mengalami situasi seperti ini. Siapa yang benar dan mengapa?

Saya dulu mengembangkan di server produksi. Ini dapat bekerja dengan baik, tetapi tidak disarankan karena setidaknya dua alasan:

1. Kode pengembangan dapat menyebabkan loop tak terbatas, kebocoran memori, atau masalah lain yang mengunci CPU, memakan semua memori, atau memengaruhi server dengan cara yang akan memengaruhi kode produksi Anda.
2. Jika Anda perlu membuat perubahan pada komponen lingkungan server sebagai bagian dari pekerjaan pengembangan Anda, seperti versi Ruby atau MySQL atau apa pun, Anda akan terikat.

Seperti yang dinyatakan orang lain, pengkodean pada lingkungan PROD memperlihatkan pengguna Anda ke bug Anda. Sekalipun Anda telah memulai contoh berbeda, Anda masih memiliki sumber daya perangkat keras bersama dan masih dapat mengakses file dan basis data produksi. Dan seperti yang ditunjukkan beberapa komentar, jika instance Dev Anda diretas (misalnya, karena Anda lupa menghapusnya dan seseorang kemudian menemukan exploit keamanan besar-besaran di Rails), kini Anda memiliki mesin yang dapat diakses publik dengan akting aplikasi Anda sebagai gerbang masuk. Yang akan ... disayangkan.

Bisnis yang berbeda memiliki respons yang berbeda untuk ini, tetapi secara umum dapat dipecah seperti ini:

• Apakah terjadi kesalahan?
• Berapa lama untuk mengembalikan perubahan (saya terutama bekerja di C ++, jadi memutar kembali biner bisa memakan waktu lebih lama secara signifikan daripada di Ruby, terutama ketika Anda telah "kehilangan" biner lama dan harus mengkompilasi ulang)
• Apa efek dari perubahan (panduan kasar: mengacaukan data yang tersimpan adalah begitu jauh lebih buruk daripada tidak menyimpan atau menampilkan data, yang pada gilirannya lebih buruk daripada tidak menampilkan halaman sama sekali)
• Jika Anda mengacau lalu keluar, apakah ada yang tahu apa yang telah Anda lakukan?
• Apakah ada opsi penyebaran lain yang akan mencegah / meminimalkan / mendeteksi gangguan sebelum dampak?

Ini memberi Anda perhitungan akhir:

• Berapa banyak kekacauan yang dapat dicegah sepenuhnya ini akan merugikan bisnis?

Sekarang ini, apalagi nilai keseluruhan struktur manajemen Anda bagi orang yang membuat keputusan anggaran. Karena itu berteriak.

Jika Anda mengerjakan halaman "Tentang Kami" internal perusahaan dan ketikkan nama Anda sendiri untuk menjadi L. "Seperti Tuhan" Thomas, masalah nama panggilan yang memalukan; jika Anda bekerja pada aplikasi pembelian bisnis-kritis, dan berakhir tanpa sengaja men-debug data kartu kredit ke beranda ... masalah gugatan. Di antara hal-hal ekstrem itu terdapat segalanya, mulai dari kesalahan pengisian, melumpuhkan produktivitas, dan semua hal lain yang dapat mengusir pelanggan.

Alasan untuk tidak mengizinkannya bahkan untuk halaman "Tentang Kami" adalah karena pengkodean langsung dalam produksi membuat ketagihan . Anda mulai dengan hanya melakukannya untuk anak di bawah umur, tetapi seiring berjalannya waktu, itu jauh lebih cepat untuk tidak perlu membuat DEV env hingga awal.

Selain itu, ukuran bisnis dapat memiliki efek yang besar. Dalam tim dua orang, ketika ada sesuatu yang berubah, Anda membungkuk di atas bahu Anda dan pergi "Oi, jackass, kembalikan". Dalam sebuah perusahaan 300 orang, Anda harus mulai khawatir tentang apakah itu ketidakmampuan atau kedengkian, manajer dapat bertanggung jawab atas hal-hal yang tidak dapat mereka kendalikan, dll.

Pada akhirnya, jika Anda mengikuti prosedur dan gagal, mereka memeriksa apa yang salah dengan prosedur tersebut. Jika Anda mengacaukan prosedur dan mengacaukannya, sekarang tanggung jawab Anda sendiri, bahkan jika kesalahannya sedikit tersebar. Apakah Anda ingin melempar dadu itu terserah Anda.

Saya memang mencoba membuat lingkungan pengembangan secara lokal, tetapi saya tidak pernah bisa menjalankannya. Setelah mencoba sebentar, saya menyerah dan memutuskan untuk mengembangkan server produksi.

Saya mendukung pernyataan untuk MENGHINDARI pengembangan pada server produksi. Anda hanya dapat dibenarkan untuk melakukan di bawah GUN, jika itu adalah kesalahan ketik dalam file konfigurasi dan bersikeras oleh manajer Anda.

WHY NOT?- Karena, sangat beresiko dan rentan menjadi kebiasaan di kemudian hari yang akan membuat Anda marah. Karena, kesalahan / kegagalan produksi yang fatal dapat menyebabkan Anda dipecat dari pekerjaan Anda.

Biarkan saya mengulanginya lagi, meskipun jika Anda diminta untuk melakukan koreksi kesalahan ketik di productionserver, pertama - tama aktifkan Staging. atau dengan kata lain menguji perubahan Anda, mengujinya, dan kembali mengujinya sebelum melakukan produksi.

Ini adalah sesuatu yang sering terjadi di tempat-tempat di mana budaya "melakukannya dengan cepat dan kotor " tampaknya menjadi norma.

Sunting: Berkembang pada server produksi, sebagai lingkungan yang terpisah juga TIDAK dapat diterima . Setiap masalah yang disebabkan dalam pekerjaan Anda mungkin hanya menurunkan server produksi, dan mempengaruhi kinerja aplikasi produksi . Sebagai contoh, saya ingat suatu kasus ketika ada lubang keamanan, ketika rekan kerja saya sebelumnya mencoba menggunakan server produksi WinServer 2003 untuk tujuan pengembangan.

Ini benar-benar masalah protokol. Secara umum, ini bukan sesuatu yang ingin Anda lakukan. Anda ingin meninggalkan mesin produksi sendiri. Mereka mungkin berisi data sensitif, dan Anda tidak ingin kompromi kinerja atau stabilitas situs produksi dengan kode siap non-produksi.

Yang mengatakan, ada saat-saat di mana hal ini biasa dilakukan. Jika Anda berada dalam posisi di mana Anda memompa keluar brouchureware lalu lintas rendah atau situs CMS sederhana, ini kemungkinan akan kurang menjadi masalah. Tetapi jika Anda mengerjakan sesuatu dengan data sensitif atau proses "kritis bisnis", Anda benar-benar tidak perlu mengambil risiko memiliki kode pengembangan pada mesin yang sama.

Alasan penting lainnya untuk tidak mengembangkan secara langsung dalam produksi adalah bahwa contoh pengembangan biasanya akan menghasilkan dan menunjukkan kesalahan verbose dan jejak tumpukan. Anda tidak pernah ingin mengekspos itu kepada pengguna.

Ya, Anda bisa mencatatnya alih-alih menunjukkannya kepada klien, tetapi itu membuat debugging menjadi jauh lebih lucu daripada yang sudah ada.

Ditambahkan Mengatasi masalah sisi Anda mengalami masalah dengan instance pengembangan Anda: Saya telah sangat sukses menggunakan VM berbasis VirtualBox yang menduplikasi lingkungan produksi kami (tidak termasuk perangkat keras, tentu saja) dengan Server Ubuntu .

Saya cukup heran belum ada yang menyebutkan alasan paling penting, mengapa itu dilarang untuk dikembangkan di server produksi:

Jangan main-main dengan data produksi, yang bisa terjadi oh begitu mudah!

Kesalahan kecil di satu tempat menyebabkan masalah besar dalam perhitungan lain dan kemudian, pada hari berikutnya, semua data adalah sampah dan pelanggan marah. Ini jauh, jauh lebih buruk daripada bug di UI atau sedikit crash di sana-sini.

Untuk sebagian besar aplikasi, nilainya terletak pada data dan bukan pada rutinitas.

Saya selalu mencoba dan bertanya kepada pengembang lain apa prosedurnya untuk perusahaan tertentu. Secara umum ya, Anda harus selalu:

1. Bangun secara lokal.
2. Dorong ke beberapa jenis kotak yang meniru produksi sebanyak mungkin untuk melihat apakah itu bagus di sana.
3. Mungkin mendorongnya ke QA atau contoh sertifikasi untuk diteruskan ke klien / tim QA untuk meninjau perubahan.
4. Dorong ke produksi.

Anda dapat menggunakan resep Capistrano yang dipasangkan dengan GitHub untuk menangani semua hal ini untuk Anda. Jika Anda harus melakukan ini dengan tangan setiap waktu, itu bisa menjadi cepat tua.

Masalah lain dengan pengembangan pada prod adalah bahwa, kadang-kadang, hal-hal ini terlewatkan dalam kontrol sumber dan rilis di masa depan dapat membatalkan perubahan perbaikan cepat Anda.

Jika Anda berada di perusahaan publik di AS, Anda seharusnya tidak memiliki akses ke produk untuk alasan pengaturan. Secara umum, di perusahaan mana pun pengembang tidak boleh memiliki akses prod (untuk resons yang disebutkan dalam semua jawaban serta alasan hukum yang mungkin), sehingga manajer Anda juga salah karena memberi Anda hak ke server itu.

Aturan yang menggunakan "selalu" atau "tidak pernah" biasanya tidak jelas. Akan ada kasus tepi di mana melanggar praktik terbaik akan dibenarkan. Saran yang jauh lebih baik adalah "Jangan menyentuh server produksi kecuali Anda memiliki alasan yang sangat bagus"

Dalam karir saya, saya hanya menemukan dua alasan untuk mengubah kode di server produksi:

1. Bug atau perilaku yang hanya terjadi di sana dan tidak dapat direproduksi di lingkungan pengembangan. Ini jarang terjadi tetapi bisa sangat menjengkelkan dan sulit ditemukan.

2. Secara langsung memperbaiki bug penting yang Anda tidak sanggup menunggu untuk melewati proses penyebaran normal jika dibutuhkan lebih dari beberapa menit. Setelah ini diselesaikan dengan manajemen. Jika Anda beruntung, Anda harus memiliki hanya sedikit dari itu untuk seluruh karir Anda.

Keduanya sebaiknya diserahkan kepada pengembang senior yang mengenal sistem secara intim.