Apa itu continuous integration/continuous delivery (CI/CD)?

Karakteristik penting dari pipeline CI/CD adalah penggunaan otomatisasi guna membantu memastikan kualitas kode. Seiring kemajuan perubahan perangkat lunak melalui pipeline, pengujian otomatis mengidentifikasi dependensi dan masalah lainnya sebelumnya, mendorong perubahan kode ke lingkungan yang berbeda dan mengirimkan aplikasi ke lingkungan produksi.

Di sini, peran otomatisasi adalah melakukan kontrol kualitas, menilai segala sesuatu mulai dari kinerja hingga penggunaan antarmuka pemrograman aplikasi (API) dan keamanan. Proses ini membantu memastikan perubahan yang dibuat oleh semua anggota tim terintegrasi secara komprehensif dan dilakukan sebagaimana dimaksud.

Kemampuan untuk mengotomatiskan berbagai fase pipeline CI/CD membantu tim pengembangan meningkatkan kualitas, bekerja lebih cepat, dan meningkatkan metrik DevOps lainnya.

Sementara pipeline CI/CD mengacu pada alur kerja DevOps yang tangkas, CI/CD adalah singkatan dari praktik gabungan integrasi berkelanjutan dan pengiriman berkelanjutan.

CI/CD menciptakan cara yang lebih cepat dan lebih tepat untuk menggabungkan pekerjaan orang yang berbeda menjadi 1 produk kohesif. Di lingkungan DevOps, CI/CD merampingkan proses pengodean, pengujian, dan penerapan aplikasi. Pendekatan ini memberi tim repositori tunggal untuk menyimpan alat kerja dan otomatisasi untuk menggabungkan dan menguji kode untuk membantu memastikannya bekerja secara konsisten.

Pipeline CI/CD memungkinkan tim DevOps untuk menulis kode, mengintegrasikannya, menjalankan pengujian, mengirimkan rilis, dan menerapkan perubahan ke perangkat lunak secara kolaboratif dan real-time. Sementara otomatisasi rilis perangkat lunak—dari pengujian awal hingga penerapan akhir—merupakan manfaat signifikan dari pipeline CI/CD, manfaat lainnya meliputi:

• Mengurangi waktu penerapan: Pengujian otomatis membuat proses pengembangan lebih efisien, mengurangi lamanya proses pengiriman perangkat lunak. Selain itu, penerapan berkelanjutan dan penyediaan otomatis memungkinkan perubahan pengembang ke aplikasi cloud untuk ditayangkan dalam beberapa menit setelah menulisnya.

• Penurunan biaya: Pengembangan, pengujian, dan produksi yang cepat (difasilitasi oleh otomatisasi) berarti lebih sedikit waktu yang dihabiskan untuk pengembangan. Proses ini hasil dalam pengurangan biaya dibandingkan dengan pengembangan perangkat lunak tradisional.

• Lingkaran masukan berkelanjutan: Pipeline CI/CD mewakili siklus berkelanjutan: membangun, menguji, menerapkan. Lingkaran masukan memungkinkan pengembang untuk bertindak dan meningkatkan kode dengan cepat setiap kali setelah kode tersebut diuji.

• Deteksi kesalahan awal: Dalam integrasi berkelanjutan, pengujian otomatis untuk setiap versi kode yang dibuat untuk mencari masalah dalam integrasi. Masalah-masalah ini lebih mudah perbaikan semakin awal terjadi dalam pipeline.

• Mengurangi waktu henti dan meningkatkan keandalan: Jika terjadi kegagalan penerapan, bug, atau masalah kinerja, fitur seperti rollback otomatis mengembalikan sistem perangkat lunak atau aplikasi ke keadaan stabil sebelumnya. Fitur ini meminimalkan waktu henti dan meningkatkan keandalan layanan.

• Peningkatan kolaborasi tim dan integrasi sistem: Setiap orang di tim dapat mengubah kode, menanggapi masukan, dan dengan cepat menanggapi masalah apa pun.

Pipeline CI/CD terdiri atas 3 metodologi yang terhubung:

• Integrasi berkelanjutan
• Pengiriman berkelanjutan
• Penerapan berkelanjutan

Proses CI/CD dimulai dengan integrasi berkelanjutan (CI), di mana pengembang menyerahkan kode mereka ke repositori pusat yang dikelola oleh sistem kontrol versi (VCS). CI memungkinkan pengembang untuk bekerja secara mandiri, membuat “cabang” pengodean mereka sendiri untuk menerapkan perubahan kecil.

Saat pengembang bekerja, mereka dapat mengambil snapshot dari kode sumber, biasanya dalam alat versi seperti Git. Pengembang kemudian bebas untuk mengerjakan fitur baru; jika masalah muncul, Git dapat dengan cepat mengembalikan basis kode ke keadaan sebelumnya.

