Hidup Tenang Dengan Script CI/CD Yang Rapi

Panduan hidup tenang untuk DevOps. Nomor 60 akan membuat Anda takjub!

DevOps menghilangkan stress. Photo by Erik Brolin on Unsplash

Saya harus akui, build script adalah bagian development yang kurang saya sukai. Build script biasanya sesuatu yang kurang terawat, seringkali panjang dan tidak mudah untuk debug lokal. Namun, dengan sedikit usaha, perencanaan, kesabaran, doa dan banyak waktu untuk coba coba, skrip CI/CD dapat menjadi lebih bersih dan gampang dicerna. Konsepnya gampang, dan tidak perlu menggunakan daftar sampai 60. Berbagai contoh di tulisan ini menggunakan azure pipeline, tapi prinsipnya berlaku untuk semua jenis pipeline.

Bagaimana awalnya

Di masa-masa indah arsitektur monolitik beberapa dekade lalu, tim programmer menulis semua fitur, API, dan jutaan baris kode ke dalam suatu repositori. Ada satu bagian kode untuk mengatur semuanya, namanya build script. Tim DevOps (atau build admin saat itu) jarang melakukan perubahan pada skrip ini, kerja bisa sambil menyeruput kopi dan membahas episode Dallas terakhir selagi mengawasi hasil code yang secara perlahan sedang compile di server.

Maju ke tahun 2020, dan segalanya sangat berbeda. Tidak ada yang pernah mendengar acara Dallas dan acara streaming paling populer adalah jenis drama Korea (contoh di sini). Harga ruang hardisk dan komputasi awan sangat murah dan gampang sehingga membuat dan deploy layanan baru dapat dilakukan dengan beberapa klik hanya dalam dua menit. Sebuah sifat arsitektur microservice, setiap fitur, setiap kumpulan API bisa berupa server-server baru di awan. Mudahnya clone server baru, aplikasi dengan cepat bisa dikembangkan dan disebarkan. Anda akan memiliki banyak server dalam waktu yang singkat, masing-masing dengan kebutuhan kompilasi dan build sendiri.

Di suatu siang

Kita semua pernah mengalaminya. Biasanya terjadi di Jumat siang. Beberapa fitur besar dari dua tim harus deploy sebelum akhir pekan, acara promo besar-besaran minggu depan bergantung padanya. Maka hidup Anda tergantung dengan release ini. Toni yang biasa melakukan deployment dan release cuti hari ini, hmm mencurigakan! Untungnya, tugasnya dilimpahkan kepada Anda. Ada beberapa perubahan yang harus dilakukan pada skrip. Waktu mendekat dan panik mulai terasa.

Skrip yang terlupakan

Bagaimana build script jadi berantakan ketika kode lainnya diformat dengan begitu cantik dan indah? Build script seringkali tidak mendapat perhatian developer dan sentuh kasih linter. Skrip sering dengan cepat disalin dari beberapa contoh supaya produk dapat dibangun dan dilepas secepat mungkin. Saat produk berkembang, berbagai environment ditambahkan, berulang kali dimodifikasi, disalin, dan ditempel lagi. Hasilnya adalah skrip Frankenstein, tambal sulam yang penting jalan. Pada akhirnya sebagian besar developer pun enggan mengambil resiko merusak proses build nantinya.

Gambar 1: Contoh build script.

Gambar 1 di atas adalah contoh langkah-langkah umum untuk build sebuah servis. Mulai dari definisi environment, versi OS, pemicu, langkah-langkah build, sampai penerbitan artefak dan mengirim image untuk di-deploy. Secara umum proses build terdiri dari:

• Melakukan clone repositori terbaru
• Mengunduh dan membangun dependensi
• Melakukan beberapa tugas linting dan menata format
• Menjalankan pengujian unit
• Menjalankan kompilasi dan build
• Mengirim image ke repositori
• Selesai dan pelaporan

