Aspek Manajemen Rilis manakah yang membantu menjelaskan perbedaan antara Air Terjun dan Agile?

Ketika menjelaskan DevOps kepada seseorang, kebetulan muncul pertanyaan seperti:

Apa perbedaan Release Management dengan metodologi Agile dari Waterfall?

Jadi, kriteria apa yang dapat Anda gunakan untuk menjelaskan perbedaan-perbedaan ini kepada audiens seperti itu?

release-management agile waterfall

— Pierre.Vriens
sumber

IMO DevOps adalah budaya, seperti Agile (tanpa memilih metodologi lincah.) Karena itu Anda tidak "melakukan" DevOps.

Anda "melakukan" metodologi rilis yang disebut Pengiriman Berkelanjutan sebagai bagian dari Budaya DevOps. (pengungkapan penuh, saya tidak berpikir saya pernah menyebut CD sebagai metodologi rilis sebelumnya, tetapi dalam kondisi jetlagged saya pikir itu berfungsi)

Jika Anda akan membelinya, maka inilah definisi Pengiriman Berkelanjutan dari salah satu orang yang menulis buku dengan judul yang sama, Jez Humble .

Pengiriman Berkelanjutan adalah kemampuan untuk mendapatkan perubahan dari semua jenis — termasuk fitur baru, perubahan konfigurasi, perbaikan bug, dan eksperimen — ke dalam produksi, atau ke tangan pengguna, secara aman dan cepat dengan cara yang berkelanjutan.

Tujuan kami adalah membuat penyebaran — apakah sistem terdistribusi skala besar, lingkungan produksi yang kompleks, sistem tertanam, atau aplikasi — yang dapat diprediksi, urusan rutin yang dapat dilakukan sesuai permintaan.

Kami mencapai semua ini dengan memastikan kode kami selalu dalam status yang dapat digunakan, bahkan di hadapan tim yang terdiri dari ribuan pengembang yang melakukan perubahan setiap hari. Kami dengan demikian sepenuhnya menghilangkan fase integrasi, pengujian, dan pengerasan yang secara tradisional mengikuti "dev complete", serta pembekuan kode.

Jadi, Anda dapat bekerja dalam metodologi Agile, memiliki perangkat lunak yang dapat Anda tunjukkan kepada bisnis, memastikan Anda melakukan pengujian otomatis yang tepat, bereaksi dengan baik terhadap perubahan dan semua hal yang membuatnya lebih baik daripada air terjun. Terlalu sering itu tidak berarti Anda benar-benar dapat menggunakannya untuk produksi.

Anda berakhir dengan sesuatu seperti ini:

Jadi perangkat lunak akan (mungkin) lebih baik ketika Anda selesai maka jika Anda tidak memiliki semacam pendekatan iteratif, tetapi Anda tidak benar-benar tahu karena pengguna nyata belum pernah melihatnya.

Yang benar-benar Anda inginkan adalah sesuatu yang lebih terlihat seperti ini:

Setiap iterasi, sesuatu dikerahkan untuk produksi. Jadi, perangkat lunak digunakan . Jika Anda memutuskan untuk membuat unduhan, buka server web, atau bagaimanapun Anda mendapatkan perangkat lunak ke tangan pengguna yang dirilis .

Apa apaan!? Saya bertanya tentang DevOps! Tidak ada yang bertanya tentang Pengiriman Berkelanjutan !!

Jadi apa yang harus dilakukan DevOps dengan ini?

Sangat, sangat sulit (mendekati tidak mungkin) untuk benar-benar memiliki perangkat lunak Anda dalam keadaan di mana Anda dapat menyebarkannya kapan pun Anda inginkan kecuali jika tim itu bekerja dalam budaya DevOps. Budaya di mana Admin Sistem, DBA, SRE, Petugas Keamanan, Pengembang, QA, dll., Semuanya adalah bagian dari satu tim dan tidak membungkam bagian dari organisasi dengan handoff.

Catatan :

Tentang bagian dari komentar yang diposting ke jawaban ini, yang seperti itu:

Tentang "... perangkat lunak Anda dalam keadaan di mana Anda dapat menggunakannya kapan saja ...": yang mengingatkan saya tentang perangkat lunak "pilot otomatis" (di pesawat) ... Pertanyaan favorit saya tentang itu: " Bayangkan pembaruan diterapkan ke perangkat lunak seperti itu ... Bagaimana perasaan Anda tentang melakukan hal itu di dalam pesawat ... Saat Anda berada di dalam pesawat? "

