Dalam era yang semakin digital, proses penyebaran perangkat lunak yang dimulai tetapi tidak pernah berakhir. Hal ini akan membutuhkan strategi manajemen rilis baru yang bergantung pada kecepatan dan efisiensi.

Memulai sebuah proyek adalah satu hal. Menyelesaikannya, adalah tantangan lain. Tapi bagaimana kalau proyek tidak pernah berakhir?

Di sinilah para pengembang dan spesialis operasi menemukan diri mereka ketika sebuah organisasi TI memutuskan proses penyebaran perangkat lunaknya akan terus berlanjut. Medan yang sulit untuk beroperasi, dengan pengembangan aplikasi dan integrasi pada dasarnya tidak pernah mencapai titik akhir. Pembaruan mengikuti pembaruan dalam siklus berkelanjutan.

Artikel strategi rilis ini adalah kerangka kerja untuk pembuatan aplikasi yang lebih cepat, lebih baik, dan lebih efisien.

Strategi Manajemen Rilis Baru

Gelombang peluncuran secara terus menerus dapat menyulitkan organisasi. Pelatihan staf berguna, tetapi, tergantung pada disiplin. Metode pengujian harus dicoba, diterima, dan disesuaikan. Pengembang aplikasi (Dev) dan tim operasional (Ops) perlu belajar cara terbaik untuk bekerja dengan satu sama lain, demi efisiensi serta untuk kualitas setiap iterasi yang mereka keluarkan.

Ketika pembangunan berkelanjutan dan integrasi berkesinambungan bergabung bersama-sama dengan cara yang efektif, organisasi menempatkan dirinya di tanah DevOps – apakah itu sengaja ditetapkan untuk melakukannya atau tidak.

Proses penyebaran perangkat lunak ini dapat berarti perubahan besar, tetapi pekerjaan ini dipandang bermanfaat dan tidak terelakkan. Data terbaru menemukan bahwa 40% dari departemen IT di negara maju sudah melakukan beberapa bentuk ini; 50% lainnya sedang mengerjakannya.

Proses penyebaran perangkat lunak yang berkelanjutan dan tidak pernah berhenti adalah bagaimana sebuah bisnis bergerak dengan kecepatan yang dibutuhkan di era modern. Dan setelah Anda memulai, tidak ada yang berhenti.

Strategi penyebaran perangkat lunak baru berarti penyesuaian berkelanjutan

Meluncurkan perubahan aplikasi tidak pernah dilakukan tanpa usaha. Dan ketika itu dilakukan sebagai bagian dari proses pengiriman yang berkelanjutan, itu tidak pernah benar-benar selesai.

Lebih cepat, lebih baik, dan lebih efisien. Itu adalah semboyan untuk bisnis yang berusaha mengimbangi lingkungan IT modern. Agar berhasil, bisnis yang berfokus pada TI telah mengubah siklus pengembangan aplikasi dan sekarang mengandalkan teknik DevOps untuk menghasilkan rilis baru lebih cepat.

Sementara dukungan pihak ketiga untuk membantu pengembang melakukan transisi ke pendekatan baru ini, sisi operasi bisa menjadi pendek. Sebuah perusahaan dapat mencoba strategi penyebaran perangkat lunak baru, tetapi hanya sedikit program pelatihan dan sertifikasi yang membantu personel operasi memperoleh keterampilan yang dibutuhkan untuk mengeksploitasi opsi-opsi ini.

Dalam proses manajemen rilis konvensional, TI akan menulis perangkat lunak baru, mengujinya di server non-produksi, menggulirkan pembaruan secara bertahap, mengawasi masalah, dan kemudian membuatnya tersedia untuk semua orang. Prosesnya lambat, tidak praktis dan berulang, tetapi dikontrol, dipahami dengan baik dan aman.

Mempercepat siklus pengembangan

Dengan munculnya DevOps, tim TI menghadirkan rilis baru dengan lebih cepat. “Persyaratan bisnis baru memaksa perusahaan untuk merilis pembaruan perangkat lunak lebih cepat”.

Pengembangan berkelanjutan DevOps dan integrasi berkelanjutan sering berarti bahwa perangkat lunak diperbarui dalam keadaan konstan. Amazon Web Services, misalnya, mengirimkan rilis baru setiap beberapa detik.

