Apa itu CI / CD? Integrasi berkelanjutan dan pengiriman berkelanjutan dijelaskan

Integrasi berkelanjutan (CI) dan pengiriman berkelanjutan (CD) mewujudkan budaya, serangkaian prinsip operasi, dan kumpulan praktik yang memungkinkan tim pengembangan aplikasi untuk mengirimkan perubahan kode lebih sering dan andal. Implementasinya juga dikenal sebagai pipeline CI / CD

CI / CD adalah salah satu praktik terbaik untuk diterapkan oleh tim developer. Ini juga merupakan praktik terbaik metodologi tangkas, karena memungkinkan tim pengembangan perangkat lunak untuk fokus pada pemenuhan persyaratan bisnis, kualitas kode, dan keamanan karena langkah-langkah penerapan diotomatiskan.

CI / CD ditentukan

Integrasi berkelanjutan  adalah filosofi pengkodean dan serangkaian praktik yang mendorong tim pengembangan untuk menerapkan perubahan kecil dan sering memeriksa kode ke repositori kontrol versi. Karena sebagian besar aplikasi modern memerlukan pengembangan kode di platform dan alat yang berbeda, tim memerlukan mekanisme untuk mengintegrasikan dan memvalidasi perubahannya.

Tujuan teknis CI adalah menetapkan cara yang konsisten dan otomatis untuk membangun, mengemas, dan menguji aplikasi. Dengan konsistensi dalam proses integrasi, tim lebih cenderung melakukan perubahan kode lebih sering, yang mengarah pada kolaborasi dan kualitas perangkat lunak yang lebih baik.

Pengiriman berkelanjutan  mengambil tempat integrasi berkelanjutan berakhir. CD mengotomatiskan pengiriman aplikasi ke lingkungan infrastruktur yang dipilih. Sebagian besar tim bekerja dengan banyak lingkungan selain lingkungan produksi, seperti lingkungan pengembangan dan pengujian, dan CD memastikan ada cara otomatis untuk mendorong perubahan kode ke mereka.

Alat CI / CD membantu menyimpan parameter khusus lingkungan yang harus dikemas dengan setiap pengiriman. Otomatisasi CI / CD kemudian melakukan panggilan layanan apa pun yang diperlukan ke server web, database, dan layanan lain yang mungkin perlu dimulai ulang atau mengikuti prosedur lain saat aplikasi diterapkan.

Integrasi berkelanjutan dan pengiriman berkelanjutan memerlukan  pengujian berkelanjutan  karena tujuannya adalah untuk memberikan aplikasi dan kode berkualitas kepada pengguna. Pengujian berkelanjutan sering kali diterapkan sebagai rangkaian regresi otomatis, performa, dan pengujian lain yang dijalankan di pipeline CI / CD.

Praktik pengembang CI / CD yang matang memiliki opsi untuk mengimplementasikan penerapan berkelanjutan di mana perubahan aplikasi dijalankan melalui pipeline CI / CD dan meneruskan build diterapkan langsung ke lingkungan produksi. Tim yang mempraktikkan pengiriman berkelanjutan memilih untuk menerapkan ke produksi pada jadwal harian atau bahkan per jam, meskipun pengiriman berkelanjutan tidak selalu optimal untuk setiap aplikasi bisnis.  

Video terkait: Cara mengirimkan kode lebih cepat dengan CI / CD

Bagaimana integrasi berkelanjutan meningkatkan kolaborasi dan kualitas

Integrasi berkelanjutan adalah filosofi pengembangan yang didukung oleh mekanisme proses dan beberapa otomatisasi. Saat mempraktikkan CI, pengembang sering memasukkan kode mereka ke dalam repositori kontrol versi dan sebagian besar tim memiliki standar minimal untuk memasukkan kode setidaknya setiap hari. Alasan di balik ini adalah bahwa lebih mudah untuk mengidentifikasi cacat dan masalah kualitas perangkat lunak lainnya pada perbedaan kode yang lebih kecil daripada yang lebih besar yang dikembangkan selama periode waktu yang lama. Selain itu, ketika pengembang mengerjakan siklus komit yang lebih pendek, kecil kemungkinannya bagi beberapa pengembang untuk mengedit kode yang sama dan memerlukan penggabungan saat melakukan.