Saya suka pertanyaan itu (dicetak tebal, dalam kutipan di atas)! Gagasan "apakah ini benar-benar siap?" adalah sesuatu yang saya ucapkan tentang sepanjang waktu - blog . IMO sangat penting bahwa Anda percaya diri dalam keamanan, kinerja, dan tes "sekunder" yang terlalu sering untuk berlatih CD. Fitur-fiturnya sudah selesai ketika sudah selesai, tetapi peretas selalu ada.

— Ken Mugrage
sumber

Terima kasih atas sudut pandang / jawaban Anda yang menarik (dan gambar mengkilap ...). Saya harus mengakui bahwa saya tidak pernah mendengar tentang istilah Metodologi Rilis , meskipun Manajemen Rilis adalah apa yang saya kenal (selama lebih dari 2 dekade ...). Tentang "... perangkat lunak Anda dalam keadaan di mana Anda dapat menggunakannya kapan saja ..." (dikombinasikan dengan "jetlagged"): itu mengingatkan saya tentang perangkat lunak "pilot otomatis" (di pesawat) ... Favorit saya pertanyaan tentang itu: " Bayangkan pembaruan diterapkan ke perangkat lunak seperti itu ... Bagaimana perasaan Anda tentang melakukan hal itu di dalam pesawat ... Saat Anda berada di dalam pesawat? ".

— Pierre.Vriens

Saya suka pertanyaan itu! Gagasan "apakah ini benar-benar siap?" adalah sesuatu yang saya ucapkan tentang sepanjang waktu - blog . IMO sangat penting bahwa Anda percaya diri dalam keamanan, kinerja, dan tes "sekunder" yang terlalu sering untuk berlatih CD. Fitur-fiturnya sudah selesai ketika sudah selesai, tetapi peretas selalu ada.

— Ken Mugrage

Saya mengacu pada - "Bayangkan pembaruan diterapkan pada perangkat lunak seperti itu ... Bagaimana perasaan Anda tentang melakukan hal itu di dalam pesawat ... Saat Anda berada di dalam pesawat?"

— Ken Mugrage

Dan tolong edit, saya n00b di sini :)

— Ken Mugrage

Harap tinjau hasil edit saya yang disarankan, untuk mengintegrasikan komentar menarik Anda juga. Jika Anda tidak menyukainya, cukup lakukan rollback ke versi sebelumnya (tautannya ada dalam "revisi"), dan / atau lebih lanjut tingkatkan / perluas sesuai keinginan Anda. Coba tebak, sepertinya "info" beberapa "izin" saya sudah berubah ... sepertinya saya sudah memiliki terlalu banyak perwakilan di sini untuk masih memerlukan "persetujuan" untuk pengeditan yang disarankan seperti itu ... beruntunglah kami ini hanya beberapa SE- perangkat lunak (bukan pembaruan yang disarankan untuk beberapa rute penerbangan tanpa persetujuan sebelumnya dari kontrol lalu lintas udara ...). Oeps 2 (koreksi): disetujui dengan kecepatan rendah ...

— Pierre.Vriens

Tidak yakin apakah tidak ada yang lain, tetapi ini adalah kriteria yang saya gunakan:

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

Dan jika Anda benar-benar ingin mengalami perbedaan itu sendiri sebagai pengguna beberapa perangkat lunak, maka pikirkan untuk menggunakan beberapa perangkat lunak (seperti distribusi Linux), di mana Anda memiliki pilihan antara menggunakan kedua rilis tersebut:

Rollingrilis " " (==> Agile).
Long Term Supportrilis " " (==> Air Terjun).

— Pierre.Vriens
sumber

Contoh Linux mungkin tidak terlalu inspirasional :) Secara pribadi saya tidak suka rilis bergulir karena: 1. tingkat kualitas dan 2. perubahan yang agak mengganggu (saya lebih suka fokus pada pekerjaan saya, bukan pada linux yang saya gunakan untuk saya kerja). Jadi saya menggunakan istilah jangka panjang (sering melewati EOL mereka) dan hanya fokus pada pembaruan besar setiap 2-3 tahun sekali. Kecuali ini hanya meningkatkan permusuhan untuk berubah karena penuaan? :)

— Dan Cornilescu

@DanCornilescu Saya menggunakan contoh Linux ini karena saya pikir ini adalah contoh ekstrim dari "a" aspek rilis mgnt (yaitu frekuensi rilis) untuk kedua metodologi. Meskipun "secara pribadi", saya sepenuhnya setuju dengan ketidaksukaan Anda terhadap rilis perilisan, untuk alasan yang sama seperti yang Anda sebutkan.

— Pierre.Vriens