Semua langkah di atas harus dijalankan di berbagai environment. Anda pasti memerlukan langkah-langkah yang mirip untuk deploy ke environment development, untuk environment staging selama pengujian, dan untuk environment produksi. Biasanya semua kerumitan di atas dimasukkan ke dalam satu file sesuatu_pipeline.yml.

Metode Validasi

Untungnya, ada beberapa cara untuk membantu periksa skrip yaml (Gambar 2). Azure memiliki plugin yang bagus untuk editor Visual Code yang membantu pengecekan file yaml. Extension market untuk untuk Visual Code menawarkan banyak pilihan selain yang dari Microsoft. Bitbucket dan Gitlab masing masing memiliki antarmuka web untuk validasi yaml. Cukup salin dan tempel isi file Anda dalam situs mereka, jika ada kesalahan akan terdeteksi.

GitHub sedikit berbeda dalam hal ini. Market yang sangat ramah terhadap para developer memanjakannya dengan banyak otomatisasi GitHub Actions yang gratis.

Gambar 2: Berbagai cara validasi skrip

Ada cara yang lebih baik

Apakah ada cara yang lebih baik? Contoh pada Gambar 1 terlihat banyak langkah yang perlu diulang-ulang untuk setiap environment atau trigger. Masuk akal jika langkah-langkah yang mirip disatukan dan menjadi skrip terpisah.

Setelah dipilah-pilah menjadi fungsi sendiri, Anda bisa memiliki sekumpulan skrip yang lebih kecil dalam direktori project build/ seperti di bawah:

Build/
├── doBuildDocker.yml
├── doLoginDocker.yml
├── doBuild.yml
├── doTests.yml
├── getDependencies.yml

Sekarang pipeline utama hanya perlu memanggil file yang dibutuhkan. Sebagian besar pipeline memiliki kemampuan untuk menggunakan skrip lain, di Azure Anda dapat menggunakan fitur template. Untuk GitLab bisa menggunakan fitur include.

Skrip pipelines.yml Anda menjadi mirip seperti:

Gambar 3: Pipeline skrip setelah menggunakan template. Jauh lebih bersih.

Pipeline utama Anda sekarang sederhana, rapi, gampang dibaca, dan lebih pendek. Anda dapat dengan mudah melihat aliran build dan langkah tanpa pindah pindah layar. Tapi sebentar, pasti tidak segampang itu. Bagaimana dengan perbedaan antar build? Gambar 3 disederhanakan untuk ilustrasi, kenyataan pasti banyak variabel yang perlu dilempar ke dalam script. Di Azure bentuknya parameters seperti ini:

- template: azure/go/doBuild.yml
  parameters:
     imgName: $(imageName)
     buildPath: $(buildPath)

Jika Anda meracik module yaml file segenerik mungkin dan menggunakan variable, module Anda akan lebih fleksibel.

Gunakan kata kunci include untuk menyertakan file YAML eksternal dalam konfigurasi CI / CD Anda. Anda dapat memecah satu gitlab-ci.yml panjang menjadi beberapa file untuk memudahkan membaca, atau mengurangi duplikasi di banyak tempat.
- docs.gitlab.com

Sekarang jika diperlukan perubahan pada suatu langkah, misalnya ada versi library yang perlu dinaikan, hanya perlu dilakukan sekali dalam file doBuild.yml, dan perubahan tersebut akan menyebar ke seluruh environment tanpa melakukan update ke banyak tempat.

Hidup tampaknya mulai lebih mudah, semua mulai teratur. Tetapi dalam sistem versioning jika anda perlu melakukan perubahan, harus melakukan clone branch utama terlebih dahulu. Kemudian melakukan perubahan pada branch lokal, push perubahan tersebut, mengajukan code review dan merge kembali lagi ke branch utama. Sistem cek dan ricek ini tidak terlalu berat jika hanya sesekali saja.

