Platform, Pipeline, dan Strategi Deployment sebagai Satu Sistem

Tim Anda sudah dipetakan. Anda tahu siapa yang membangun apa, siapa yang meninjau perubahan, dan siapa yang menangani insiden produksi. Namun, ketika seseorang bertanya "di mana sebenarnya kita menjalankan aplikasi ini?" atau "bagaimana kode berpindah dari pull request ke layanan yang berjalan?", jawabannya mulai kabur.

Di sinilah sebagian besar inisiatif pengiriman perangkat lunak mandek. Tim mulai memilih alat, menulis file YAML, dan memutuskan antara blue-green dan canary deployment tanpa menghubungkan titik-titik antara infrastruktur, otomatisasi, dan mekanisme rilis. Hasilnya adalah sistem yang terfragmentasi di mana platform bertentangan dengan pipeline, dan strategi deployment bekerja melawan keduanya.

Mengapa Platform Engineering Didahulukan

Bayangkan sebuah tim yang perlu men-deploy sebuah microservice baru. Tanpa platform bersama, mereka menyediakan mesin virtual secara manual, menginstal dependensi dengan tangan, dan mengonfigurasi jaringan melalui sistem tiket. Tim lain melakukan hal yang sama dengan cara berbeda. Enam bulan kemudian, satu lingkungan menggunakan Ubuntu 20.04, lingkungan lain menggunakan 22.04. Satu tim menyimpan log secara lokal, tim lain mengalirkannya ke layanan terpusat. Ketika terjadi insiden, tidak ada yang tahu lingkungan mana yang berperilaku seperti produksi.

Platform engineering memecahkan masalah ini dengan menyediakan fondasi yang konsisten. Platform ini menjawab pertanyaan: bagaimana tim mendapatkan lingkungan tanpa harus membangun ulang semuanya dari awal setiap saat? Platform bisa berupa klaster Kubernetes dengan template sumber daya yang terstandarisasi, sekumpulan modul Terraform yang digunakan setiap tim, atau lapisan layanan terkelola yang mengabstraksi detail infrastruktur sepenuhnya.

Kuncinya adalah konsistensi. Ketika setiap tim melakukan deployment di atas fondasi yang sama, perbedaan antar lingkungan menyusut. Lingkungan staging berperilaku seperti produksi karena keduanya berjalan di platform yang sama. Masalah yang muncul di pengujian adalah masalah yang sama yang muncul di produksi, bukan masalah baru yang disebabkan oleh penyimpangan konfigurasi.

Modul Terraform bersama membuat konsistensi ini dapat diulang:

# modules/team-namespace/main.tf
resource "kubernetes_namespace" "team" {
  metadata {
    name = var.team_name
    labels = {
      team    = var.team_name
      env     = var.environment
      managed = "platform"
    }
  }
}

resource "kubernetes_resource_quota" "limits" {
  metadata {
    name      = "${var.team_name}-quota"
    namespace = kubernetes_namespace.team.metadata[0].name
  }
  spec {
    hard = {
      pods                = var.max_pods
      requests.cpu        = var.max_cpu
      requests.memory     = var.max_memory
      limits.cpu          = var.max_cpu
      limits.memory       = var.max_memory
      persistentvolumeclaims = var.max_pvcs
    }
  }
}

Setiap tim memanggil modul ini dengan variabel mereka sendiri, tetapi definisi sumber daya yang mendasarinya tetap identik.

Pipeline sebagai Tulang Punggung Pengiriman

Pipeline CI/CD lebih dari sekadar rangkaian langkah otomatis. Pipeline adalah jalur yang menghubungkan kode yang ditulis oleh pengembang ke lingkungan tempat pengguna berinteraksi dengan aplikasi. Setiap tahap dalam pipeline--build, unit test, integration test, security scan, deploy--mewakili langkah dalam aliran nilai yang mengirimkan perubahan ke pengguna.

Tanpa pipeline, langkah-langkah ini terjadi secara manual. Seseorang membangun artefak di laptop mereka. Orang lain menyalinnya ke server. Orang ketiga menjalankan pengujian dengan tangan. Setiap langkah manual memperkenalkan penundaan dan risiko. Dependensi yang terlupakan, versi sistem operasi yang berbeda, atau pengujian yang dilewati dapat menyebabkan kegagalan yang baru muncul setelah deployment.

Pipeline yang dirancang dengan baik menerapkan pemeriksaan yang sama pada setiap perubahan. Setiap pull request memicu proses build yang sama, menjalankan pengujian yang sama, dan melewati gerbang verifikasi yang sama. Tim dapat percaya bahwa pipeline hijau berarti perubahan telah lulus semua pemeriksaan yang penting. Kepercayaan inilah yang membuat deployment sering menjadi aman.

Strategi Deployment Adalah Tentang Pengguna, Bukan Teknologi

Ketika orang berbicara tentang strategi deployment, mereka sering fokus pada pola teknis: blue-green, canary, rolling update, feature flags. Ini adalah detail implementasi. Pertanyaan sebenarnya adalah: bagaimana Anda mengirimkan perubahan tanpa mengganggu pengguna?