Untuk mendukung strategi manajemen rilis baru perangkat lunak ini, departemen TI perlu berubah. Pengembangan perangkat lunak yang berkelanjutan menuntut integrasi operasional yang ketat untuk penyebaran yang efisien dan efektif dengan ketersediaan beban kerja yang tinggi dan gangguan yang minimal. Itu memerlukan proses bisnis baru serta keterampilan baru.

Sejumlah alat pemrograman baru muncul untuk mendukung pendekatan ini dan mendapatkan perangkat lunak yang dikirimkan lebih cepat. Organisasi pihak ketiga – seperti CBT Nuggets, MindMajix, NetCom Learning, Simplilearn, Learning Tree International dan The Linux Foundation – menawarkan pelatihan dan program sertifikasi untuk alat pengembangan baru.

DevOps Institute menawarkan kursus tentang topik seperti teknik pengujian DevOps dan arsitektur pengiriman berkelanjutan. Namun, semua program terutama berusaha untuk memberikan keahlian dalam berbagai alat pengembangan dan mengatasi tantangan manajemen.

Munculnya model penyebaran baru

Di sisi operasi, opsi baru telah muncul untuk mempercepat penyebaran sistem.

Sebagai contoh:
  • pendekatan biru / hijau mensyaratkan bahwa perusahaan menyiapkan dua sistem, yang satu dianggap biru dan yang lain hijau.
  • biru mendukung lingkungan produksi, dan hijau adalah pengujian. Setelah pengujian selesai, pembaruan didorong keluar ke simpul biru dalam satu gerakan.

Pendekatan lain membatasi penerapan kode baru dalam berbagai cara. Dalam penyebaran canary, rilis perangkat lunak bertindak sebagai sistem peringatan dini. Perangkat lunak diuji dalam lingkungan ‘live’ kecil, terkontrol, sebelum diluncurkan di semua sistem produksi.

Pengujian dengan pengguna nyata dalam lingkungan produksi memberikan perusahaan wawasan ke dalam angka-angka kinerja aktual daripada di lingkungan simulasi.

Strategi manajemen rilis baru perangkat lunak lain adalah teknik pendukung kehidupan awal. Dalam pendekatan ini, tim penyebaran mendefinisikan dan mendokumentasikan kriteria yang dianggap dapat diterima oleh bisnis untuk dirilis.

Tim memonitor pembaruan untuk jangka waktu tertentu untuk memastikan bahwa itu aman. Pendekatan ini mungkin tidak efektif di lingkungan DevOps, di mana beberapa rilis terjadi setiap hari, tetapi dapat membantu ketika pembaruan kurang sering dilakukan.

Juga, beberapa organisasi memilih penerapan bergulir. Ini membutuhkan sistem perangkat lunak, seperti load balancer.

Perangkat lunak baru diuji dan dioptimalkan pada server yang tidak aktif sampai tim operasi merasa nyaman. Penyebaran rilis baru kemudian secara progresif dijalankan di server dalam sebuah cluster. Satu node diambil offline dan diperbarui, sementara server lain memproses lalu lintas produksi.

Kemudian proses ini diulang untuk server lain sampai mereka semua menjalankan rilis yang sama. Metode penyebaran ini mengisolasi masalah apa pun dari pembaruan ke sejumlah sistem yang terbatas, tetapi mengharuskan tim operasi memantau dan mengelola perangkat lunak baru secara ketat.

Faktor “gerbang”

Fitur bendera adalah alat pengembangan perangkat lunak yang berfungsi gerbang baru. Di sini, operasi mengelola seluruh siklus hidup suatu fitur. Organisasi melakukan peluncuran fitur secara bertahap dan menonaktifkan fitur buggy tanpa menerapkan ulang ketika masalah muncul. Setelah bug diperbaiki, semua flag dihapus.

Peluncuran “senyap” adalah proses serupa. Perangkat lunak secara bertahap dirilis ke pengguna untuk mendapatkan umpan balik mereka serta untuk menguji kinerja. Kode dibungkus dalam fitur toggle yang mengontrol siapa yang dapat melihat fitur baru dan kapan.

Facebook dan Google mengandalkan peluncuran senyap untuk secara bertahap merilis dan menguji fitur baru ke sekelompok kecil pengguna sebelum merilisnya sepenuhnya.

Pendekatan ini memungkinkan staf operasi menentukan apakah pengguna menyukai atau tidak menyukai fungsi baru. Ini juga memungkinkan untuk penilaian kinerja sistem sebelum melanjutkan dengan rilis penuh.

