35-7 · Bab 35 · 5 menit baca

Ketika Setiap Tim Melakukan Deployment dengan Cara Berbeda

Deployment yang tidak konsisten antar tim adalah masalah organisasi, bukan skill. Platform engineering menyediakan jalur deployment bersama yang aman, cepat, dan mudah digunakan tanpa menghilangkan fleksibilitas.

Ketika Setiap Tim Melakukan Deployment dengan Cara Berbeda

Di banyak organisasi engineering, deployment bukanlah kapabilitas bersama. Ia adalah kumpulan kebiasaan individual. Tim A punya shell script yang dijalankan dari laptop seseorang. Tim B punya pipeline yang dibangun dua tahun lalu, dan tidak ada yang berani menyentuhnya karena takut rusak. Tim C menggunakan tools yang sama sekali berbeda karena seorang senior engineer nyaman dengannya. Hasilnya bisa ditebak: deployment menjadi tidak konsisten. Satu tim bisa ship dalam lima menit. Tim lain butuh dua jam. Satu tim punya rollback otomatis. Tim lain harus mengembalikan dari backup secara manual.

Situasi ini bukan tentang skill. Ini tentang ketiadaan sistem deployment bersama. Ketika setiap tim membangun jalur deployment-nya sendiri, organisasi kehilangan kemampuan untuk memastikan bahwa setiap deployment mengikuti safety checks yang sama. Security scan mungkin dilewati di satu tim. Integration tests mungkin opsional di tim lain. Proses approval pun berbeda-beda. Dan ketika terjadi masalah, sulit untuk mengetahui apakah masalahnya ada di kode, konfigurasi, atau proses deployment itu sendiri.

Masalah Beban Kognitif

Setiap kali sebuah tim harus memikirkan cara melakukan deployment, mereka kehilangan fokus dari hal yang sebenarnya penting: apakah fiturnya benar, apakah perubahan database aman, atau apakah konfigurasi infrastruktur sudah sesuai. Deployment menjadi distraksi, bukan rutinitas.

Ini sangat menyakitkan bagi tim yang menangani kode aplikasi sekaligus infrastruktur. Mereka harus mengingat environment variables mana yang harus diatur, secrets mana yang harus dirotasi, migration scripts mana yang harus dijalankan, dan urutan menjalankannya. Overhead mental terus menumpuk. Dan ketika ada yang terlupa, deployment gagal, dan tim menghabiskan waktu untuk debugging proses alih-alih memperbaiki produk.

Masalahnya bukan karena tim ceroboh. Masalahnya adalah pengetahuan tentang deployment tersebar di antara individu, script, dan dokumentasi yang usang. Tidak ada satu sumber kebenaran. Setiap deployment terasa seperti masalah baru yang harus dipecahkan.

Platform Engineering sebagai Layanan, Bukan Tools

Platform engineering mengatasi hal ini dengan menyediakan jalur deployment yang sudah teruji, aman, dan mudah digunakan. Idenya sederhana: tim tidak perlu mencari cara untuk melakukan deployment. Mereka tidak perlu khawatir tentang setup environment, version tracking, atau prosedur rollback. Platform yang menangani semua itu.

Tapi platform bukanlah tools. Ia adalah layanan. Tim tidak peduli apakah platform berjalan di Jenkins, GitLab CI, GitHub Actions, atau yang lain. Yang mereka pedulikan adalah apakah platform membantu mereka melakukan deployment dengan aman, cepat, dan tanpa harus memikirkan hal-hal yang seharusnya sudah ditangani. Jika platform terlalu kompleks atau terlalu kaku, tim akan mencari jalannya sendiri. Dan organisasi kembali ke titik awal: deployment yang tidak konsisten.

Platform yang baik menyediakan golden path. Ini adalah cara deployment yang paling direkomendasikan, dan berfungsi untuk sebagian besar tim hampir sepanjang waktu. Tapi platform juga memungkinkan kustomisasi untuk tim dengan kebutuhan spesifik. Tim yang menangani aplikasi dengan kepatuhan tinggi mungkin membutuhkan langkah approval tambahan. Tim yang mengerjakan internal tool dengan risiko rendah mungkin bisa melakukan deployment lebih cepat. Platform harus mengakomodasi perbedaan ini tanpa memaksa setiap tim membangun semuanya dari awal.

Apa yang Sebenarnya Disediakan oleh Deployment Platform

Deployment platform bukan sekadar pipeline. Ia adalah sekumpulan kapabilitas yang bisa digunakan tim tanpa membangun infrastruktur dari nol. Berikut adalah apa yang biasanya disertakan dalam platform yang praktis:

Contohnya, template job GitLab CI yang dapat digunakan kembali mungkin terlihat seperti ini:

.deploy-template:
  stage: deploy
  script:
    - run-security-scan
    - run-integration-tests
    - deploy-canary --percentage 10
    - wait-for-health-check
    - promote-to-production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  variables:
    DEPLOY_ENV: "production"
  artifacts:
    reports:
      security: gl-security-report.json

