CI/CD dalam Rekayasa Data: Panduan untuk Deployment Tanpa Hambatan

Memulai di bidang rekayasa data tidak mudah. Di ruang kelas, dan bahkan kursus online, Anda menguasai dasar-dasar penulisan Python dan SQL. Anda mungkin juga mempelajari sedikit tentang kerangka kerja dan alat seperti Airflow, Databricks, dan Snowflake. 

Menulis kode yang berjalan itu satu hal. Hal lain adalah menulis pengujian untuk kode ini dan mengirimkannya ke produksi agar berjalan di lingkungan perusahaan. Untungnya, rekayasa perangkat lunak sudah menemukan caranya, dan rekayasa data mulai menyusul. 

Bagaimana mereka melakukannya, Anda mungkin bertanya? CI/CD. Bagaimana kita tahu kode akan berjalan di “alam liar”? Bagaimana kita tahu kode itu tidak rusak? Bagaimana kita mengirim kode final untuk dijalankan di produksi setelah disetujui? Dalam artikel ini, kita membahas CI/CD dalam rekayasa data. Kami juga memiliki panduan terpisah tentang CI/CD dalam pembelajaran mesin. 

Apa itu CI/CD?

CI/CD adalah singkatan dari continuous integration, continuous delivery/deployment. Saat ini, itu mungkin belum terlalu berarti bagi Anda; mari kita uraikan lebih lanjut.

Continuous integration

Continuous integration adalah proses secara berkala menggabungkan perubahan kode ke repositori pusat. Misalnya, katakanlah Anda berhasil mengubah sebuah fungsi Python di basis kode pipeline data tim rekayasa Anda. Continuous integration menyatakan bahwa kode ini kemudian harus dibawa kembali ke repositori pusat. 

Namun, ada hal lain yang perlu diperhatikan. Kode ini harus dilacak dengan semacam alat kontrol versi (seperti git) dan diuji menggunakan unit test dan integration test setiap kali ada perubahan baru. Ini memungkinkan dua hal; pertama, memastikan perubahan terbaru pada basis kode tersedia bagi semua pengguna lain, dan kedua, memvalidasi bahwa perubahan kode benar-benar bekerja seperti yang diharapkan.

Continuous delivery

Setelah Anda menggabungkan kode kembali ke basis kode pusat dan mengujinya, bagaimana kode tersebut masuk ke produksi? Di situlah CD berperan. CD adalah singkatan dari continuous delivery/deployment (kita gunakan istilah continuous delivery), dan merupakan praktik menerapkan perubahan pada kode secara otomatis. 

Sebagian orang mungkin berpendapat bahwa unit test dan integration test adalah bagian dari continuous deployment, tetapi terlepas dari itu, hanya kode yang telah divalidasi yang akan dikirim ke produksi

Dibuat menggunakan Napkin.AI

Jadi, jika digabungkan, CI/CD adalah proses ujung-ke-ujung untuk memastikan kode berfungsi (continuous integration) sebelum mengirimkannya ke produksi (continuous delivery) secara otomatis. Untuk menerapkan CI/CD, kita perlu menggunakan pipeline CI/CD, yang akan kita bahas lebih jauh berikutnya.

CI/CD dalam Rekayasa Data

Praktik terbaik rekayasa data bergerak semakin mendekati pedoman yang telah diterapkan oleh rekayasa perangkat lunak. Tugas seperti mengembangkan dan menjalankan unit test serta menjaga lingkungan pengujian/QA khusus tidak lagi hanya menjadi ranah rekan-rekan rekayasa perangkat lunak. Ini termasuk CI/CD.

Anda tidak perlu mencari jauh untuk menemukan use case pada tumpukan rekayasa data untuk CI/CD. Berikut hanya beberapa use case umum:

• Mengepak pekerjaan Databricks menggunakan “Asset Bundles”
• Mengirim perubahan yang dibuat pada DAG Airflow ke produksi
• Merilis endpoint baru untuk REST API yang mengekspos data kepada konsumen data internal dan eksternal
• Memperbarui job dbt yang digunakan untuk menyiapkan data bagi laporan harian

Menambahkan CI/CD ke siklus pengembangan “rekayasa data” memiliki banyak keuntungan, termasuk tata kelola atas kualitas kode yang dikirim ke produksi, dan pengurangan upaya manual untuk merilis perubahan tersebut. 