Ketika pilihan pengiriman yang berbeda ini muncul, perusahaan mencari cara untuk melatih dan membiasakan staf mereka sebagai bagian dari strategi manajemen rilis baru perangkat. Pilihan terbatas.

Tidak ada program pelatihan yang ditujukan khusus untuk opsi penyebaran yang muncul atau yang dapat membantu tim operasi menentukan pilihan mana yang paling cocok untuk organisasi tertentu.

Linux Foundation menawarkan kursus tentang dasar-dasar DevOps dengan penekanan pada integrasi berkelanjutan dan pengiriman berkelanjutan serta tahap rilisnya yang berbeda: fase build, pengemasan, dan penyebaran.

Perusahaan merangkul DevOps untuk mempercepat penyebaran aplikasi. Saat ini, opsi pelatihan dan sertifikasi untuk strategi penyebaran perangkat lunak yang inovatif sudah lebih matang di sisi pengembangan daripada komponen operasi.

Tingkatkan perencanaan peluncuran aplikasi dengan opsi lanjutan

Tim TI Perusahaan memiliki beberapa opsi lanjutan untuk menerapkan pembaruan aplikasi. Yang benar bergantung pada apa yang paling masuk akal untuk bisnis, infrastruktur TI yang tersedia, dan keyakinan Anda dalam pembaruan.

Perencanaan peluncuran aplikasi mengharuskan tim operasi TI untuk mencapai keseimbangan yang sulit antara tuntutan pengembangan, harapan pengguna, dan kenyataan bisnis sehari-hari. Ketika rilis perangkat lunak tiba lebih cepat, sakit kepala menjadi lebih besar.

Secara tradisional, tim operasi TI menyebarkan pembaruan dengan mengambil server aplikasi atau server secara offline, meluncurkan pembaruan dan mengembalikan infrastruktur ke produksi dengan beberapa pengujian untuk memverifikasi fungsi pembaruan sebagaimana dimaksud.

Pengembangan perangkat lunak berkelanjutan, seperti yang terlihat dalam metodologi DevOps, menuntut integrasi operasional yang lebih ketat untuk penyebaran yang efisien dan efektif dengan ketersediaan beban kerja yang tinggi dan gangguan pengguna yang minimal.

Tidak ada cara yang tepat untuk menggulirkan perangkat lunak, terutama di server aplikasi. Tetapi ada beberapa panduan untuk memilih yang terbaik. Strategi yang berbeda sesuai dengan beban kerja dan jenis pembaruan yang berbeda. Masing-masing juga memiliki implikasi sendiri untuk produksi infrastruktur TI, yang membuat perencanaan peluncuran aplikasi penting.

Mengumpulkan pembaruan aplikasi

Pemasangan canary, kadang-kadang disebut bertahap atau “incremental rollout”. Nama Canari ini diambil dari praktik pertambangan lama, mengambil canary yang dikandangkan ke tambang sebagai sistem peringatan dini untuk gas beracun yang dapat membahayakan para penambang.

Pengalokasian Canary menggulirkan pembaruan ke sebagian kecil dari infrastruktur terlebih dahulu, memungkinkan sebagian kecil pengguna untuk bertindak sebagai kelompok uji yang menangkap kesalahan sebelum masalah sebelum menyebar dan mempengaruhi seluruh basis pengguna.

Pemasangan Canary memiliki persyaratan infrastruktur minimal, mengurangi banyak perencanaan kapasitas pra-peluncuran. Biasanya grup canary terdiri dari satu server atau cluster, atau satu set server terbatas.

Load balancer dikonfigurasi untuk menghentikan lalu lintas ke sistem tersebut untuk pembaruan, sementara sebagian besar server aplikasi terus melayani pengguna dengan versi perangkat lunak yang dikenal baik.

Load balancers kemudian diarahkan ke sebagian kecil dari keseluruhan lalu lintas ke server atau cluster yang diperbarui selama fase pengujian. Pengguna Canary dapat menjadi sampel acak pengguna, hanya karyawan internal atau profil pengguna tertentu atau demografi lainnya.

Pemasangan canary cukup dapat diandalkan. Jika ada masalah dengan rilis baru, tim penyebaran dengan mudah mengarahkan pengguna ke server yang menjalankan versi perangkat lunak yang ada sementara tim menyebarkan tambalan dan perbaikan pada pembaruan, sebanyak yang diperlukan.