Jawabannya tergantung pada karakteristik aplikasi Anda. Layanan web publik dengan jutaan pengguna mungkin memerlukan canary release yang mengarahkan satu persen lalu lintas ke versi baru, kemudian secara bertahap meningkatkan persentase sambil memantau tingkat kesalahan. Alat internal yang digunakan oleh dua puluh orang mungkin cukup dengan rolling update sederhana yang mengganti instance satu per satu.

Deployment basis data menambahkan lapisan kompleksitas lain. Migrasi skema yang menambahkan kolom aman dijalankan bersamaan dengan kode lama. Migrasi yang mengganti nama kolom atau mengubah tipenya memerlukan koordinasi yang cermat antara versi aplikasi. Strategi deployment harus memperhitungkan kendala ini, bukan hanya kode aplikasi.

Kemampuan rollback juga merupakan bagian dari strategi. Jika terjadi kesalahan, seberapa cepat Anda dapat kembali ke versi sebelumnya? Bisakah Anda melakukan rollback aplikasi secara independen dari basis data? Apakah platform mendukung rollback instan, atau Anda perlu membangun ulang dan men-deploy ulang? Pertanyaan-pertanyaan ini harus dijawab sebelum deployment produksi pertama, bukan saat insiden terjadi.

Tiga Lapisan Harus Dirancang Bersama

Platform, pipeline, dan strategi deployment bukanlah pilihan independen. Mereka membentuk sistem di mana setiap lapisan membatasi dan memungkinkan lapisan lainnya.

Diagram di bawah menunjukkan bagaimana setiap lapisan bergantung pada dan membatasi lapisan lainnya.

flowchart TD DS["Strategi Deployment<br>Bagaimana perubahan mencapai pengguna"] P["Pipeline<br>Jalur pengiriman otomatis"] PL["Platform<br>Infrastruktur yang konsisten"] DS -->|membutuhkan| P P -->|dieksekusi di| PL PL -->|memungkinkan| DS PL -->|membatasi| P P -->|memvalidasi| DS DS -->|mendefinisikan kebutuhan| PL

Platform menentukan apa yang bisa dilakukan pipeline. Jika platform tidak mendukung deployment blue-green dengan perpindahan lalu lintas, pipeline tidak dapat mengimplementasikan strategi itu. Jika platform tidak memiliki mekanisme rollback, strategi deployment tidak dapat mengandalkan pemulihan cepat.

Pipeline menentukan bagaimana strategi deployment dijalankan. Jika pipeline tidak menyertakan tahap verifikasi yang menjalankan integration test terhadap lingkungan staging, canary release tidak memiliki health check yang berarti. Jika pipeline melewatkan validasi migrasi basis data, strategi deployment tidak dapat menangani perubahan skema dengan aman.

Strategi deployment menentukan apa yang harus didukung platform. Jika strategi memerlukan rollback instan, platform harus menyimpan versi sebelumnya tetap berjalan dan mengalihkan lalu lintas secara instan. Jika strategi menggunakan feature flags, platform harus mendukung perubahan konfigurasi runtime tanpa redeployment.

Ketika ketiga lapisan ini dirancang bersama, hasilnya adalah sistem pengiriman yang bekerja sebagai satu kesatuan yang koheren. Tim tidak perlu mencari cara untuk membuat komponen yang tidak kompatibel bekerja bersama. Platform menyediakan apa yang dibutuhkan pipeline. Pipeline menjalankan apa yang diminta strategi. Strategi menghormati kemampuan platform.

Daftar Periksa Praktis untuk Sistem Pengiriman Anda

Sebelum Anda memfinalisasi platform, pipeline, dan strategi deployment, jalankan pemeriksaan ini:

  • Dapatkah setiap tim men-deploy layanan mereka menggunakan template pipeline yang sama?
  • Apakah platform memberikan perilaku yang sama di staging dan produksi?
  • Dapatkah Anda melakukan rollback deployment tanpa intervensi manual?
  • Apakah pipeline menyertakan langkah verifikasi yang sesuai dengan strategi deployment Anda?
  • Dapatkah platform mendukung strategi deployment yang Anda pilih tanpa solusi alternatif?
  • Apakah proses migrasi basis data terintegrasi ke dalam pipeline, tidak ditangani secara terpisah?
  • Dapatkah Anda melakukan deployment selama jam kerja tanpa rasa takut mengganggu pengguna?

Jika ada jawaban tidak, Anda memiliki celah di antara lapisan. Perbaiki celah tersebut sebelum Anda menskalakan sistem.

Intisari

Platform, pipeline, dan strategi deployment bukanlah tiga keputusan terpisah. Mereka adalah satu sistem yang harus dirancang bersama. Ketika mereka selaras, tim dapat melakukan deployment sering, pulih dengan cepat, dan percaya bahwa setiap perubahan melewati jalur ketat yang sama. Ketika mereka tidak selaras, setiap deployment menjadi masalah koordinasi, dan setiap insiden mengungkap celah antara apa yang disediakan platform dan apa yang dibutuhkan strategi. Mulailah dengan platform, bangun pipeline di sekitarnya, dan pilih strategi yang dapat didukung oleh keduanya.