Tim yang menerapkan integrasi berkelanjutan sering kali memulai dengan konfigurasi kontrol versi dan definisi praktik. Meskipun pemeriksaan kode sering dilakukan, fitur dan perbaikan diterapkan pada kerangka waktu yang pendek dan panjang. Tim pengembang yang mempraktikkan integrasi berkelanjutan menggunakan teknik yang berbeda untuk mengontrol fitur dan kode apa yang siap untuk produksi.

Banyak tim menggunakan tanda fitur , mekanisme konfigurasi untuk mengaktifkan atau menonaktifkan fitur dan kode pada waktu proses. Fitur yang masih dalam pengembangan dibungkus dengan tanda fitur dalam kode, disebarkan dengan cabang master ke produksi, dan dinonaktifkan hingga siap digunakan. Menurut survei terbaru, 63 persen tim yang menggunakan tanda fitur melaporkan pengujian yang lebih baik dan perangkat lunak berkualitas lebih tinggi. Alat penandaan fitur seperti CloudBees Rollout, Optimizely Rollouts, dan LaunchDarkly terintegrasi dengan alat CI / CD dan mengaktifkan konfigurasi tingkat fitur.

Teknik lain untuk mengelola fitur adalah  percabangan kontrol versi . Strategi percabangan seperti Gitflow dipilih untuk menentukan protokol tentang bagaimana kode baru digabungkan menjadi cabang standar untuk pengembangan, pengujian, dan produksi. Cabang fitur tambahan dibuat untuk cabang yang membutuhkan siklus pengembangan lebih lama. Saat fitur selesai, pengembang kemudian dapat menggabungkan perubahan dari cabang fitur ke cabang pengembangan utama. Pendekatan ini berfungsi dengan baik, tetapi dapat menjadi sulit untuk dikelola jika ada banyak fitur yang dikembangkan secara bersamaan.

Proses build itu sendiri kemudian diotomatiskan dengan mengemas semua perangkat lunak, database, dan komponen lainnya. Misalnya, jika Anda mengembangkan aplikasi Java, CI akan mengemas semua file server web statis seperti HTML, CSS, dan JavaScript bersama dengan aplikasi Java dan skrip database apa pun.

CI tidak hanya mengemas semua komponen perangkat lunak dan database, tetapi otomatisasi juga akan menjalankan pengujian unit dan pengujian lainnya. Pengujian ini memberikan umpan balik kepada pengembang bahwa perubahan kode mereka tidak merusak pengujian unit yang ada.

Sebagian besar alat CI / CD memungkinkan pengembang memulai build sesuai permintaan, dipicu oleh kode komit di repositori kontrol versi, atau pada jadwal yang ditentukan. Tim perlu mendiskusikan jadwal build yang paling sesuai untuk ukuran tim, jumlah komitmen harian yang diharapkan, dan pertimbangan aplikasi lainnya. Praktik terbaik untuk memastikan bahwa commit dan build cepat, jika tidak, hal itu dapat menghambat kemajuan tim yang mencoba membuat kode dengan cepat dan sering berkomitmen.

Pengujian berkelanjutan melampaui otomatisasi pengujian

Kerangka kerja pengujian otomatis membantu teknisi jaminan kualitas menentukan, mengeksekusi, dan mengotomatiskan berbagai jenis pengujian yang dapat membantu tim pengembangan mengetahui apakah pembuatan perangkat lunak berhasil atau gagal. Ini mencakup uji fungsionalitas yang dikembangkan di akhir setiap sprint dan digabungkan menjadi uji regresi untuk keseluruhan aplikasi. Tes regresi ini kemudian menginformasikan tim apakah perubahan kode gagal pada satu atau lebih tes yang dikembangkan di semua area fungsional aplikasi di mana ada cakupan tes.