Jika pengembang dan pemangku kepentingan yakin dengan fungsi versi baru, administrator TI dapat menerapkannya ke server tambahan, sampai semua server aplikasi menjalankan versi baru. Strategi ini tidak memerlukan sumber daya TI tambahan, meskipun sistem uji dapat ditambahkan jika diinginkan.

Kelemahan dari penyebaran Canary

Satu kelemahan dari penyebaran canary untuk dipertimbangkan selama perencanaan peluncuran aplikasi adalah waktu yang diperlukan untuk menyelesaikan pembaruan. Ini karena versi baru diuji dan bertahap secara bertahap ke dalam produksi.

Pemilik aplikasi harus mengelola lebih dari satu versi secara bersamaan, dan menuntut perubahan hati-hati dan manajemen versi pada bagian dari staf operasi TI.

Peningkatan penggunaan secara bertahap memungkinkan banyak kesempatan untuk mengumpulkan metrik beban, namun, memungkinkan perencana kapasitas TI produksi untuk melihat bagaimana tuntutan beban berubah dengan kode yang diperbarui.

Proses kenari menyediakan proses rollback yang relatif aman dan cepat jika konsekuensi yang tidak diinginkan terjadi.

Rencanakan peluncuran aplikasi canary untuk perubahan yang relatif kecil di mana kepercayaan pada rilis tinggi, seperti pengujian perbaikan masalah atau regresi. Jika Anda menguji perubahan perangkat lunak yang lebih signifikan seperti peningkatan versi utama, penerapan alternatif, atau perubahan arsitektur dasar perangkat lunak, gulir ke bawah untuk membaca tentang penerapan biru / hijau.

Roll on, aplikasi

Rolling deployment adalah bentuk alternatif dari strategi manajemen rilis perangkat lunak bertahap di mana versi perangkat lunak baru secara sistematis secara perlahan ditempatkan di satu atau lebih server yang ada, biasanya dalam gugus server.

Sebagai contoh:
  • Misal ada server aplikasi cluster dengan empat node.
  • Masing-masing dari empat node server aplikasi menerima traffic melalui load balancer.
  • Pengoperasian bergulir membutuhkan satu simpul offline, dan load balancer mengarahkan lalu lintas ke server yang tersisa yang masih menjalankan versi perangkat lunak saat ini.
  • Server siaga diperbarui sementara server aktif terus mendukung lalu lintas pengguna.
  • Perangkat lunak diuji dan dioptimalkan pada server yang menganggur, kemudian proses diulang secara sistematis untuk semua server aplikasi dalam kluster sampai semuanya menjalankan versi yang sama.

Pengoperasian bergulir tidak memerlukan perangkat keras atau infrastruktur tambahan, dan aplikasi tetap tersedia karena server yang tidak diperbarui membawa beban pengguna.

Jika kesalahan atau konsekuensi tak terduga lainnya terjadi dalam versi perangkat lunak baru, servernya dapat dipulihkan dari cadangan atau image VM yang dilindungi hingga versi baru siap. Tim TI harus memiliki rencana rollback dengan cadangan dan pemulihan di tempat.

Indonesia Disaster Recovery as a Service Data Center
Penggelaran Rolling secara konseptual hampir identik dengan penyebaran canary, hanya berbeda cara penggunaan. Dalam perencanaan peluncuran aplikasi, penyebaran Canary biasanya berarti penerapan pengujian awal atau peningkatan lambat, sementara proses sistematis memperbarui server yang tersisa umumnya disebut pengguliran secara bergulir.

Misalnya, pengujian Canary mungkin dilakukan pada satu server selama beberapa hari dan perlahan-lahan diluncurkan ke server tambahan selama beberapa minggu.

Sebagai perbandingan, penyebaran secara bergulir biasanya memperbarui semua sistem produksi dalam hitungan jam atau hari. Biasanya ada kurang perhatian dengan pengujian beban dan mengumpulkan metrik kinerja saat membuat rencana penerapan aplikasi.

Selain itu, lalu lintas biasanya tidak sengaja dibatasi untuk memilih grup atau demografi seperti halnya dengan pengujian Canary.

Gunakan penerapan bergulir saat ada kepercayaan yang lebih tinggi dalam pembaruan perangkat lunak, dan terapkan pada jadwal yang ditentukan.

