Topologi deployment

Menata lingkungan dan strategi deployment DAG, termasuk pemisahan repo dan CI/CD.

Daftar isi

Topik ini membahas alur kode DAG dari repository pengembang hingga lingkungan Airflow yang berjalan. Pembahasan mencakup pemisahan repository DAG dan konfigurasi Airflow, susunan lingkungan dev, staging, dan production, konsep bundle sebagai unit sumber DAG pada Airflow 3, alur CI/CD (continuous integration dan continuous delivery), beserta strategi rollback, yaitu pengembalian DAG ke versi sebelumnya. Setelah topik ini, perubahan DAG dapat diterapkan ke production secara terkontrol dan dapat dikembalikan jika terjadi masalah.

Pemisahan repository DAG dan konfigurasi Airflow#

Kode DAG dikelola dalam repository tersendiri yang berisi berkas DAG, pengujian, dan metadata proyeknya. Repository memberikan riwayat perubahan yang dapat ditelusuri melalui commit, mekanisme tinjauan kode melalui pull request, dan titik pengembalian yang jelas melalui tag. Berkas DAG pada repository inilah satu-satunya sumber kebenaran, sehingga tidak ada lagi salinan DAG yang diedit langsung di server.

Konfigurasi Airflow dikelola terpisah karena sifat dan siklusnya berbeda. Nilai seperti kunci core.executor, ukuran pool, Connections, dan Variables berada di sisi deployment dan berbeda antar lingkungan, sedangkan kode DAG sama untuk semua lingkungan. Siklus perubahannya pun berbeda, yaitu DAG dapat berubah beberapa kali seminggu, sedangkan konfigurasi platform berubah jarang dan disertai pertimbangan operasional. Pemisahan ini juga membatasi akses, karena pengembang data tidak semestinya mengetahui kredensial sumber data production.

Bentuk repository DAG yang rapi memuat minimal tiga bagian berikut, yaitu berkas DAG, pengujian, dan berkas dependensi.

text Struktur folder repository DAG

repo-pipeline-data/
├── dags/
│   ├── rekap_suhu.py
│   ├── arsip_cadangan.py
│   └── .airflowignore
├── tests/
│   ├── test_rekap_suhu.py
│   └── test_integritas_dag.py
├── requirements.txt
└── README.md

Folder dags memuat berkas DAG yang nantinya dibaca Airflow, folder tests memuat pengujian yang dijalankan CI, dan requirements.txt mencantumkan paket provider yang dibutuhkan DAG. Berkas .airflowignore menyaring berkas yang tidak perlu diparse. Struktur sederhana ini sudah cukup untuk seluruh alur deployment pada topik ini.

Lingkungan dev, staging, dan production#

Deployment yang sehat menyediakan tiga lingkungan terpisah dengan basis data metadata, konfigurasi, dan sumber daya masing-masing. Kode DAG pada ketiga lingkungan tersebut tetap sama, sedangkan yang berbeda hanya Connections, Variables, dan parameter lingkungan.

Lingkungan	Peran	Data	Perubahan kode
dev	eksperimen dan pengembangan	tiruan atau sebagian kecil	bebas, sering
staging	pengujian menyerupai production	tiruan yang terkontrol	hanya melalui deployment
production	melayani kebutuhan nyata	asli	hanya melalui deployment

Lingkungan dev adalah tempat dags test dan eksperimen berlangsung secara bebas. Staging meniru production sebesar yang terjangkau, misalnya jadwal dan dependensi DAG yang sama dengan data tiruan. Dengan demikian, kegagalan yang akan muncul di production dapat terdeteksi lebih dulu di staging. Production melayani data asli, dan aturannya tegas, yaitu perubahan hanya masuk melalui mekanisme deployment, bukan melalui penyuntingan berkas di server.

Bundle sebagai unit sumber DAG#

Airflow 3 memuat DAG dari bundle, yaitu unit sumber DAG yang dideklarasikan pada konfigurasi dag processor. Bundle menentukan dari mana berkas DAG diambil, baik folder lokal, repository Git, maupun bucket penyimpanan objek. Konsep ini menggantikan kebiasaan Airflow 2 yang hanya menggunakan satu folder DAG, dan menjadi titik pertemuan yang tepat antara proses deployment dan Airflow.

Nilai bawaan konfigurasi tersebut memuat satu bundle bernama dags-folder yang menunjuk ke folder DAG yang ditetapkan konfigurasi.

bash

# baca konfigurasi bundle bawaan dari dag processor
export AIRFLOW_HOME=/tmp/ra-topologi-deployment
airflow config get-value dag_processor dag_bundle_config_list

text Keluaran

[
{
"name": "dags-folder",
"classpath": "airflow.dag_processing.bundles.local.LocalDagBundle",
"kwargs": {}
}
]

Bundle bawaan tersebut berupa LocalDagBundle yang membaca folder yang ditunjuk kunci core.dags_folder, dan folder itu sendiri dapat diperiksa dengan perintah berikut.

bash

# baca folder DAG yang efektif
export AIRFLOW_HOME=/tmp/ra-topologi-deployment
airflow config get-value core dags_folder