Praktik terbaiknya adalah mengaktifkan dan mewajibkan developer untuk menjalankan semua atau sebagian pengujian regresi di lingkungan lokalnya. Langkah ini memastikan bahwa pengembang hanya memasukkan kode ke kontrol versi setelah uji regresi meneruskan perubahan kode.

Tes regresi hanyalah permulaan. Pengujian kinerja, pengujian API, analisis kode statis, pengujian keamanan, dan formulir pengujian lainnya juga dapat diotomatiskan. Kuncinya adalah dapat memicu pengujian ini baik melalui baris perintah, webhook, atau layanan web dan mereka merespons dengan kode status berhasil atau gagal.

Setelah pengujian diotomatiskan, pengujian berkelanjutan menyiratkan bahwa otomatisasi diintegrasikan ke dalam pipeline CI / CD. Beberapa pengujian unit dan fungsionalitas dapat diintegrasikan ke dalam CI yang menandai masalah sebelum atau selama proses integrasi. Pengujian yang memerlukan lingkungan pengiriman lengkap seperti pengujian performa dan keamanan sering kali diintegrasikan ke dalam CD dan dilakukan setelah build dikirim ke lingkungan target.

Pipa CD mengotomatiskan perubahan ke beberapa lingkungan

Pengiriman berkelanjutan adalah otomatisasi yang mendorong aplikasi ke lingkungan pengiriman. Sebagian besar tim pengembangan biasanya memiliki satu atau beberapa lingkungan pengembangan dan pengujian tempat perubahan aplikasi dilakukan untuk pengujian dan peninjauan. Alat CI / CD seperti Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, atau Travis CI digunakan untuk mengotomatiskan langkah-langkah dan menyediakan pelaporan.

Pipeline CD tipikal memiliki tahapan build, test, dan deploy. Jaringan pipa yang lebih canggih mencakup banyak dari langkah-langkah berikut:

  • Menarik kode dari kontrol versi dan menjalankan build.
  • Menjalankan langkah infrastruktur yang diperlukan yang diotomatiskan sebagai kode untuk berdiri atau menghancurkan infrastruktur cloud.
  • Memindahkan kode ke lingkungan komputasi target.
  • Mengelola variabel lingkungan dan mengonfigurasinya untuk lingkungan target.
  • Mendorong komponen aplikasi ke layanan yang sesuai, seperti server web, layanan API, dan layanan database.
  • Menjalankan langkah apa pun yang diperlukan untuk memulai ulang layanan atau memanggil titik akhir layanan yang diperlukan untuk dorongan kode baru.
  • Menjalankan pengujian berkelanjutan dan lingkungan rollback jika pengujian gagal.
  • Memberikan data log dan peringatan tentang status pengiriman.

Sebagai contoh, pengguna Jenkins menentukan pipeline mereka dalam Jenkinsfile yang mendeskripsikan tahapan berbeda seperti build, test, dan deploy. Variabel lingkungan, opsi, kunci rahasia, sertifikasi, dan parameter lainnya dideklarasikan dalam file dan kemudian direferensikan secara bertahap. Bagian posting menangani kondisi kesalahan dan pemberitahuan.  

CD yang lebih canggih mungkin memiliki langkah lain seperti melakukan sinkronisasi data, mengarsipkan sumber informasi, atau melakukan patch aplikasi dan perpustakaan. Alat CI / CD biasanya mendukung pasar plug-in. Misalnya, Jenkins mencantumkan lebih dari 1.500 plugin yang mendukung integrasi dengan platform pihak ketiga, antarmuka pengguna, administrasi, pengelolaan kode sumber, dan pengelolaan build.

Setelah alat CI / CD dipilih, tim pengembangan harus memastikan bahwa semua variabel lingkungan dikonfigurasi di luar aplikasi. Alat CI / CD memungkinkan pengaturan variabel ini, menutupi variabel seperti kata sandi dan kunci akun, dan mengonfigurasinya pada saat penerapan untuk lingkungan target.