Pendekatan penuh warna untuk aplikasi yang matang

Pengerahan biru / hijau bergantung pada pendekatan cutover yang lebih luas. Tim TI menjalankan kumpulan infrastruktur TI ganda, baik pada perangkat keras di pusat data atau pada instance cloud, yang identik mungkin. Satu set perangkat keras menjalankan versi perangkat lunak saat ini dan menangani lalu lintas aplikasi, sementara perangkat keras pendamping diatur dalam mode siaga. Moniker biru dan hijau adalah umum, atau kadang A dan B.

Ketika rilis perangkat lunak baru sudah siap, tim akan menyebarkannya ke perangkat perangkat keras menganggur biru. Set aktif hijau menjalankan seluruh beban kerja perangkat lunak yang dikenal baik.

Saat pengujian penerapan baru selesai, TI mengalihkan ulang lalu lintas ke perangkat keras biru, dan perangkat hijau yang telah aktif dibiarkan menganggur. Proses ini akan terbalik ketika iterasi peranti lunak berikutnya siap untuk rilis.

Penyebaran biru / hijau memerlukan dua perangkat keras yang identik, dan perangkat keras itu membawa tambahan biaya dan overhead tanpa benar-benar menambah kapasitas atau meningkatkan pemanfaatan. Ini tidak terlalu efisien dibandingkan dengan penyebaran canary atau rolling.

Manfaat tambahan biaya tambahan ini dalam rencana penerapan aplikasi biru / hijau adalah kemampuan rollback langsung, karena perangkat keras alternatif selalu menjalankan versi perangkat lunak yang terakhir dikenal baik. Ini sangat menarik ketika merencanakan peluncuran beban kerja bisnis penting-misi. Rollback sederhana seperti merutekan lalu lintas aplikasi dari satu perangkat keras ke perangkat lainnya.

Karena cutover akan memengaruhi semua pengguna aplikasi sekaligus, bisnis harus memiliki keyakinan yang sangat tinggi terhadap integritas perangkat lunak.

Contoh:
  • Penyebaran biru / hijau sering disediakan untuk aplikasi besar dan matang yang telah diuji secara menyeluruh.
  • Penerapan biru / hijau terkadang digunakan untuk mengevaluasi perubahan perangkat lunak utama, seperti pembaruan arsitektur yang signifikan.

Pertimbangkan memantau metrik atau indikator kinerja utama untuk secara obyektif membandingkan perbedaan operasional antara versi terbaru dan sebelumnya.

Timbang pro dan kontra selama perencanaan peluncuran aplikasi, dan terapkan setiap strategi di mana dapat optimalkan hasil terbaik untuk bisnis.

Luncurkan praktik terbaik pengelolaan untuk setiap tim TI

Tidak ada yang suka aplikasi yang bermasalah setelah mencapai produksi. Tim operasi TI dapat menyelamatkan diri mereka sendiri dengan menerapkan strategi manajemen rilis baru dari desain awal.

Tujuan IT pro adalah untuk memindahkan kode – baik sepotong infrastruktur atau aplikasi yang diperbarui – dari jaminan, pementasan dan penilaian hingga produksi. Langkah sederhana itu bisa menjadi tangkapan besar.

Pengembang membangun kode baru di kotak pasir dan pindah ke produksi saat siap. Banyak cerita horor tentang proyek TI yang membutuhkan sumber daya tambahan dan lisensi dalam penyebaran atau yang gagal karena alasan lain.

Tim yang tidak mengikuti praktik terbaik manajemen rilis, sering membuat asumsi tentang langkah-langkah untuk mendapatkan beban kerja yang dilepaskan ke dalam produksi yang menghasilkan kesalahan pada langkah terakhir.

Banyak fokus pada praktik terbaik dalam manajemen rilis – dan penyimpangan dari mereka – selama bertahun-tahun. Perpustakaan Infrastruktur Teknologi Informasi (I.T.I.L.), kerangka kerja manajemen layanan, bertujuan untuk menyelaraskan TI dan layanannya dengan kebutuhan dan arah bisnis.

Pemeriksaan dan penyesuaian pada berbagai tahap harus dapat melindungi bisnis dari isu-isu kritis dan perubahan yang tidak terduga. Kerangka komprehensif ini benar-benar mencakup dan mengandung banyak kekurangan TI untuk bisnis, dan membantu mengatasi kesenjangan tersebut.

