Release management · ITIL 5 Learn

Purpose in one sentenceTujuan dalam satu kalimatMake new and changed services and features available for use.Membuat layanan dan fitur baru atau yang diubah siap digunakan.

A release is when new or changed features become available to users. That is not the same as a deployment, which moves components into an environment. Modern teams often deploy first and release later, switching features on for users when everyone is ready. Release management plans what reaches users and when, and makes sure users and support are prepared.

Release adalah saat fitur baru atau yang diubah tersedia bagi pengguna. Ini tidak sama dengan deployment, yang memindahkan komponen ke suatu lingkungan. Tim modern sering melakukan deployment lebih dulu dan release belakangan, menyalakan fitur bagi pengguna saat semua pihak siap. Release management merencanakan apa yang sampai ke pengguna dan kapan, serta memastikan pengguna dan tim support sudah siap.

Key ideasKonsep kunci

A release is a package. A set of changes made available together, usually with a version name or number.
Separate deploy from release. With feature flags, code can be live but switched off until you choose to release it.
Release gradually. A canary release gives a new feature to a small group first, then to everyone.
Readiness is more than code. Release notes, training, support knowledge and communication must be ready too.
Small and frequent beats big and rare. Smaller releases are easier to test, explain and undo.

Release adalah sebuah paket. Sekumpulan perubahan yang tersedia bersamaan, biasanya dengan nama atau nomor versi.
Pisahkan deployment dari release. Dengan feature flag, kode bisa sudah live tetapi dimatikan sampai Anda memutuskan untuk merilisnya.
Rilis secara bertahap. Canary release memberikan fitur baru kepada kelompok kecil lebih dulu, lalu ke semua orang.
Kesiapan bukan hanya soal kode. Catatan rilis, pelatihan, pengetahuan untuk support, dan komunikasi juga harus siap.
Kecil dan sering lebih baik daripada besar dan jarang. Release yang lebih kecil lebih mudah diuji, dijelaskan, dan dibatalkan.

Key activitiesAktivitas kunci

A typical flow. Real work loops back and skips steps when it makes sense.

Alur yang umum. Dalam praktik, pekerjaan bisa kembali ke langkah sebelumnya atau melewati langkah tertentu bila masuk akal.

PlanScope and timing, avoiding busy business periods.
PrepareBuild and test the release package with development.
Check readinessSupport briefed, users informed, rollback ready.
ReleaseSwitch on, ideally for a small group first.
CommunicateClear release notes in users’ language.
Support and reviewEarly life support, then a short review.

MerencanakanCakupan dan waktu, menghindari periode sibuk bisnis.
MenyiapkanBangun dan uji paket release bersama tim development.
Memeriksa kesiapanSupport sudah di-briefing, pengguna diberi tahu, rollback siap.
MerilisNyalakan, idealnya untuk kelompok kecil lebih dulu.
BerkomunikasiCatatan rilis yang jelas dalam bahasa pengguna.
Mendukung dan meninjauEarly life support, lalu review singkat.

How to measure itCara mengukurnya

MetricMetrik	What it tells youApa yang ditunjukkan	Watch out forPerhatikan
Release frequencyFrekuensi release	How often value reaches usersSeberapa sering value sampai ke pengguna	Frequent releases of tiny, meaningless changesRelease yang sering tetapi berisi perubahan kecil tanpa makna
Releases without major incidentsRelease tanpa major incident	Release qualityKualitas release	Incidents not linked to the releaseIncident yang tidak dikaitkan dengan release
Time from approval to availabilityWaktu dari persetujuan hingga tersedia	How fast you deliverSeberapa cepat Anda menyampaikan	Speed gained by skipping readiness checksKecepatan yang didapat dengan melewatkan pemeriksaan kesiapan
Adoption of new featuresAdopsi fitur baru	Whether releases create valueApakah release menghasilkan value	Measuring only that it went liveHanya mengukur bahwa fitur sudah live
RollbacksJumlah rollback	How often releases must be undoneSeberapa sering release harus dibatalkan	Hiding rollbacks to look goodMenyembunyikan rollback agar terlihat baik

What each level looks likeGambaran setiap level

Use these descriptions as a quick self-check before running the full assessment. Level 3 is a strong, realistic target for most teams.

Gunakan deskripsi ini sebagai pengecekan cepat sebelum menjalankan asesmen lengkap. Level 3 adalah target yang kuat dan realistis bagi sebagian besar tim.

L1InitialFeatures appear without warning. Users and the service desk are surprised.
L2RepeatableBig releases are planned, but small ones slip out, and release notes are inconsistent.
L3DefinedA release calendar, a readiness checklist, release notes and a support briefing for every release.
L4MeasuredRelease outcomes (incidents, adoption, rollbacks) are tracked, and reviews improve the process.
L5OptimizedSmall, frequent, low-risk releases, with feature flags and gradual rollout as routine.