Tapi dikala perlu melakukan perubahan pada banyak repositori, saat misalnya, ada perubahan provider, maka banyak pipeline perlu diperbarui. Ini akan memakan waktu lama. Ditambah keperluan review dan pengujian untuk memastikan perubahan apapun tidak merusak fitur utama produk. Tentu bukan sesuatu yang bisa Anda lakukan dalam satu siang di hari Jumat.

Remote Template

Bagaimana jika Anda dapat melepas build script sepenuhnya dari repositori produk? Dengan begitu, setiap perubahan pada langkah-langkah pipeline tidak perlu mengganggu repositori-repositori produk utama. Dengan memindahkan skrip dari repositori, skrip aman dari perubahan yang tidak disengaja. Merubah pipeline juga dijamin tidak merubah fitur produk.

Build script Anda bisa disimpan dalam repositori eksternal seperti www.github.com/namaperusahaan/pipelines. Di dalamnya adalah kumpulan skrip untuk berbagai jenis server, dengan beberapa jenis teknologi dan semua varian seperti contoh di bawah.

azure/
├── README.md
├── azure-pipelines.yml
├── docker
│   ├── doBuildDocker.yml
│   └── doLoginDocker.yml
├── go
│   ├── doBuild.yml
│   ├── doGenericScript.yml
│   ├── doTests.yml
│   └── getDependencies.yml
├── node
│   ├── doBuild.yml
│   ├── doGenericScript.yml
│   └── doTest.yml

Di dalam pipeline azure, Anda hanya perlu deklarasi repositori eksternal sebagai resource dengan tipe github pada awal pipeline.yml Anda seperti ini:

resources:
   repositories:
     - repository: repositoryname
       name: yourcompany/pipeline
       type: github
       endpoint: namaservisendpoint

Remote template mirip dengan menggunakan template biasa, dengan tambahan penamaan sumber eksternal dalam bentuk @repositoryname di belakang. Bentuk pipeline menjadi seperti contoh di Gambar 4.

Gambar 4: Build pipeline yang menggunakan file template dari repositori eksternal.

Untuk GitLab anda bisa melakukan mirroring dari repository external, kemudian menggunakan include seperti biasa.

Gambar 5: Memulai project dengan tipe external repository (kanan bawah).

Setup Template Eksternal

Bagaimana cara setup eksternal repositori untuk digunakan di pipeline Azure? Langkahnya cukup gampang, tetapi dokumentasi di Azure kurang jelas seputar ini.

1. Langkah pertama membuat service connection (koneksi layanan) di dalam project Azure Devops. Setting ini ada dalam menu Project Settings di panel kiri.
2. Langsung klik New Service Connection (koneksi servis baru) pada tombol kanan atas.
3. Pada layar dialog New Service (Gambar 7), pilih lokasi repository templatemu berada. Jika menggunakan GitHub, maka klik pilihan GitHub.
4. Untuk servis jenis GitHub, perlu Personal Access Token untuk memberi Azure akses.
5. Setelah berhasil, catat nama endpoint pada servis anda, ini yang akan dipakai di pipeline utama, ganti nama endpoint asli ke bagian namaservisendpoint di contoh atas.

Gambar 6: Setting koneksi servis baru di dalam project settings.

Gambar 7: Opsi pilihan servis baru. Jika pipeline template ada di GitHub, klik di GitHub.

Catatan: Pastikan eksternal repositori di atas sudah jadi sebelum pipeline dibuat. Jika kebalikan, eksternal repositori tidak akan dikenal.

Akhir kata

Dengan memindahkan semua build script ke repositori eksternal, dan menyisakan satu skrip generik pada repositori asli, Anda akan memiliki satu titik untuk mengatur pipeline pada semua project. Anda dapat menjamin tidak akan ada perubahan pada file-file dalam repositori asli karena semua perubahan dilakukan di tempat lain.

Referensi

1. https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/overview
2. https://github.com/settings/tokens
3. https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html

Hyperjump is an open-source-first company providing engineering excellence service. We aim to build and commercialize open-source tools to help companies streamline, simplify, and secure the most important aspects of its modern DevOps practices.

Hyperjump