text Keluaran

/tmp/ra-topologi-deployment/dags

Dokumentasi deployment menegaskan satu sifat penting, yaitu LocalDagBundle tidak mendukung versioning sehingga task selalu menjalankan kode terbaru yang ada di disk. Untuk versioning, Airflow menyediakan bundle dari provider. GitDagBundle melakukan checkout repository Git dan mendukung versioning, sedangkan S3DagBundle membaca bucket penyimpanan objek dan tidak mendukung versioning. Konfigurasi bundle terdapat pada kunci [dag_processor] dag_bundle_config_list, dan bundle Git membutuhkan tracking_ref yang dapat berupa branch, tag, atau commit.

Alur CI/CD untuk DAG#

CI/CD adalah mekanisme yang menjalankan pengujian secara otomatis pada setiap perubahan, lalu menerapkannya ke lingkungan secara berurutan. Diagram berikut memperlihatkan alurnya. Push ke repository memicu CI yang menjalankan lint dan uji. Hasil CI diterbitkan sebagai bundle versi tag, bundle tersebut disinkronkan ke staging, lalu dipromosikan ke production melalui persetujuan manual.

Alur deployment DAG dari repository menuju staging dan production

Tahap CI menjalankan tiga pemeriksaan minimum sebelum kode dianggap layak. Ketiganya adalah lint terhadap gaya dan kesalahan umum Python, unit test terhadap logika task, dan uji integritas yang mem-parse seluruh berkas DAG agar tidak ada yang gagal dimuat. Sinkronisasi ke staging berlangsung otomatis setelah CI berhasil, sedangkan promosi ke production menunggu persetujuan manual atau tag rilis. Contoh perintah sinkronisasinya sebagai berikut.

bash

# tidak-dijalankan
# sinkronisasi bundle ke staging setelah CI hijau
rsync -av --delete dags/ staging-host:/opt/airflow/bundles/pipeline-data/

bash

# tidak-dijalankan
# promosi ke production ditandai dengan tag rilis di repository
git tag rilis-2026-11-04
git push origin rilis-2026-11-04

Strategi rollback#

Rollback adalah pengembalian kode DAG ke versi sebelumnya ketika versi baru terbukti bermasalah. Prinsipnya, rollback berlangsung dengan cara yang sama dengan deployment, yaitu menerapkan versi yang sudah ada, bukan menyunting berkas langsung di server. Tag rilis pada repository membuat setiap versi dapat diambil kembali melalui nama tag-nya.

Bentuk bundle menentukan cara rollback dilakukan. Dengan GitDagBundle, setiap dag run mencatat commit Git tempat dag run itu dibuat, sehingga eksekusi ulang menggunakan kode yang persis sama meskipun repository sudah berubah. Rollback cukup menggeser tracking_ref ke tag sebelumnya. Dengan LocalDagBundle yang tidak memiliki versioning, rollback dilakukan dengan mengembalikan isi folder bundle ke salinan versi sebelumnya, misalnya dari arsip per rilis yang disiapkan pipeline deployment.

Kesalahan umum#

Menyalin berkas DAG langsung ke folder production tanpa melewati CI. Kode yang belum diuji dapat membuat seluruh berkas DAG gagal diparse karena satu kesalahan sintaks. Terapkan aturan bahwa folder bundle hanya berubah melalui mekanisme deployment yang sudah menjalankan pengujian.

Mengubah Variables atau Connections di UI production tanpa mencatatnya di repository. Konfigurasi yang menyimpang dari catatan menyulitkan forensik ketika pipeline berperilaku berbeda antar lingkungan. Catat perubahan konfigurasi sebagai bagian dari proses deployment.

Menyatukan dev, staging, dan production dalam satu pemasangan Airflow. Keputusan berbahaya dapat diuji langsung pada data asli, dan basis data metadata yang sama membebani production dengan eksperimen. Pisahkan paling tidak basis data metadata dan konfigurasinya.

Ringkasan#

Kode DAG, pengujian, dan konfigurasi Airflow dikelola terpisah karena siklus perubahan dan hak aksesnya berbeda.
Airflow 3 memuat DAG dari bundle, dengan LocalDagBundle menunjuk folder DAG dan GitDagBundle menambahkan versioning berbasis commit.
CI menjalankan lint, unit test, dan uji integritas DAG sebelum bundle diterapkan ke staging, lalu promosi ke production berlangsung terkontrol.
Rollback memanfaatkan versi yang sudah ada, baik melalui tag Git maupun salinan folder bundle per rilis.

Referensi#

DAG Bundles — Apache Airflow — Menjelaskan konsep bundle, jenis bawaannya, dan konfigurasinya.
Production Deployment — Apache Airflow — Membahas kebutuhan deployment Airflow pada lingkungan produksi.
Best Practices — Apache Airflow — Merangkum praktik penyusunan dan penyebaran DAG yang disarankan.
Bundles — Apache Airflow Providers Git — Merinci opsi GitDagBundle termasuk versioning berbasis commit.