Standar penamaan lingkungan dalam pengembangan perangkat lunak?


15

Proyek saya saat ini menderita masalah penamaan lingkungan. Orang yang berbeda memiliki asumsi yang berbeda mengenai lingkungan apa yang harus dinamai atau apa yang ditetapkan namanya, dan itu menyebabkan kebingungan ketika mendiskusikannya. Saya telah melakukan sedikit riset dan saya belum menemukan standar apa pun di luar sana.

Istilah-istilah tersebut termasuk "Lokal", "Pasir", "Dev", "Tes", "Pengguna", "QA", "Staging" dan "Prod" (ditambah beberapa lagi yang ditanyakan oleh orang yang berbeda)

Saya tidak mencari hanya pendapat, meskipun jika ada satu di luar sana yang "semua orang" akan saya ambil - saya mencoba untuk menemukan definisi yang dikembangkan oleh semacam otoritas, bahkan jika itu tidak resmi.

Inilah lingkungan yang saat ini kami gunakan:

  1. Lingkungan pada PC pengembang
  2. Lingkungan Bersama di mana pengembang langsung mengunggah kode untuk swa-uji
  3. Lingkungan Bersama tempat standar dan fungsionalitas diuji oleh orang-orang QA
  4. Lingkungan Bersama tempat kode selesai dan QA diperiksa oleh pemohon proyek
  5. Lingkungan yang mencerminkan lingkungan terakhir sebagai pemeriksaan terakhir dan untuk mempersiapkan penyebaran
  6. Lingkungan Akhir tempat kode digunakan

Saya tahu apa yang saya sebut mereka, tetapi apakah ada semacam standar dalam hal ini? Terima kasih sebelumnya.


Terima kasih. Saya tidak menyadari SE itu. Saya tahu itu bukan milik ServerFault atau SuperUser, tetapi saya belum pernah mendengar tentang programmer.

Saya menandainya untuk pindah, jadi idealnya harus mencari jalan ke situs yang tepat.
Ricardo Altamirano

Tergantung pada ruang lingkup proyek, Anda mungkin memiliki lebih sedikit atau lebih banyak lingkungan.
Yusubov

Jawaban:


11

Tidak hanya bukan standar tetap, tetapi sebenarnya tidak ada pola baku. Ketergantungan antara apa yang Anda bangun dan skala di mana Anda mampu mereplikasinya akan menentukan seperti apa bentuknya dari satu jenis proyek ke jenis lainnya.

Saya telah bekerja dengan sedikitnya satu lingkungan dan sebanyak 13.

Dalam urutan yang Anda gambarkan, saya biasanya akan melihat mereka menamakan mereka sesuatu seperti

  1. lokal atau dev jika Anda tidak menggunakan dev pada langkah berikutnya
  2. dev atau integrasi jika ini adalah penyebaran pertama setelah penggabungan
  3. tes atau QA
  4. uat atau penerimaan atau QA jika Anda tidak menggunakan QA pada langkah 3
  5. pre-prod, staging atau kinerja jika itu merupakan langkah kinerja untuk sign-off akhir
  6. melecut

Saran saya adalah menyetujui nama, tujuan dan kriteria untuk masuk dan meninggalkan masing-masing untuk setiap produk atau per proyek maka ketika Anda menyadari bahwa Anda memerlukan lingkungan ke-7 atau hanya perlu 5 dalam satu kasus untuk alasan lain di masa depan, diskusikan lagi dengan tim.

Jika Anda memiliki anggota tim yang terbiasa dengan semantik nama, Anda selalu dapat menyebutkan nama dan menyebutnya sebagai prod minus enam hingga prod minus satu dengan satu manajer yang hanya menolak untuk membiarkan staf QA-nya menguji lingkungan. yang tidak bernama "QA"

Jika Anda mencari untuk menamai server sendiri, saya biasanya menyarankan penamaan mereka oleh siapa otoritas mereka di bawah. Biasanya ini berlangsung seperti:

  • mesin dev dapat dimanipulasi oleh pengembang
  • Mesin QA tidak dapat dimanipulasi oleh pengembang tetapi juga tidak dimonitor oleh dukungan produksi
  • mesin prod adalah bisnis dukungan prod

kebanyakan orang akhirnya menggunakan nama-nama semacam itu sebagai awalan atau sufiks sehingga Anda memiliki rantai seperti "devsqllweb" "qasqlweb" "prodsqlweb" atau sesuatu seperti itu.


Anda pada dasarnya menyatakan kesimpulan saya datang ke. Saya berharap ada semacam standar di luar sana sehingga saya bisa menyelesaikan situasi tanpa menetapkan standar dasarnya sewenang-wenang. Masalah saya terletak pada struktur lingkungan "utama" kami yang memiliki lingkungan lebih sedikit daripada proyek yang sedang saya kerjakan ini (jadi saya tidak bisa hanya mencerminkan apa yang kami gunakan secara normal) - dan proyek saya memiliki banyak konsultan dari berbagai tempat, yang berarti tidak ada seseorang memiliki standar yang sama. Saya akan membiarkan pertanyaan ini terbuka selama beberapa jam lagi untuk melihat apakah ada orang lain yang akan ikut, tetapi ini adalah jawaban yang saya takuti.
Marcus_33

Saya telah melihat standar untuk ini. Mereka adalah jenis standar yang baik opini atau sangat spesifik untuk situasi tertentu sayangnya.
Bill

2

Saya kira berasal dari industri yang lebih terstruktur dan teregulasi, pilihan untuk menamai server adalah kemewahan yang tidak saya miliki. Server kami dinamai sesuai dengan kebijakan TI perusahaan kami - jadi nama host sebenarnya dari mesin bukanlah sesuatu yang dapat kami kontrol.

Apa yang telah kami lakukan adalah pergi dengan nama dan alias DNS. Aturannya adalah huruf pertama mengidentifikasi peran umum server dalam proses pengembangan (zona)

  • p = produksi
  • d = pengembangan
  • s = pementasan
  • t = pengujian

Kemudian kami memiliki nama maksimal tiga huruf untuk mengidentifikasi peran mesin

  • app = aplikasi
  • db = database
  • web = frontend / web
  • kas = caching

Diikuti oleh angka jika ada beberapa mesin di zona itu. Kami menerbitkan ini di server dokumentasi internal dan menyediakannya sebagai bagian dari dokumentasi baru untuk proyek dan selama tahap bootstrap.

Ini untuk server yang merupakan bagian dari proses pengembangan. Untuk mesin pendukung kami memiliki kebijakan yang lebih liberal; dan ketika kami harus menyediakan server bantu baru kami meminta tim pengembangan untuk membuat nama yang mereka sukai.

Ini mengarah pada beberapa yang menarik, dua favorit saya adalah kotak cerberus (proxy internal) dan hades (server dokumentasi / intranet)

Saya yakin ini bukan praktik terbaik, tapi ini yang kami gunakan dan ini bekerja untuk kami.


1

Tidak ada definisi pasti. Ada beberapa yang digunakan oleh praktik umum (yang telah Anda daftarkan). Jika Anda ingin memberi setiap lingkungan nama karakter dalam Toy Story, Anda dapat (tidak akan merekomendasikannya).

Apa yang akan saya lakukan adalah membuat glosarium untuk perusahaan, di mana kami akan memberikan nama yang ingin kami gunakan.

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.