Alat CD juga menyediakan fungsi dasbor dan pelaporan. Jika pembuatan atau pengiriman gagal, mereka memperingatkan pengembang dengan informasi tentang kegagalan. Mereka berintegrasi dengan kontrol versi dan alat tangkas, sehingga mereka dapat digunakan untuk mencari perubahan kode dan cerita pengguna apa yang membentuk sebuah build.

Mengimplementasikan pipeline CI / CD dengan Kubernetes dan arsitektur tanpa server 

Banyak tim yang mengoperasikan pipeline CI / CD di lingkungan cloud juga menggunakan container seperti Docker dan sistem orkestrasi seperti Kubernetes. Container memungkinkan untuk aplikasi pengemasan dan pengiriman dengan cara standar dan portabel. Penampung memudahkan untuk meningkatkan atau menghancurkan lingkungan yang memiliki beban kerja variabel.

Ada banyak pendekatan untuk menggunakan container, infrastruktur sebagai kode, dan pipeline CI / CD secara bersamaan. Anda dapat menjelajahi opsi dengan mempelajari tutorial seperti Kubernetes dengan Jenkins atau Kubernetes dengan Azure DevOps.

Arsitektur komputasi tanpa server menghadirkan jalan lain untuk menerapkan dan menskalakan aplikasi. Dalam lingkungan tanpa server, infrastruktur sepenuhnya dikelola oleh penyedia layanan cloud dan aplikasi menggunakan sumber daya sesuai kebutuhan berdasarkan konfigurasinya. Di AWS misalnya, aplikasi tanpa server yang dijalankan sebagai fungsi Lambda dan penerapan dapat diintegrasikan ke dalam pipeline CI / CD Jenkins dengan plug-in. 

CI / CD memungkinkan penerapan kode yang lebih sering

Ringkasnya, CI mengemas dan menguji build perangkat lunak dan memberi tahu pengembang jika perubahan mereka gagal dalam pengujian unit apa pun. CD adalah otomatisasi yang mengirimkan perubahan ke infrastruktur dan menjalankan pengujian tambahan. 

Pipeline CI / CD dirancang untuk bisnis yang ingin sering meningkatkan aplikasi dan membutuhkan proses pengiriman yang andal. Upaya tambahan untuk menstandardisasi build, mengembangkan pengujian, dan mengotomatiskan penerapan adalah proses manufaktur untuk menerapkan perubahan kode. Setelah di tempat, ini memungkinkan tim untuk fokus pada proses peningkatan aplikasi dan lebih sedikit pada detail sistem untuk mengirimkannya ke lingkungan komputasi.

CI / CD adalah praktik terbaik pengembang karena mengatasi ketidakselarasan antara pengembang yang ingin sering mendorong perubahan, dengan operasi yang menginginkan aplikasi stabil. Dengan adanya otomatisasi, pengembang dapat mendorong perubahan lebih sering. Tim operasi melihat stabilitas yang lebih baik karena lingkungan memiliki konfigurasi standar, ada pengujian berkelanjutan dalam proses pengiriman, variabel lingkungan dipisahkan dari aplikasi, dan prosedur rollback diotomatiskan.

Dampak penerapan pipeline CI / CD dapat diukur sebagai indikator kinerja utama (KPI) devops. KPI seperti frekuensi penerapan, perubahan waktu tunggu, dan waktu rata-rata untuk pemulihan (MTTR) dari suatu insiden sering kali ditingkatkan ketika CI / CD dengan pengujian berkelanjutan diterapkan. Namun, CI / CD hanyalah satu proses yang dapat mendorong peningkatan ini, dan ada prasyarat lain untuk meningkatkan frekuensi penerapan.

Memulai CI / CD membutuhkan tim pengembangan dan tim operasional untuk berkolaborasi dalam teknologi, praktik, dan prioritas. Tim perlu mengembangkan konsensus tentang pendekatan yang tepat untuk bisnis dan teknologi mereka sehingga setelah CI / CD diterapkan, tim akan siap dengan praktik berikut secara konsisten.