Tim dapat menyertakan template ini di pipeline mereka sendiri, mewarisi semua safety checks tanpa harus mengimplementasikannya ulang.

Pipeline standar yang sudah terintegrasi dengan cara tim menulis kode, menyimpan konfigurasi, dan mengelola environment. Ketika sebuah tim melakukan push kode ke branch tertentu, platform secara otomatis menjalankan langkah build, test, dan deployment. Tim tidak perlu menulis script pipeline dari awal.

Environment management yang memastikan setiap environment konsisten. Staging dan production tidak boleh melenceng karena seseorang mengubah konfigurasi secara manual. Platform harus memastikan bahwa environment diprovisi dan dikonfigurasi dengan cara yang sama setiap saat.

Security dan compliance checks yang berjalan otomatis pada setiap deployment. Ini termasuk vulnerability scanning, secret detection, dan policy enforcement. Tim tidak perlu mengingat untuk menjalankan pemeriksaan ini. Platform menjalankannya sebagai bagian dari proses deployment.

Kapabilitas rollback yang teruji dan andal. Ketika deployment bermasalah, platform harus menyediakan cara untuk kembali ke kondisi baik sebelumnya tanpa intervensi manual. Ini tidak hanya tentang kode. Ini juga berlaku untuk database migrations dan perubahan infrastruktur.

Integrasi observability yang menghubungkan event deployment ke monitoring dan alerting. Ketika deployment terjadi, platform harus mengeluarkan sinyal yang membantu tim memahami apakah deployment berjalan sehat. Ini mengurangi waktu antara deployment yang buruk dan deteksinya.

Konsistensi Tanpa Kekakuan

Ketakutan terbesar tentang platform engineering adalah bahwa ia akan memaksa setiap tim ke dalam cetakan yang sama. Itu adalah kekhawatiran yang valid, tapi juga merupakan kesalahpahaman tentang apa yang dilakukan platform yang baik.

Platform yang terlalu kaku akan ditolak oleh tim. Mereka akan mem-bypass-nya, membangun workaround sendiri, atau mengabaikannya sama sekali. Platform yang terlalu fleksibel akan menjadi kacau, dengan setiap tim menggunakannya secara berbeda dan organisasi kehilangan konsistensi yang ingin dicapai.

Keseimbangannya terletak pada penyediaan golden path yang berfungsi untuk sebagian besar kasus, sambil memungkinkan tim untuk menyimpang ketika mereka memiliki alasan yang jelas. Penyimpangan harus eksplisit, bukan aksidental. Jika sebuah tim membutuhkan alur approval yang berbeda, mereka harus bisa mengonfigurasinya. Jika sebuah tim perlu menjalankan tes tambahan sebelum deployment, mereka harus bisa menambahkannya. Tapi jalur dasar harus menjadi default, dan harus menjadi opsi yang paling mudah digunakan.

Checklist Praktis untuk Membangun Deployment Platform

Jika Anda sedang mempertimbangkan untuk membangun atau meningkatkan deployment platform, berikut adalah checklist singkat untuk memandu upaya tersebut:

Apakah platform mengurangi jumlah keputusan yang harus diambil tim sebelum melakukan deployment?
Dapatkah sebuah tim melakukan deployment tanpa membaca dokumentasi atau bertanya ke tim lain?
Apakah platform menerapkan security dan compliance checks yang sama untuk setiap tim?
Apakah rollback otomatis dan teruji, bukan hanya terdokumentasi?
Dapatkah tim menyesuaikan proses deployment tanpa merusak platform?
Apakah platform mengeluarkan sinyal yang membantu tim mendeteksi masalah setelah deployment?
Apakah platform lebih mudah digunakan daripada alternatif membangun pipeline kustom?

Jika jawaban untuk salah satu pertanyaan ini adalah tidak, platform belum memenuhi tujuannya.

Tujuan Sebenarnya

Platform engineering bukan tentang sentralisasi kontrol. Ini tentang menghilangkan gesekan. Ketika tim dapat melakukan deployment tanpa memikirkan proses deployment itu sendiri, mereka bisa fokus pada apa yang sebenarnya mereka bangun. Mereka bisa mengirim fitur lebih cepat, pulih dari kegagalan dengan lebih andal, dan menghabiskan lebih sedikit waktu pada overhead operasional.

Ukuran platform yang baik bukanlah berapa banyak tools yang diintegrasikan atau berapa banyak fitur yang dimilikinya. Ukurannya adalah apakah tim cukup percaya untuk menggunakannya tanpa keraguan. Ketika sebuah tim bisa push kode dan tahu bahwa platform akan menangani sisanya, organisasi telah beralih dari kebiasaan deployment individual ke kapabilitas deployment bersama. Di titik itulah deployment berhenti menjadi risiko dan mulai menjadi rutinitas.