Pekerjaan individu kemudian didorong ke dalam sistem otomatis yang menggunakan skrip untuk membangun dan menguji perubahan kode. Setelah tahap build otomatis, server CI mengompilasi perubahan kode sumber ke kode cabang utama atau “trunk” dari repositori kode sumber bersama.

Alih-alih menulis kode secara independen dan mengirimkan ke cabang kode utama sebulan sekali, yang dapat menyebabkan beban pekerjaan memperbaiki bug dan kontrol versi yang buruk, proses pengembangan CI/CD memungkinkan tim Kirim perubahan kode lebih sering.  Pengujian berkelanjutan ini menawarkan perbaikan bug yang lebih cepat, membantu memastikan fungsionalitas, dan pada akhirnya menghasilkan kolaborasi dan kualitas perangkat lunak yang lebih baik.

Langkah selanjutnya dalam pipeline adalah pengiriman berkelanjutan (CD), yang menempatkan perubahan kode yang divalidasi yang dibuat dalam integrasi berkelanjutan ke lingkungan tertentu atau repositori kode, seperti GitHub. Di sini, tim operasi dapat menerapkan mereka ke lingkungan produksi langsung.

Perangkat lunak dan API diuji, dan kesalahan diselesaikan melalui proses otomatis. Pada langkah terakhir dari proses CD, tim DevOps menerima pemberitahuan tentang build terbaru, dan mereka mengirimkannya secara manual ke tahap penerapan.

Tujuan dari tahap delivery pipeline berkelanjutan adalah untuk menerapkan kode baru dengan sedikit usaha, tetapi masih memungkinkan tingkat pengawasan manusia.

CD dalam proses CI/CD juga merupakan singkatan dari penerapan berkelanjutan. Penerapan berkelanjutan secara otomatis merilis perubahan kode ke pengguna akhir setelah melewati serangkaian pengujian yang telah ditentukan sebelumnya, seperti pengujian integrasi yang menguji kode di lingkungan peniru untuk membantu memastikan integritas kode.

Pengiriman berkelanjutan dan penerapan berkelanjutan berhubungan dengan otomatisasi lebih jauh di jalur pipa daripada CI dan sering digunakan secara bergantian.

Perbedaan antara pengiriman berkelanjutan dan penerapan berkelanjutan adalah pada tingkat otomatisasi yang digunakan dalam rilis perangkat lunak atau aplikasi. Dalam pengiriman berkelanjutan, kode secara otomatis pindah ke lingkungan seperti produksi untuk pengujian lebih lanjut dan jaminan kualitas, seperti menilai risiko dan mengidentifikasi kerentanan kode sumber. Intervensi manusia diperlukan untuk pindah ke produksi setelah tes yang berhasil.

Dalam penerapan berkelanjutan, otomatisasi berjalan lebih jauh. Setelah kode lulus pengujian, penerapan ke produksi terjadi secara otomatis—persetujuan manusia tidak diperlukan.

Bagaimana organisasi menerapkan pipeline CI/CD dan memutuskan apakah akan menggunakan pengiriman atau penerapan berkelanjutan bergantung pada kebutuhan bisnisnya. Penerapan berkelanjutan adalah yang terbaik untuk tim DevOps dengan siklus pengembangan yang cepat, seperti yang membangun situs e-commerce dan platform perangkat lunak sebagai layanan (SaaS).

Penerapan berkelanjutan mendukung proses rilis perangkat lunak dengan memungkinkan tim merilis perangkat lunak baru atau yang diperbarui secara sering dan secepat mungkin. Karena perubahan diterapkan ke publik secara otomatis, jenis pipeline penerapan berkelanjutan ini biasanya hanya digunakan oleh tim DevOps yang memiliki proses yang terbukti.

Untuk tim yang mungkin tidak perlu merilis pembaruan sesering dalam alur kerja mereka—seperti untuk mereka yang membangun aplikasi perawatan kesehatan—pengiriman berkelanjutan biasanya merupakan pilihan yang lebih disukai. Langkah ini lebih lambat tetapi menawarkan lapisan pengawasan lain untuk membantu memastikan fungsionalitas bagi pengguna akhir.

Untuk melihat lebih detail perbedaan antara pengiriman berkelanjutan dan penerapan berkelanjutan, silakan tonton video ini.

Pipeline machine learning adalah serangkaian langkah pemrosesan dan pemodelan data yang saling berhubungan yang dirancang untuk mengotomatiskan, menstandardisasikan, dan menyederhanakan proses membangun, melatih, mengevaluasi, dan menerapkan model pembelajaran mesin.

Pipeline machine learning adalah komponen penting dalam pengembangan dan produksi sistem machine learning (ML). Selain itu, peran mereka semakin penting karena pertumbuhan big data dan kecerdasan buatan (AI).

