Friday, December 4, 2020

Manajemen Versi Dan Rilis

MANAJEMEN VERSI DAN RILIS




Versi

merupakan bentuk perubahan baru bersifat signifikan dari bentuk sebelumnya. akan berbeda halnya dengan istilah Software Versioning (memberi versi perangkat lunak) yang berfokus pada proses penetapan nama atau nomor versi unik terhadap identitas perangkat lunak.

Rilis

pelepasan atau peluncuran produk perangkat lunak. Jika sebuah produk dirilis maka, produk itu sudah paten artinya telah melewati fase pengujian dan pengembangan lengkap.

Software Release Life Cycle

jumlah dari tahap pengembangan dan kematangan untuk perangkat lunak komputer: mulai dari pengembangan awal hingga rilis akhirnya, dan termasuk versi terbaru dari versi yang dirilis untuk membantu meningkatkan perangkat lunak atau memperbaiki bug perangkat lunak yang masih ada dalam perangkat lunak.

Proses Software Release Life Cycle:
Pre-Alpha
merujuk pada semua aktifitas pembuatan dan pengembangan software sebelum dilakukan testing, aktifitas ini bisa berupa analisa kebutuhan, desain perangkat lunak, pengembangan unit maupun pengujian unit software.

Alpha
Tahap pertama untuk melakukan pengujian pada software (penggunaan alpha berasal dari huruf pertama dalam sistem alfabet Yunani kuno yang diartikan sebagai angka 1). Pada tahap ini developer software biasanya melakukan pengujian terhadap software dengan menggunakan teknik bernama white box techniques. Tambahan validasi kemudian dilakukan dengan menggunakan teknik bernama black box or gray box techniques oleh tim pengujian yang lain. Perpindahan pada metode pengujian black box dalam sebuah organisasi ini disebut dengan alpha release. Software alpha bisa saja tidak stabil dan dapat menyebabkan error maupun kehilangan data, jarang sekali software pada tahap alpha tersedia secara bebas untuk publik, terkecuali digunakan untuk bonus pre-order.

Beta
Tahap pengembangan software yang mengikuti tahap alpha (penggunaan istilah beta berasal dari bahasa Yunani kuno yang diartikan sebagai angka 2). Tahap ini biasanya tahap dimana software telah memiliki fitur yang lengkap, beberapa organisasi menyebut tahap ini sebagai prototype atau technical preview. Fokus dari tahap beta adalah mengurangi dampak buruk pada pengguna, yang biasanya berupa pengujian penggunaan produk. Beta release biasanya merupakan tahap pertama sebuah perangkat lunak tersedia untuk pihak diluar pengembang software. Pengguna dari versi beta ini disebut beta tester, biasanya adalah pengguna atau calon pengguna dari produk yang ada, mau melakukan pengujian terhadap produk perangkat lunak tanpa bayaran dan biasanya menerima hasil akhir software secara cuma-cuma atau dengan pengurangan harga (untuk software berbayar). Beberapa pengembang software meluncurkan closed beta maupun open beta dimana closed beta version adalah produk yang diluncurkan untuk sekelompok orang atau grup sebagai pengguna penguji sedangkan open beta diluncurkan untuk komunitas pengguna secara umum maupun siapa saja yang tertarik. Pengguna kemudian melaporkan adanya kesalahan yang ditemukan maupun memberi saran untuk tambahan fitur yang seharusnya ada pada produk akhir 22/5/2013 5

Release Candidate
merujuk pada suatu versi perangkat lunak yang dilihat sebagai potensi sebuah produk akhir, yang kemudian akan diluncurkan jika tidak terdapat kesalahan fatal pada produk software yang ada. Pada tahap ini produk sudah lebih stabil dan semua fitur sudah didesain dan diuji melalui beberapa kali beta testing tanpa menunjukkan kesalahan. Beberapa developer software seperti Apple Inc. menggunakan istilah ‘Golden Master’ untuk mengindikasikan versi RC yang dimilikinya. Beberapa developer menggunakan istilah Gamma dan Delta untuk mengindikasikan versi yang sudah komplit tapi masih butuh beberapa pengujian, Omega atau Zenith untuk mengindikasikan versi pengujian akhir yang dipercaya sudah lebih bebas kesalahan dan siap untuk diproduksi.

