Baru-baru ini saya berdiskusi dengan rekan kerja tentang membuat versi aplikasi web.
Saya tidak berpikir Anda memerlukannya sama sekali, dan jika Anda hanya ingin cek kewarasan untuk mengonfirmasi bahwa rilis terbaru Anda tayang, saya pikir kencan (YYMMDD) mungkin cukup bagus.
Apakah saya kehilangan basis? Apakah saya melewatkan intinya? Haruskah saya menggunakan nomor versi aplikasi web
Jawaban:
Jika Anda menjual kembali aplikasi web yang sama ke banyak pelanggan, Anda harus membuatnya versi.
Jika itu adalah situs web yang hanya pernah dipasang di satu lokasi, maka kebutuhannya tidak terlalu buruk, tetapi kemungkinan besar tidak ada salahnya. Anda akan kurang rentan terhadap masalah zona waktu dan semacamnya juga. Mendiagnosis masalah di perpustakaan versi 1.0.2.25 jauh lebih baik daripada memburu pembangunan perpustakaan pada 3 November 2010 11:15
Jika Anda dapat mengotomatisasi nomor versi di DLL aplikasi Anda, tidak ada salahnya. Ini akan membantu Anda melacak versi.
Secara umum, aplikasi web hanya dirilis di satu lokasi tempat Anda hosting, jadi tidak sepenting aplikasi desktop. Ini dapat membantu dengan roll-backs, pelacakan bug (yaitu versi apa ini) dan melacak perbedaan antara server pengembang, staging, dan produksi, jika berlaku.
Saya akan melihat ke dalam mengotomatisasi itu - itu adalah jenis hal yang dapat Anda setup sekali dan menggunakannya jika / ketika Anda membutuhkannya.
Pengguna Anda tidak peduli dengan nomor versi karena mereka selalu memiliki rilis terbaru dan terhebat, tetapi Anda berhutang kepada diri sendiri (dan tim Anda) untuk mengetahui secara tepat versi apa yang sedang ditayangkan. Akhirnya sumber pengembangan Anda tidak sinkron dengan kode langsung dan kemudian Anda pasti harus tahu. Jadi beri label rilis Anda di pohon svn / git Anda dan tandai aplikasi web dengan tag itu.
Selain apa yang dikatakan orang lain, saya akan menambahkan bahwa versi juga penting dari perspektif pemasaran. Versi baru adalah sesuatu yang baru yang dapat dipasarkan ke pelanggan potensial atau yang sudah ada. Ini membuat pelanggan tahu ada sesuatu yang 'baru' dan melihat bahwa segala sesuatu bergerak maju. Ini menyediakan pengelompokan fitur baru yang bagus. Dan itu terlihat lebih profesional.
Saya mengatakan bahwa untuk apa pun kecuali aplikasi web yang sepele, Anda harus versi itu. Ada dua gagasan yang sedikit berbeda yang bekerja di sini:
Terlepas dari situasinya, saya percaya bahwa file harus memiliki nomor versi individu (atau revisi). Idealnya, ini akan ditangani secara otomatis oleh sistem kontrol versi Anda. Seperti yang telah dinyatakan oleh orang lain, lebih mudah untuk merujuk ke nomor versi file daripada tanggal dan waktu.
Jika Anda memiliki (atau mungkin memiliki) lebih dari satu instalasi aplikasi secara langsung, itu harus diversi secara keseluruhan. Ini juga merupakan praktik yang baik jika Anda memiliki lingkungan pengembang dan pengujian terpisah (seperti yang seharusnya). Setiap nomor versi aplikasi (atau rilis) mengacu pada kumpulan file individual pada nomor versi tertentu. Meskipun berurusan dengan semua ini adalah beban tambahan, lebih mudah untuk memeriksa rilis spesifik daripada file individual di nomor revisi tertentu.
Ini membuat saya berpikir tentang konsep linguistik. Dikatakan bahwa jika Anda tidak dapat mengekspresikan sesuatu dalam suatu bahasa, Anda tidak dapat memikirkannya (dalam bahasa itu). Saya memikirkan kata Jerman 'Schadenfreude.' Adalah jauh lebih mudah untuk memikirkan (dan berbicara) tentang gagasan "merasakan sukacita karena ketidakberuntungan orang lain" dengan merujuk pada kata itu, daripada definisinya. Itulah alasan mengapa kata itu mulai digunakan dalam bahasa Inggris.
Demikian pula, nomor versi memudahkan untuk berbicara (dan memikirkan) aplikasi Anda dan file-file di negara-negara tertentu. Jika Anda adalah tim satu orang, mengerjakan satu aplikasi, sepertinya tidak akan ada perbedaan besar. Namun, karena semakin rumit, lebih baik bagi Anda untuk memiliki label ini tersedia untuk digunakan.
Anda harus membuat versi aplikasi web Anda dengan build id dari server build Anda dan memasukkannya ke dalam semua laporan bug.
Ini akan memungkinkan Anda untuk kembali ke masa lalu jika Anda harus memperbaiki bug yang dilaporkan pada versi lama yang saat ini tidak ada dalam produksi.
Dari pertanyaan Anda, jelas bahwa Anda memikirkan aplikasi web sederhana
Hanya dapat diakses oleh GUI Web dan bukan oleh Web (-layanan) API . Jika Anda memiliki pengguna yang mengakses aplikasi menggunakan API, Anda perlu membuatnya versi. Jika Anda mengubah API, Anda memutuskan klien, jadi Anda perlu mempertahankan versi API yang berbeda secara bersamaan.
Hanya satu instance yang berjalan pada saat itu . Bahkan jika Anda hanya memiliki web guy, jika Anda memiliki lebih banyak instalasi, Anda perlu tahu pelanggan mana yang menjalankan versi mana.
Dengan down-time yang dapat diterima untuk meningkatkan versi langsung. Mungkin ada masalah besar yang merupakan basis data . Perubahan penting dengan versi yang lebih baru disertai dengan perubahan dalam struktur data yang mendasarinya. Jika Anda hanya memiliki satu versi yang berjalan pada saat itu, Anda mungkin harus mematikan versi yang lama, memutakhirkan database, dan mengaktifkan versi yang baru. Yang menghasilkan aplikasi down-time. Ini dapat diterima tergantung pada jumlah dan jenis pengguna.
Jika aplikasi web Anda terdiri dari beberapa modul, baik di klien maupun di server, setiap modul harus diversi. Dan setiap kombinasi versi modul pada klien dan server harus diberikan id unik, id yang harus ada di semua logging dan pesan kesalahan.
Dengan menggunakan konvensi itu, akan selalu memungkinkan untuk membuat ulang keadaan aplikasi web itu pada saat tertentu.
Menurut pendapat saya, karena webapps hari ini dibangun menggunakan bahasa dinamis di kedua sisi, server dan klien, seharusnya tidak ada alasan untuk memuat ulang aplikasi web yang diperbarui kecuali pengguna me-restart browser atau memuat ulang halaman secara manual.
Hanya bagian atau modul yang diperbarui di aplikasi web yang harus dimuat ulang tanpa memengaruhi keseluruhan kondisi aplikasi.
Mengapa Anda bertanya? Nah, dengan menegakkan itu, aplikasi web dengan desainnya akan menjadi lebih kuat, benar dan mungkin lebih mudah dirawat. Jika aplikasi web selalu membutuhkan pembaruan server / klien secara bersamaan, maka itu mungkin tidak dibangun dengan cara yang benar.
Ya, Anda harus versi itu! Dan harus ada tag di sistem kontrol revisi Anda (seperti subversi, git, lincah, dll.) Yang cocok dengan nomor versi.
Tag memungkinkan Anda untuk kembali dan membuat cabang. Sebagai contoh: versi produksi saat ini memiliki bug, tetapi Anda tidak dapat memperbaikinya karena kode pada mesin Anda tidak siap untuk membuka pintu. Jika Anda memiliki tag di RCS Anda, Anda bisa bercabang di tag itu dan memperbaiki bug dalam versi persis kode yang berjalan dalam produksi.
Secara pribadi saya pikir Anda harus versi, tetapi satu manfaat besar dari aplikasi web versi yang khusus untuk situs web adalah dapat membuat perubahan pada konten statis lebih mudah untuk dikelola.
Sebagai contoh, katakanlah Anda memiliki file mysite.css yang memiliki tanggal kedaluwarsa yang jauh di masa depan (yang biasanya ingin Anda lakukan agar di-cache di browser di setiap halaman). Jika Anda kemudian mengubah gaya dalam file itu, tidak seorang pun yang pernah mengunjungi situs Anda sebelumnya akan melihatnya kecuali mereka melakukan sesuatu untuk menghapus file itu dari cache mereka.
Jika Anda memversi situs Anda, Anda dapat mengubah semua referensi css di build Anda menjadi sesuatu seperti mysite.css? V = 1234 yang akan membuat Anda menyimpan tanggal kedaluwarsa masa depan yang jauh dan tidak khawatir tentang perubahan di masa depan seperti di build selanjutnya. akan menjadi mysite.css? v = 1235.
Ya kamu harus. Untuk alasan distribusi ditunjukkan di sini oleh jawaban lain.
Tapi saya mengerti, mengapa Anda mengajukan pertanyaan. Pendekatan aplikasi web didorong oleh biaya. Ini berlawanan dengan pendekatan shrinkwrap lama, di mana biaya termasuk media fisik, distribusi, instalasi, hardcopy dokumentasi, pelatihan dan dukungan teknis. Apa pun yang dapat dikecualikan, harus dikecualikan.
Untuk lebih jelasnya, saya berasumsi bahwa Anda berbicara tentang semacam versi yang terlihat oleh pengguna, dan tidak menyerah pada kontrol versi dalam pengembangan. (jika Anda pikir Anda tidak memerlukan kontrol versi dalam pengembangan, maka Anda salah, Anda perlu kontrol versi).
Untuk proyek dengan satu host, itu tidak sepenuhnya diperlukan, karena jika ada pertanyaan Anda selalu dapat melihat host dan mengkonfirmasi apa yang sebenarnya berjalan. Ini agak menyenangkan, karena mungkin berguna sekali atau dua kali. Ini benar-benar terserah Anda, apakah menurut Anda itu akan berguna atau tidak.
Untuk proyek multi-host, itu bukan benar-benar opsional. Host yang berbeda pada akhirnya akan berakhir dengan versi yang berbeda dan Anda harus dapat membedakannya di sisi pengguna.