CI/CD juga menawarkan lapisan visibilitas ke langkah-langkah yang dilakukan dalam setiap rilis dan dapat membatasi akses terhadap tindakan tertentu hanya untuk sekelompok individu tertentu.

Pipeline CI/CD

Untuk melakukan CI/CD, Anda perlu menggunakan pipeline CI/CD. Pipeline CI/CD adalah serangkaian langkah yang dijalankan untuk menguji (CI) dan menerapkan (CD) kode ke produksi setelah kode tersebut dikembalikan ke repositori pusat. Berikut sekilas seperti apa bentuk pipeline CI/CD.

Pipeline CI/CD biasanya terdiri dari tiga langkah; mengonfigurasi lingkungan build/deployment, menjalankan pengujian, dan mengirim kode ke produksi.

Biasanya, ada tiga jenis operasi dalam pipeline CI/CD. Pertama, lingkungan yang diperlukan untuk menguji dan menerapkan kode harus dikonfigurasi di tempat pipeline dijalankan. Ini dapat mencakup tugas seperti memasang CLI, mengambil secret, dan yang terpenting, menarik turun basis kode yang baru diperbarui.

Setelah menyiapkan lingkungan, kode yang akan dirilis harus diuji. Di sinilah unit test dan integration test dijalankan terhadap basis kode yang baru diperbarui. Setelah lulus setiap test case, kode yang diperbarui dapat diterapkan ke produksi.

Alat untuk CI/CD

Mencari alat untuk menjalankan pipeline CI/CD Anda? Untungnya, ada banyak! Dari penawaran open-source hingga layanan terkelola penuh, tidak kekurangan opsi untuk mengorkestrasi proses CI/CD Anda. Berikut beberapa alat CI/CD paling populer saat ini.

GitHub Actions

Saat Anda memikirkan kontrol versi, kemungkinan Anda memikirkan GitHub. GitHub adalah salah satu tempat paling populer untuk menyimpan kode Anda, dan karena itu, salah satu yang paling menarik untuk mengelola pipeline CI/CD Anda. 

GitHub Actions adalah penawaran CI/CD terkelola penuh yang memungkinkan pengguna GitHub mengembangkan, menjalankan, dan mengelola pipeline CI/CD mereka. Pipeline didefinisikan menggunakan file YAML yang biasanya dipicu oleh sebuah aksi seperti push ke cabang tertentu atau pull request yang digabungkan. Menggunakan GitHub Actions memungkinkan pengalaman pengembang yang terpadu, serta satu panel kendali terpusat untuk kontrol versi dan manajemen rilis.

Jenkins

Di sisi lain spektrum adalah Jenkins. Jenkins adalah penawaran CI/CD open-source yang memudahkan untuk membangun dan memelihara pipeline kustom dan sering dianggap sebagai standar industri untuk CI/CD. 

Jenkins menawarkan lapisan ekstensi tambahan, termasuk plugin siap pakai dan dukungan untuk arsitektur terdistribusi. Dengan Jenkins, jika Anda bisa membayangkannya, kemungkinan Anda bisa membangunnya. Namun, dengan kustomisasi ini datang tanggung jawab, termasuk tingkat pengelolaan tertentu terhadap Jenkins itu sendiri.

Berbeda dengan GitHub Actions, Jenkins adalah program yang harus di-host dan dikelola oleh penggunanya sendiri. Untuk melakukan ini, tim rekayasa data perlu mengonfigurasi dan mengelola hal-hal seperti server Jenkins, build agent, akses keamanan, integrasi dengan klien kontrol versi, dan lingkungan runtime Java. Ini berarti overhead yang signifikan, dan mungkin tidak masuk akal untuk tim yang lebih kecil.

Penyedia cloud besar

Bagi tim rekayasa data yang sudah berada di cloud, menggunakan solusi CI/CD dari penyedia cloud mereka sering kali sangat menarik. AWS menawarkan alat seperti CodeBuild dan CodePipeline. Azure mendukung DevOps dan Pipelines, dan GCP menyediakan Cloud Build. 

Biasanya, aplikasi dalam lingkungan cloud yang sudah ada tidak perlu melalui proses pengadaan dan tidak memerlukan komitmen belanja. Alat-alat ini sering kali intuitif bagi data engineer yang terbiasa bekerja di cloud dan mudah untuk mulai digunakan.

Praktik Terbaik CI/CD

Saat mengonfigurasi alur kerja CI/CD Anda sendiri, ada beberapa praktik terbaik yang membantu menjadikan pengalaman lebih mulus. Pertama, kontrol versi.