Release To Manufacturing
disebut juga Going Gold digunakan untuk software yang siap untuk dikirimkan maupun digunakan oleh pengguna. Istilah ini biasanya digunakan untuk software yang digunakan untuk produksi masal dimana software dijual sebagai bagian dari kelengkapan hardware komputer atau distribusi masal retail (berkebalikan dengan software yang khusus diproduksi untuk proyek komersial atau distribusi terbatas). RTM biasanya merupakan tahap sebelum software disediakan untuk umum (GA).

General Availability
titik dimana semua hal yang diperlukan untuk kegiatan komersialisasi produk telah dilakukan dan software sudah siap untuk disediakan pada pasar atau publik baik melalui web atau media fisik. Istilah lain yang memiliki arti yang hampir sama dengan GA adalah First Customer Shipment (FCS), istilah ini digunakan oleh beberapa perusahaan seperti Sun Microsystem dan Cisco untuk mendeskripsikan software yang telah dikirimkan untuk mendapatkan pendapatan. Beberapa versi mungkin di klasifikasikan sebagai Long Term Support (LTS) yang disertai dengan kemampuan untuk diupgrade ke versi LTS selanjutnya dan akan terus didukung, update ataupun ditambah patch untuk waktu yang panjang dibandingkan versi non-LTS. 29/5/2013 9  

Support Release
dalam sistem operasi Windows disebut dengan Service Pack tidak selalu ada dalam sebuah daur hidup perangkat lunak. Biasa disebut juga dengan Update Patch, paket ini berisi koleksi update, perbaikan maupun penambahan fitur dalam sebuah paket yang dapat diinstal. END OF LIFE Tahap ini adalah tahap dimana sebuah software sudah tidak lagi diproduksi, dijual maupun didukung dengan support release. 10       

Semantic Versioning (SemVer) 
Jadi apa itu Semantic Version? Simplenya Semantic Version ini adalah sistem penomoran versi sebuah produk/software. Berfungsi untuk membedakan satu versi dengan versi lainnya.

Dalam SemVer, ada 3 istilah dan melakukan versioning: Major, minor, patch. Gambarannya adalah seperti ini:

contohnya: 2.33.7

  • 2 adalah versi major nya
  • 33 adalah versi minor nya
  • 7 adalah versi patch nya

Kita akan bahas lanjut seputar apa itu major, minor, patch dibawah.

Major version

Versi major adalah tentang perubahan yang terjadi terhadap public API. Bila versi major tersebut bernilai 1, berarti software tersebut baru dirilis ke publik. Ya, jika kamu baru pertama kali merilis software/library kamu ke publik, dengan catatan sudah "stabil", maka seharusnya kamu menggunakan nilai 1 untuk versi major nya.

Kondisi kapan versi major harus ditambah adalah ketika kamu melakukan perubahan terhadap public API yang mana perubahan tersebut sudah tidak mendukung versi sebelumnya.

Kita ambil contoh ketika React merilis versi 16. Apa saja perubahan yang terjadi?

  1. Behavior dalam scheduling dan lifecycle. Salah duanya adalah menggunakan "Fiber" dalam reconciliation dari yang sebelumnya menggunakan "Stack", dan memanggil setState di methods render akan menyebabkan perubahan dari yang sebelumnya tidak.
  2. Perubahan struktur direktori. Dari yang sebelumnya hanya memisahkan antara versi asli dan versi "minified" nya, sekarang ditambah: Versi production dan development meskipun masih tetap ada versi "minified" ataupun aslinya.

Yang artinya, perubahan yang terjadi dari versi major terbaru "berpengaruh" terhadap "behavior" dari versi sebelumnya. Seharusnya, versi major ini jangan cepat berubah. Atau users akan kabur karena sering kali terjadi perubahan yang membuat users harus "mempelajari lagi".

Di level aplikasi, mungkin bumping major version dilakukan ketika user seharusnya tidak bisa menikmati fitur sebelumnya bila memang menggunakan SemVer. Misal, dari yang sebelumnya (v1.x.x) pembayaran bisa menggunakan kartu kredit, di versi sekarang (v2.x.x) tidak bisa karena blablabla.

Minor Version

Jika major version adalah tentang perubahan yang menyebabkan dampak terhadap behavior sebelumnya, di minor version tidak. Kita ambil contoh React Hooks, di versi 16.8.x. React Hooks adalah tentang membuat component dengan gaya fungsional, namun tetap stateful.