Tantangannya adalah semua checks and balances membutuhkan sumber daya, mengatasi kekurangan membutuhkan sumber daya – ini adalah tema umum dengan I.T.I.L. Untuk memanfaatkan apa yang ditawarkan I.T.I.L., membutuhkan investasi dalam sumber daya dan staf, dan itu adalah sesuatu yang banyak bisnis tidak mau atau tidak dapat alokasikan.

Bagi banyak perusahaan, mengubah staf TI yang dibayar tinggi menjadi proposisi yang mahal dan memakan waktu. Dokumen tidak seberharga pengalaman dukungan IT atau tugas desain yang membutuhkan keahlian khusus.

Terapkan praktik terbaik manajemen rilis

Manajemen rilis sangat penting, tetapi dalam bentuknya yang murni akan terlalu banyak sumber daya dan langkah yang harus di ikuti perusahaan. Namun, praktik terbaik pengelolaan rilis tidak sepenuhnya di luar jangkauan.

Operasional dan manajemen harus menandatangani desain. Insinyur dan arsitek bisa eksis dalam vakum figuratif, dan mungkin tidak selalu menyadari kompleksitas desainnya. Sebelum menghabiskan uang atau waktu untuk desain, operasi dan staf manajemen yang tepat harus menandatangani diskusi papan tulis awal untuk memastikan ruang lingkup dan kerumitan yang masuk akal.

Selain itu, kontak manajemen harus berfungsi sebagai sponsor usaha; kontak operasional adalah orang yang ditunjuk sebagai kontak handoff operasional.

Outsourcing atau Managed IT Services menyediakan kontrol kualitas terbaik. Pengembang yang menulis aplikasi atau pembaruan kode tidak dapat menjadi orang yang melakukan pemeriksaan jaminan kualitas.

Semuanya membutuhkan “Second Opinion” sebelum memasuki produksi. Pengembang lain atau administrator sistem harus terlibat untuk membuat standar praktik manajemen rilis terbaik ini.

Strategi manajemen rilis membutuhkan manajer rilis

Seseorang di tim operasi harus mengambil kepemilikan kode baru setelah menyelesaikan pengembangan dan jaminan kualitas. Pertimbangkan untuk membuka lowongan helpdesk atau administrator TI untuk tugas tersebut.

Manajer rilis harus memahami apa penyebarannya, bagaimana seharusnya berfungsi dan apa yang harus dilakukan jika ada kesalahan. Mereka juga harus memahami siklus rilis ke dalam produksi.

Praktik terbaik manajemen rilis termasuk melacak waktu penggunaan kritis, penghentian operasi dan tingkat staf dan merencanakan pelepasan pada waktu yang optimal untuk menekan risiko gangguan pada lingkungan produksi. Dokumentasikan faktor-faktor ini dalam manual rilis aplikasi.

Titik kontak dalam operasi sangat penting untuk penyalinan awal kode ke infrastruktur produksi, serta untuk 30 hari pertama kode itu hidup dalam produksi.

Rilis ini hanya berhasil jika pelanggan mengatakannya seperti itu. Bagian terakhir dan paling penting dari keseluruhan proses adalah lingkaran umpan balik pelanggan. Pengerahan produksi hanya berhasil bila Anda memiliki umpan balik pelanggan yang positif.

Menutup loop antara pelanggan, operasi dan pengembangan dapat membantu untuk memastikan keberhasilan penyebaran – dan akhirnya bisnis.

Kesimpulan:

Memindahkan sistem atau aplikasi apa pun ke dalam produksi merupakan risiko. Kegagalan dapat merubah operasional ke mode krisis untuk memperbaiki masalah.

Sasaran praktik terbaik pengelolaan rilis adalah membuat rencana yang sesuai untuk perusahaan Anda dan meminimalkan risiko terhadap lingkungan produksi.

Meskipun tidak mungkin untuk mengurangi setiap masalah yang tidak terduga, tetap mungkin untuk mengurangi banyak orang yang bekerja dengan tonggak pencapaian akal sehat dan handoffs.

Praktik terbaik ini membantu pengembang, manajer, dan dukungan operasional dalam menghindari visi terowongan ketika melihat rilis produksi.

Jika Anda tidak memiliki sumber daya untuk melakukan struktur manajemen layanan I.T.I.L. skala penuh, pendekatan hibrida untuk rilis produksi akan sangat masuk akal.