Kontrol versi

Melacak kode Anda menggunakan kontrol versi adalah langkah pertama untuk membangun platform data yang tangguh. Alat kontrol versi (seperti git) tidak hanya memungkinkan kode dilacak, tetapi juga versi produksi dari kode tersebut dipertahankan. Klien kontrol versi (pikirkan GitHub) kemudian dapat digunakan untuk memicu pipeline CI/CD ketika sebuah peristiwa tertentu terjadi.

Berikut contoh alur kerja; Anda adalah seorang data engineer yang ditugaskan membuat workflow ETL baru. Untuk melakukannya, Anda checkout cabang fitur dan membuat perubahan pada cabang tersebut. Ketika Anda siap untuk mendorong perubahan ini ke produksi, Anda akan menggabungkan cabang fitur ke cabang main, yang kemudian akan memicu pipeline CI/CD, menerapkan kode Anda ke produksi.

Visibilitas

Tidak selalu memungkinkan untuk menambahkan visibilitas ke pipeline CI/CD, tetapi ketika memungkinkan, penting untuk melakukannya. Bergantung pada alat CI/CD yang Anda gunakan, Anda dapat memecah setiap langkah dalam pipeline menjadi satu tugas. Lalu, jika salah satu tugas ini gagal, mudah untuk mengidentifikasi dan memulai remediasi. Jika Anda menggunakan GitHub Actions untuk menjalankan pipeline CI/CD, cobalah memisahkan konfigurasi lingkungan, pengujian, dan langkah deployment menjadi tiga tugas berbeda.

Sama pentingnya dengan visibilitas ke eksekusi pipeline adalah dokumentasi. Menambahkan catatan tentang bagaimana pipeline dipicu, pengujian yang dijalankan terhadap basis kode, dan target deployment membantu mempercepat proses pemecahan masalah

Lindungi secret Anda

Kemungkinan besar, Anda akan perlu menggunakan semacam kata sandi atau kunci untuk menerapkan basis kode Anda setelah diuji. Penting untuk tidak pernah menyimpan data sensitif ini dalam konfigurasi pipeline CI/CD itu sendiri (melakukannya adalah cara pasti membuat tim keamanan Anda pusing). Sebagai gantinya, manfaatkan alat CI/CD Anda untuk menyimpan dan mereferensikan secret ini sebagai variabel. Dengan alat seperti AWS CodeBuild, nilai sensitif dapat disimpan di luar definisi pipeline menggunakan environment variable, yang kemudian direferensikan dengan aman.

Gunakan lebih dari satu lingkungan

Sejauh ini, kita hanya membahas penggunaan pipeline CI/CD untuk mendorong kode ke produksi. Namun, proses pengembangan kelas perusahaan terlihat sedikit berbeda. Alih-alih langsung mendorong ke produksi ketika ada perubahan kode, data engineer biasanya mendorong kode ke lingkungan pengujian khusus. 

Ini memungkinkan mereka menguji solusi secara manual, memastikan hasilnya sesuai harapan. Untuk melakukannya, cabang test dan main akan dipertahankan menggunakan kontrol versi, masing-masing memicu job CI/CD yang sedikit berbeda ketika suatu peristiwa tertentu terjadi.

Kesimpulan

Ya, CI/CD bisa jadi rumit. Dan ya, mungkin perlu waktu untuk dikonfigurasi pada awalnya. Namun CI/CD adalah investasi untuk memungkinkan rilis kode yang tertata dan efisien ke lingkungan produksi. Meluangkan waktu di awal untuk mengembangkan pipeline CI/CD membantu mengurangi waktu manual yang dihabiskan untuk menguji perubahan kode dan mengemasi kode untuk dikirim ke produksi.

Memahami dan menerapkan CI/CD adalah salah satu cara tercepat untuk meningkatkan karier Anda; jika Anda dapat membangun proyek di Python atau SQL, Anda telah mengembangkan keterampilan dasar yang solid sebagai seorang data engineer. Namun, jika Anda dapat membangun alur kerja CI/CD dengan test case yang dieksekusi setiap kali ada perubahan, dan mengotomatisasi dorongan ke produksi, Anda telah menunjukkan bahwa Anda siap membangun solusi kelas perusahaan.

Mulai jalur Anda menjadi data engineer hari ini dengan Data Engineer in Python career track dan Sertifikasi Karier Data Engineer dari DataCamp.