GNU/Linux >> Belajar Linux >  >> Linux

Siklus Hidup Rilis Perangkat Lunak di DevOps:Mengapa Menemukan Kembali Model?

Dalam artikel saya sebelumnya dan pertama dalam seri ini, saya mempresentasikan bentuk dan model baru DevOps dan menjelaskan komponen dan alur kerjanya yang penting.

Dalam artikel ini, saya akan mengeksplorasi pentingnya siklus rilis aplikasi dan peran penting yang dimainkannya dalam model DevOps kami.

Tetapi sebelum saya mulai, saya perlu mengingat secara singkat beberapa bagian penting dari artikel saya sebelumnya, khususnya SDLC dan juga melihat kembali fakta bahwa banyak dari kita di akademisi ilmu komputer mungkin secara tidak sengaja mengikuti selama beberapa dekade.

Saya tidak akan merinci langkah-langkahnya lagi, karena artikel sebelumnya telah ditautkan di sini. Tapi saya akan melihat diagram SDLC sekali lagi.

Signifikansi Siklus Hidup Rilis Perangkat Lunak di DevOps

Siklus Hidup Rilis Perangkat Lunak, atau singkatnya SRLC, adalah prosedur wajib yang dilakukan selama pengembangan aplikasi apa pun. Ini adalah kebutuhan penting karena perangkat lunak berkualitas memastikan DevOps berkualitas. Itu dapat dipastikan secara efektif hanya jika berbagai fasenya dikembangkan secara efisien.

Siklus Hidup Rilis Perangkat Lunak

Siklus Hidup Rilis Perangkat Lunak atau SRLC adalah urutan berbagai tahap di mana pengembangan perangkat lunak berkembang dari fase pra-alfa menjadi fase produksi. Ini adalah proses yang berkelanjutan karena perangkat lunak apa pun akan selalu memiliki versi yang diperbarui hingga dan kecuali jika mencapai akhir masa pakainya (EOL).

Nama dan praktik dapat bervariasi dari satu pengembang ke pengembang lainnya. Namun secara umum, ada lima fase penting yang terlibat:

  1. Pra-alfa :Fase pertama dalam rilis perangkat lunak yang hanya mencakup fungsionalitas utama dan kemungkinan besar memiliki jumlah bug maksimum. Ini hanya diuji oleh pengembang dan penguji.
  2. Alfa :Fase kedua dalam rilis perangkat lunak dianggap fitur lengkap dan masih mungkin memiliki bug tetapi jauh lebih sedikit daripada pra-alfa. Ini diuji oleh pengembang dan penguji. Namun, bergantung pada NDA yang beragam, NDA dapat tersedia untuk publik secara selektif atau di seluruh dunia.
  3. Beta :Fase ketiga terutama difokuskan pada perbaikan bug dan masalah yang ditemui di dua fase sebelumnya. Seperti pra-alfa, ketersediaan perangkat lunak beta juga didasarkan pada NDA.
  4. Kandidat Pelepasan :Versi kandidat rilis perangkat lunak adalah versi pra-rilis yang berpotensi menjadi produk stabil akhir. Dalam praktik umum, versi kandidat rilis tidak lagi menerima kode sumber baru untuk program. Perubahan pada kode sumber hanya dilakukan jika masih ditemukan kesalahan saat menjalani pengujian tingkat produksi.
  5. Rilis Produksi :Seperti yang sangat jelas, rilis produksi adalah produk akhir yang tersedia untuk masyarakat umum sebagai produk yang stabil.

Catatan :Konsep NDA tidak membawa banyak nilai di bidang Perangkat Lunak Sumber Terbuka karena modelnya yang transparan.

Berdasarkan model baru kami, SRLC sebenarnya bekerja dalam dua tahap:

1. Tahap Rilis Pengembangan di ADLC

Aplikasi menjadi versi pertama dalam tahap ini dan berkembang melalui sebagian besar fase rilis (disebutkan di atas) karena menjadi lebih matang dan layak. Bug berkurang secara bertahap dan efisiensi meningkat seiring berjalannya waktu.

2. Tahap Rilis Stabil di SDLC

Ini adalah tahap produksi SRLC di mana rilis pengembangan menjadi versi stabil pertama yang tersedia dan siap digunakan oleh klien dan pengguna.

Mengapa disebut "Siklus Hidup"?

Selama beberapa dekade, dalam bidang akademik Rekayasa Perangkat Lunak , kurikulum Ilmu Komputer di berbagai universitas telah menyebutkan model proses rilis perangkat lunak sebagai sebuah siklus. Namun diagram yang digambarkan cukup kontradiktif. Biasanya, ini dijelaskan dengan cara berikut:

Berdasarkan pengamatan sederhana, sangat jelas bahwa diagram di atas tidak menunjukkan sifat "seperti siklus" sama sekali. Berdasarkan model konvensional ini disebut siklus meskipun diagram tidak menunjukkan karakteristik seperti itu…tidak bisa disebut siklus… itu diagram alur.

Agar terlihat seperti siklus, fase produksi harus kembali ke fase pra-alfa dan itu tidak masuk akal, kecuali jika seluruh skenario ditinjau secara kritis sekali lagi:

Anda dapat dengan jelas melihat bahwa rilis stabil adalah tempat perangkat lunak telah mencapai potensi penuhnya dan mampu digunakan dalam produksi. Meskipun tidak terlihat dalam diagram, mengapa kemudian disebut sebagai "siklus hidup"?

Inilah alasannya

Ketika rilis produksi telah diadopsi oleh pengguna/klien, pengembang perangkat lunak masih melakukan perbaikan di dalamnya dengan menambahkan lebih banyak fitur, mengutak-atik yang sudah ada, memperbaiki bug dan gangguan keamanan saat dalam produksi dan perubahan lain yang diperlukan seiring waktu . Oleh karena itu, selalu ada versi pengembangan yang secara konsisten bekerja di belakang layar.

Betapapun kritisnya perangkat lunak yang diuji, ada kekurangan tertentu yang hanya akan terungkap dalam skenario dunia nyata, dan kekurangan ini diperbaiki dalam versi terbaru dari rilis produksi apa pun.

Mari kita pikirkan sejenak. Bisakah rilis produksi benar-benar disebut produk akhir jika perangkat lunak terus dikembangkan dalam bentuk versi yang diperbarui?

Bagaimana cara meninjau diagram dan skenarionya sebagai siklus nyata?

Untuk dapat memahami proses ini sebagai sebuah siklus, kita perlu meninjau kembali model SDLC baru kita yang dijelaskan sebelumnya:

Jika Anda ingin melihatnya hanya dengan perspektif rilis perangkat lunak, model SDLC dapat diubah menjadi SRLC:

Aplikasi perangkat lunak berkaitan dengan pengembangannya sendiri, sedangkan sistem perangkat lunak berkaitan dengan pengembangan aplikasi dan proses sistemik di mana ia digunakan dan dipelihara. Jika disederhanakan lebih lanjut, kita dapat membayangkannya kembali sebagai berikut:

Mari kita perbesar Rilis Pengembangan zona untuk melihat apa yang sebenarnya terjadi dan mendapatkan "Siklus Hidup" kami:

Di sini, Anda dapat mengamati bahwa empat fase penting pertama sekarang direpresentasikan sebagai bagian dari siklus yang sebenarnya. Setiap fase ini juga mengalami pengembangan aplikasi berdasarkan ADLC (diberi label dalam diagram sebagai ADLC) saat mereka melanjutkan ke fase berikutnya. Setelah pengembangan perangkat lunak keluar dari tahap kandidat rilis, ia menjalani pengembangan sistem berdasarkan SDLC(diberi label dalam diagram sebagai SDLC) untuk akhirnya menjadi rilis stabil yang akan aktif melalui penerapan produksi seperti lingkungan pengguna akhir dan klien.

Mengapa sekarang rilis stabil harus kembali ke status pra-alfa? Hanya untuk mewakili dirinya sebagai siklus hidup? Jelas tidak.

Rilis yang stabil harus menjalani kembali penyaringan tingkat pra-alfa untuk mempertahankan kualitas setinggi mungkin secara konsisten.

Karena produk telah dirilis sebagai versi stabil, debugging dan pengujian di bawah fase pra-alfa, alfa dan beta tidak memakan waktu lama. Jadi, Anda harus ingat bahwa setelah produk baru dirilis ke publik, produk tersebut dengan cepat mendekati tingkat penyaringan kandidat rilis setelah benar-benar diterapkan dan diaudit oleh setiap jenis pengguna.

Bug tingkat produksi waktu nyata tidak dapat dihindari dan bagaimanapun sifatnya, perlu untuk menilai ulang mereka dengan pendekatan pra-alfa. Hanya dengan demikian perangkat lunak berkualitas dapat dipastikan secara konsisten dengan kecepatan dan efisiensi optimal.

Oleh karena itu, model yang direvisi ini sekarang akhirnya dapat disebut sebagai siklus aktual dan bukan diagram alur konvensional yang mungkin telah diikuti banyak dari kita di komunitas pembangunan secara tidak sengaja selama beberapa dekade! Ini adalah proses berkelanjutan, itulah sebabnya disebut Rilis Perangkat Lunak "Siklus Hidup".

Jika ada saran, umpan balik, atau komentar tentang topik ini, beri tahu kami di bagian di bawah. Kami ingin melihat Anda terlibat dalam pendekatan yang begitu menarik. Nantikan artikel selanjutnya dalam seri ini :)


Linux
  1. Mengapa Server Memblokir IP Saya?

  2. Mengapa ~/.bash_profile Tidak Berfungsi?

  3. Mengapa Kernel Menjatuhkan Paket?

  1. Mengapa Garpu Mekanisme Pembuatan Proses Default?

  2. Mengapa Perintah Berikut Membunuh Sistem?

  3. Mengapa Saya Tidak Dapat Mengekspor Tampilan Linux?

  1. Mengapa programmer menyukai kemasan Linux

  2. Evolusi manajer paket

  3. Linux – Mengapa Kernel Tidak Dapat Menjalankan Init?