Menurut Kings Research, ukuran pasar machine learning global bernilai 26,06 miliar USD pada tahun 2023 dan diproyeksikan tumbuh dari 35,44 miliar USD pada tahun 2024 menjadi 328,89 miliar USD pada tahun 2031, menunjukkan CAGR 37,47% selama periode perkiraan.¹

Pipeline machine learning terintegrasi dengan praktik DevOps untuk mengaktifkan CI/CD model machine learning. Integrasi ini disebut sebagai operasi machine learning (MLOps), yang membantu tim ilmu data secara efektif mengelola kompleksitas pengelolaan orkestrasi ML.

Dari kode sumber hingga produksi, tahapan ini terdiri atas siklus proses pengembangan dan alur kerja pipa CI/CD:

• Membangun
• Uji
• Menghadirkan
• Menyebarkan

Tahap ini adalah bagian dari proses integrasi berkelanjutan dan melibatkan pembuatan dan kompilasi kode. Tim membangun kode sumber secara kolaboratif dan mengintegrasikan kode baru sambil dengan cepat menentukan masalah atau konflik apa pun.

Pada tahap ini, tim menguji kode. Pengujian otomatis terjadi dalam pengiriman dan penerapan berkelanjutan. Lingkungan pengujian ini mungkin termasuk tes integrasi, pengujian unit, dan tes regresi.

Di sini, basis kode yang disetujui dikirim ke lingkungan produksi. Tahap ini diotomatisasi dalam penerapan berkelanjutan dan hanya diotomatisasi dalam pengiriman berkelanjutan setelah persetujuan pengembang.

Terakhir, perubahan diterapkan, dan produk akhir berpindah ke produksi. Dalam pengiriman berkelanjutan, produk atau kode dikirim ke repositori dan dipindahkan ke produksi atau penerapan dengan persetujuan manusia. Dalam penerapan berkelanjutan, langkah ini diotomatiskan.

Saat memilih alat CI/CD, fokusnya harus pada pengoptimalan dan otomatisasi proses pengembangan perangkat lunak. Pipeline CI/CD yang efektif menggunakan alat sumber terbuka untuk integrasi, pengujian, dan penerapan. Konfigurasi yang benar dari proses CI/CD Anda juga memengaruhi keberhasilan pipeline pengembangan perangkat lunak.

Alat CI/CD sumber terbuka yang paling umum adalah Jenkins. Jenkins adalah server CI otomatis yang ditulis dalam Java yang digunakan untuk mengotomatiskan langkah-langkah dan pelaporan CI/CD. Alat sumber terbuka lainnya untuk Integrasi termasuk Travis CI dan CircleCI.

Selain sumber terbuka, semua penyedia layanan cloud utama — Google Cloud, IBM® Cloud, Microsoft Azure dan Amazon Web Services (AWS) — menawarkan rantai alat CI/CD berbasis cloud, pipeline, dan Integrasi.

Lingkungan pengembangan terintegrasi (IDE), seperti GitHub atau AWS CodeCommit, membantu pengembang membuat, memelihara, dan melacak paket perangkat lunak. Pada saat yang sama, platform seperti GitLab berusaha menyediakan IDE dalam platform komprehensif yang mencakup alat lain.

Saat beroperasi di lingkungan cloud, tim DevOpscloud-native menggunakan kontainer seperti Docker untuk pengemasan dan pengiriman aplikasi, dan mereka menggunakan alat orkestrasi kontainer seperti Kubernetes. Meskipun Kubernetes tidak hanya untuk pipeline CI/CD, Kubernetes digunakan di banyak alur kerja CI/CD.

Keamanan CI/CD berfokus pada praktik, proses, dan teknologi yang menerapkan dan mengelola langkah-langkah keamanan dan kepatuhan di seluruh pipeline CI/CD.

Di masa lalu, keamanan “ditempelkan” ke perangkat lunak pada akhir siklus pengembangan. Kemajuan platform cloud, layanan mikro, dan kontainer menciptakan hambatan bagi pendekatan pengembangan tradisional.

Keamanan mungkin tidak mengikuti rilis cepat karena pengembang mengadopsi praktik tangkas dan DevOps, memacu evolusi DevSecOps, yang merupakan singkatan dari pengembangan, keamanan, dan operasi. DevSecOps mengotomatiskan praktik alat keamanan yang mengintegrasikan saat muncul dalam pipeline integrasi berkelanjutan (CI) dan pengiriman berkelanjutan (CD).

Praktik DevSecOps termasuk pengujian shift-left dan shift-right. Pengujian shift-left melibatkan pengintegrasian pengujian keamanan dan praktik pengembangan penting lainnya di awal siklus pengembangan perangkat lunak (SDLC). Pengujian shift-right melibatkan pengujian di kemudian hari dalam pengembangan, biasanya di lingkungan produksi. Metode-metode ini saling melengkapi dengan menyebarkan tanggung jawab pengujian di seluruh SDLC.