Berkembang di server produksi


35

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?


46
Satu-satunya retort yang valid adalah "memiliki server produksi yang tidak dapat direproduksi dalam pengembangan tidak dapat diterima - selamanya."
Blrfl

49
Bagi saya, masalah sebenarnya di sini adalah bahwa Anda memiliki sistem produksi di mana Anda tidak tahu apa yang sedang berjalan atau bagaimana itu dikonfigurasi. Apa yang akan Anda lakukan jika mesin produksi Anda mogok, kehilangan semua datanya? Jika Anda tidak dapat mengatur lingkungan pengembangan yang tepat sekarang, apa yang akan Anda lakukan saat itu satu-satunya pilihan Anda?
Greg Hewgill

@GregHewgill, ya itu poin yang bagus
luk3thomas

25
Greg benar, jika Anda tidak cukup tentang aplikasi untuk mereproduksi lingkungan pada mesin pengembangan, maka Anda tidak hanya harus tidak mengembangkan dan menguji pada mesin produksi, Anda bahkan tidak boleh diizinkan akses untuk menyebar ke mesin itu. Anda jelas-jelas salah, tetapi saya akan berteriak pada atasan Anda karena memberi Anda akses di tempat pertama sebelum Anda sepenuhnya memahami apa yang Anda lakukan.
maple_shaft

3
Jika Anda tidak dapat mengatur lingkungan pengembangan lokal, Anda tidak boleh berkembang sama sekali.
Jas

Jawaban:


58

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.

1
Ya, itu poin yang bagus. Semakin aku memikirkannya, kalian sepenuhnya benar.
luk3thomas

6
Ada masalah ketiga: keamanan. Bagaimana jika seseorang portcans server produksi dan menemukan aplikasi (pengembangan) Anda - dan akibatnya kompromi aplikasi produksi? Sekali lagi, sementara ini bukan skenario yang mungkin cukup banyak yang dikatakan semua orang setelah server atau sistem dikompromikan.
Marco

Masalah loop tak terbatas yang terkenal ...
Mansuro

3
@ Marco Sebenarnya itu sangat mungkin jika server dapat diakses oleh publik. Server pengembangan biasanya memiliki keamanan yang sangat buruk (karena kenyamanan seperti debugger dan jejak tumpukan adalah kewajiban ketika datang ke keamanan). Jika penyerang dapat meningkatkan hak istimewa dengan mengeksploitasi server dev, ia dapat sepenuhnya memiliki aplikasi produksi.
Mark E. Haase

29

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.


Ini adalah ringkasan yang baik dari jebakan dengan pengembangan di lingkungan produksi , tetapi pertanyaannya adalah tentang pengembangan di lingkungan terpisah pada perangkat keras produksi .
Carson63000

@ Carson63000 Setuju, dan jawaban Yakub pasti lebih baik di sisi itu. Saya telah sedikit mengubah milik saya.
deworde

13

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 adalah ringkasan yang baik dari jebakan dengan pengembangan di lingkungan produksi , tetapi pertanyaannya adalah tentang pengembangan di lingkungan terpisah pada perangkat keras produksi .
Carson63000

Terima kasih, saya telah menambahkan suntingan yang membahas masalah melakukannya.
EL Yusubov

10

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.


Ok terima kasih. Bisakah kode pengembangan membuat mesin tidak stabil? Saya sedang mengerjakan aplikasi rel tua. Sepertinya saya (orang yang naif) bahwa kode pengembangan http://example.com:3000tidak akan mempengaruhi http://example.com.
luk3thomas

2
@ luk3thomas: baik, tentu, seharusnya tidak. Bagaimana jika ada bug di server web atau kerangka Rails, yang membuat server crash? Bagaimana jika, seperti yang disarankan Jacob Terry dalam jawabannya, loop tak terbatas atau kebocoran memori dalam kode dev Anda menyedot semua sumber daya di server produksi dan membahayakan kinerja situs langsung?
Carson63000

1
Terkadang itu suatu persyaratan. Seperti toko yang melisensikan perangkat lunak mahal dan tidak memiliki anggaran untuk salinan kedua hanya untuk pekerjaan dev.
Brian Knoblauch

8

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 .


3
mencatat, terima kasih atas sarannya w / VirtualBox
luk3thomas

1
@ luk3thomas Ini juga gratis! Ada ton dari tutorial online untuk VirtualBox + Ubuntu (mungkin salah satu yang paling kombinasi virtualisasi umum).
msanford

8

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.


1
Anda belajar ini dengan cukup cepat setelah Anda mengacaukan data produksi. Saya kira dia tidak punya DB.
Rocklan

8

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.


rel 2.3.11, saya mungkin akan berakhir melakukan sesuatu seperti itu
luk3thomas

1

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.


0

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.


Jika Anda memiliki bug yang hanya terjadi pada lingkungan produksi, lingkungan pengembangan Anda tidak cukup dekat dengan lingkungan produksi. Anda harus DI SANGAT SANGAT SETIAP memiliki lingkungan pementasan dengan konfigurasi yang sama persis dengan lingkungan produksi, hingga ke pengaturan OS yang tepat, pemrosesan perangkat keras, dan perangkat lunak yang diinstal.
Nzall
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.