L1InitialFitur muncul tanpa pemberitahuan. Pengguna dan service desk terkejut.
L2RepeatableRelease besar direncanakan, tetapi yang kecil lolos begitu saja, dan catatan rilis tidak konsisten.
L3DefinedAda kalender release, checklist kesiapan, catatan rilis, dan briefing support untuk setiap release.
L4MeasuredHasil release (incident, adopsi, rollback) dipantau, dan review memperbaiki prosesnya.
L5OptimizedRelease kecil, sering, dan berisiko rendah, dengan feature flag dan peluncuran bertahap sebagai kebiasaan.

Assess release management in the wizardNilai release management di wizard →

Using AIMemanfaatkan AI

Draft release notes in users’ language from change records and commits.
Risk prediction based on the size and history of similar releases.
Feedback summaries from reviews, chats and tickets after a release.
Translation of release notes and briefings for different audiences.

Draf catatan rilis dalam bahasa pengguna dari change record dan commit.
Prediksi risiko berdasarkan ukuran dan riwayat release serupa.
Ringkasan umpan balik dari ulasan, chat, dan tiket setelah release.
Terjemahan catatan rilis dan briefing untuk berbagai audiens.

Keep a human in the loopTetap libatkan manusiaCheck AI-written release notes for accuracy, and make sure they don’t reveal internal or security details.Periksa keakuratan catatan rilis buatan AI, dan pastikan tidak membuka detail internal atau keamanan.

Key ideaInti materiA release isn’t done when the code is live. It’s done when users can use it and support is ready to help.Release belum selesai saat kodenya live. Release baru selesai saat pengguna bisa memakainya dan tim support siap membantu.

Real-world example: a mobile banking app moves to small releasesContoh kasus: aplikasi mobile banking beralih ke release kecil3 min3 menit

A mobile banking app ships one big release a month. Each one brings a wave of app store complaints and a busy week for the call center.

Sebuah aplikasi mobile banking merilis satu release besar setiap bulan. Setiap release memicu gelombang keluhan di app store dan minggu yang sibuk bagi call center.

They move to releases every two weeks with feature flags. A new QR payment feature goes to 10% of users first. A bug on older Android phones appears, gets fixed, and only then does the feature reach everyone. The call center gets a briefing before every release.

Mereka beralih ke release setiap dua minggu dengan feature flag. Fitur pembayaran QR baru diberikan kepada 10% pengguna lebih dulu. Sebuah bug di ponsel Android lama muncul, diperbaiki, dan baru setelah itu fitur tersebut sampai ke semua pengguna. Call center mendapat briefing sebelum setiap release.

Common pitfallsJebakan umum

Treating deployment and release as the same thing.
Releasing during month-end or other peak business periods.
Forgetting to brief the service desk.
Bundling months of changes into one giant release.

Menganggap deployment dan release sebagai hal yang sama.
Melakukan release saat akhir bulan atau periode sibuk bisnis lainnya.
Lupa memberi briefing kepada service desk.
Menggabungkan perubahan berbulan-bulan menjadi satu release raksasa.

Related practicesPractice terkait

PracticePractice	How they connectBagaimana keterkaitannya
Change enablement	Assesses and authorizes the changes in a release.Menilai dan mengotorisasi change di dalam release.
Deployment management	Moves the release components into environments.Memindahkan komponen release ke lingkungan tujuan.
Service validation and testing	Checks the release meets its requirements.Memastikan release memenuhi persyaratannya.
Knowledge management	Prepares articles so support can help from day one.Menyiapkan artikel agar support bisa membantu sejak hari pertama.

Beginner tipsTips untuk pemula

Send the service desk a one-page briefing before every release: what changes, who is affected, known issues.
Write release notes for users, not developers: "You can now…"
Agree "no-release windows" with the business, such as payroll week or holidays.

Kirimkan briefing satu halaman kepada service desk sebelum setiap release: apa yang berubah, siapa yang terdampak, masalah yang sudah diketahui.
Tulis catatan rilis untuk pengguna, bukan untuk developer: "Sekarang Anda bisa…"
Sepakati "periode tanpa release" bersama bisnis, misalnya pekan penggajian atau hari libur.

The practice name and purpose follow ITIL. KPIs, level descriptions, AI uses and pitfalls are practical guidance written in our own words, not official ITIL text.Nama dan tujuan practice mengikuti ITIL. KPI, deskripsi level, pemanfaatan AI, dan jebakan umum adalah panduan praktis yang ditulis dengan kata-kata sendiri, bukan teks resmi ITIL.