Sebelumnya untuk membuat component yang stateful, kita harus menggunakan class-based component. Tidak sedikit masalah yang dihadapi di class-based component: boilerplate, this binding, constructor, dsb. Dengan React hooks, kita bisa menyelesaikan masalah tersebut. Karena boilerplate-free, automatic this bindung, dan zero constructor. Because it just a function!

Hooks tidak mengubah cara kita membuat component, melainkan "menambah". Ya, minor version adalah tentang "fitur baru". Asiknya, upgrade minor version tidak akan menyebabkan dampak yang terjadi terhadap kondisi yang sudah ada.

Aman untuk diupgrade (sebagai users), dan aman untuk di rilis (sebagai owner).

Juga, bila terjadi "deprecated" terhadap public API, maka minor version harus ditambah nilainya. Deprecated adalah kondisi dimana API tersebut akan "dihilangkan" dan users harus menggantinya ke API terbaru sebelum melakukan upgrade ke major version terbaru. Bila version minor ditambah, maka versi patch harus di reset ke 0.

Patch Version

Di versi ini adalah tentang fix bug yang tidak menyebabkan perubahan terhadap public API. Karena fix bug biasanya hanya terkait terhadap kode internal, bukan public API yang digunakan oleh users.

Biasanya, versi patch di version ditambah bila terjadi bug yang sangat krusial. Bila perubahan tersebut tidak terlalu krusial, alias hanya berdampak "kecil" terhadap public API, seperti fix typo; Enhancement in performance dsb, rilis tersebut dilakukan di versi minor. Alias, digabung dan dianggap sebagai "fitur".

Namun bila bug seperti memory leak, seputar security dsb, maka harus melakukan bumping version patch dengan catatan tidak merubah behavior yang ada di public API.

Demo sederhana

Kita membuat library untuk berinteraksi dengan AWS S3. Karena belum stabil, kita rilis kode tersebut dengan versi 0.1.0 dengan catatan kode tersebut sudah bisa digunakan untuk melakukan proses upload dan membaca file dari S3.

Lalu kita menambah fitur baru, delete file. Kita tambah versi minornya, yang berarti menjadi 0.2.0. User yang sudah menggunakan kode kamu, bisa melakukan upgrade version terhadap library kamu untuk bisa menikmati fitur delete tanpa harus meragukan kompatibilitas terhadap kode yang ada sebelumnya yang bergantung dengan library kamu.

Lalu kamu menemukan bug dan mem-fix nya. Memory leak, proses tetap berjalan meskipun user sudah membatalkan proses tersebut yang menyebabkan library tetap mengupload namun konten nya kosong. Maka kamu harus melakukan bump version patch, yang berarti menjadi 0.2.1.

Lalu kamu membuat fitur baru: Rename file yang sudah ada. Selain itu, kamu juga melakukan fix terhadap bug-bug kecil seperti typo yang mengganggu. Dan juga, kamu melakukan beberapa improvement. Misal, bila user membaca file yang sama dalam 10 detik, maka library akan memberikan versi cache nya daripada harus me-request terus-menerus ke file yang sama dalam 10 detik oleh user yang sama.

Maka kamu melakukan bumping version terhadap versi minor, dan me-reset versi patch nya, yakni menjadi 0.3.0.

Ketika kita sudah merasa bahwa library ini sudah stabil untuk digunakan, kita bisa merilis fitur major nya yang berarti versi 1.0.0 dengan fitur-fitur yang sudah dijelaskan di minor version (namun bukan yang seputar patch nya).

Lalu perubahan terjadi, sekarang oktober 2019 dan AWS sudah tidak akan mendukung S3 per-desember 2019 nanti. Sebagai gantinya, AWS merilis S4 (Super Simple Storage Service) yang mana hampir sama dengan S3 namun menggunakan protokol http3 untuk proses read nya dan menggunakan protokol TUS untuk uploadnya.

Maka kita harus melakukan bumping version versi minor, bahwasannya API uploadFile akan deprecated, sebagai gantinya gunakan updateFile namun tetap di versi tersebut method uploadFile masih berjalan. Yang berarti, versi sekarang harus ditambah minor nya menjadi 1.1.0.

Lalu sekarang 10 desember, dan 20 desember AWS sudah tidak mendukung AWS S3 lagi. Maka kamu merilis versi baru library kamu yang berarti menjadi versi 2.0.0 dengan catatan method uploadFile sudah tidak bisa digunakan lagi dan menjadi updateFile sebagai gantinya.


Referensi:

0 comments:

Post a Comment