Assalamualaikum dan salam sejahtera kepada semua pembaca setia blog saya! Sebagai seorang yang sentiasa bergelumang dalam dunia teknologi, khususnya pembangunan perisian, saya faham sangat betapa pantasnya landskap digital ini berubah.
Setiap hari ada saja teknologi baru muncul, dan kita sentiasa mencari cara untuk memastikan projek kita berjalan lancar, cepat, dan berkualiti tinggi.
Betul tak? Antara kunci utamanya semestinya Continuous Integration (CI) dan Continuous Delivery (CD) atau lebih popular dipanggil CI/CD. Ia memang game-changer, membantu kita melancarkan aplikasi sekelip mata, tapi ada satu perkara yang sering terlepas pandang: kos operasinya yang boleh melambung tinggi!
Saya sendiri pernah menyaksikan bagaimana syarikat-syarikat, tidak kira startup kecil mahupun korporat gergasi, bergelut dengan bil infrastruktur awan yang kian meningkat, semata-mata untuk memastikan pipeline CI/CD mereka sentiasa beroperasi.
Kadang-kadang, niat nak tingkatkan kecekapan, tapi tak sedar kita dah terjerat dengan perbelanjaan yang tak sepatutnya. Lebih-lebih lagi dalam ekonomi sekarang, setiap ringgit sangat bernilai, dan pengurusan kos ini bukan lagi pilihan, tapi satu kemestian.
Malah, dengan trend digitalisasi yang pesat di Malaysia dan rantau ASEAN, mengoptimumkan kos CI/CD boleh jadi penentu daya saing sesebuah perniagaan. Jadi, persoalannya, adakah kita perlu berkorban antara kelajuan pembangunan dan penjimatan kos?
Tentu sekali tidak! Melalui pengalaman saya yang dah lama menyelami selok-belok CI/CD ini, saya dapati ada banyak ‘rahsia’ dan teknik yang boleh kita praktikkan untuk mengurangkan kos operasi tanpa menjejaskan prestasi atau kualiti.
Dengan perancangan yang betul dan strategi yang bijak, pipeline CI/CD kita bukan sahaja efisien, malah lebih mesra dompet. Nak tahu bagaimana? Jom kita bongkar bersama tip-tip dan strategi terbaik untuk menjimatkan kos operasi CI/CD pipeline yang mungkin ramai tak tahu.
Saya akan kongsikan rahsia bagaimana kita boleh mencapai lebih banyak dengan perbelanjaan yang kurang! Mari kita selami lebih mendalam!
Mengoptimumkan Penggunaan Sumber Komputasi untuk Pipeline Anda
Saya sering lihat, ramai antara kita terlampau selesa dengan tetapan *default* sumber komputasi dalam pipeline CI/CD. Kononnya, biar lebih sikit, jangan tak cukup.
Tapi, tahukah anda, pembaziran sumber seperti CPU dan memori ini boleh jadi punca bil awan kita melambung tinggi tanpa kita sedar? Pengalaman saya sendiri, ada satu projek dulu yang saya bantu selesaikan, bil mereka tiba-tiba naik mendadak.
Setelah disiasat, rupanya *build agent* mereka dilarikan pada spesifikasi yang jauh lebih tinggi daripada keperluan sebenar. Macam kita beli kereta sport untuk pergi pasar, memanglah boleh, tapi membazir minyaknya!
Ini bukan sekadar isu teknikal, tapi juga melibatkan mentaliti penggunaan sumber. Kita perlu ubah cara kita melihat infrastruktur awan—ia bukan hanya tapi juga .
Setiap saat sumber itu berjalan, setiap bait memori yang diasingkan, semuanya ada harga. Jadi, mengoptimumkan saiz *instance* atau *container* untuk *build agent* bukan lagi pilihan, tapi satu kemestian.
Kita perlu teliti setiap langkah dalam pipeline, faham betul-betul berapa banyak CPU dan RAM yang diperlukan untuk *compile*, *test*, atau *deploy*. Jangan main agak-agak, sebab agak-agak itu yang selalunya makan diri dan duit kita.
Menyesuaikan Saiz Instance Mengikut Beban Kerja
Pernah tak anda perasan, *job* CI/CD anda cuma ambil masa 5 minit untuk siap, tapi ia dilarikan pada *instance* berspesifikasi tinggi yang diuntukkan untuk 30 minit?
Inilah pembaziran. Solusinya, kita perlu bijak dalam menyesuaikan saiz *instance* mengikut keperluan sebenar setiap *job*. Untuk *job* yang ringan seperti *linter* atau *unit test* yang pantas, *instance* bersaiz kecil sudah memadai.
Tapi, untuk *integration test* yang makan masa atau *build image* yang besar, mungkin kita perlukan yang lebih berkuasa. Teknologi seperti *autoscaling* dan *serverless compute* boleh menjadi penyelamat di sini.
Saya sendiri pernah cuba strategi ini pada projek *e-commerce* yang mana pipeline mereka ada *step* untuk menguji ribuan produk. Dengan *autoscaling group* yang ditetapkan dengan betul, ia hanya akan naik taraf apabila beban kerja meningkat dan turun semula apabila tiada aktiviti.
Ini memang menjimatkan sangat! Kita bayar apa yang kita guna, bukannya apa yang kita sediakan untuk kemungkinan sahaja. Ia seperti menyewa kereta mengikut saiz keluarga yang mahu melancong, bukan menyewa basikal bila ada lima ahli keluarga!
Memanfaatkan Spot Instances dan Serverless Computing
Satu lagi rahsia yang ramai tak berani cuba, atau mungkin tak tahu, adalah menggunakan *spot instances* atau beralih kepada *serverless computing* untuk *workload* tertentu.
*Spot instances* menawarkan penjimatan kos yang sangat besar, kadangkala sehingga 90% berbanding *on-demand instances*. Kelemahannya, ia boleh ditamatkan pada bila-bila masa.
Tapi, untuk *job* CI/CD yang *stateless* dan boleh disambung semula atau dilarikan semula tanpa masalah (contohnya, *build* kod yang gagal boleh *re-run*), ini adalah pilihan yang sangat menguntungkan.
Saya sendiri pernah guna *spot instances* untuk *nightly builds* dan *regression tests* yang tidak kritikal dari segi masa. Manakala, *serverless functions* seperti AWS Lambda atau Google Cloud Functions, walaupun nampak kecil, ia amat berkuasa untuk *task* yang kecil dan jangka pendek seperti *trigger* notifikasi atau *processing* fail selepas *deployment*.
Anda hanya bayar apabila kod anda berjalan, tiada lagi kos untuk *idle server*. Ia seolah-olah anda membayar untuk elektrik yang digunakan sahaja, bukannya bil tetap bulanan walaupun tidak menggunakan.
Memang bijak!
Strategi Cache Pintar untuk Mengurangkan Masa dan Kos
Caching, ia bukan sekadar perkataan teknikal yang canggih, tapi satu seni dalam pengurusan sumber. Bagi saya, *cache* yang baik adalah tulang belakang kepada pipeline CI/CD yang pantas dan murah.
Bayangkan begini, setiap kali anda *build* projek, anda perlu memuat turun *dependencies* yang sama berulang kali. Kalau projek anda ada beratus-ratus *dependencies* dan saiznya gigabait, bayangkan berapa banyak masa dan *bandwidth* yang terbuang?
Ini bukan sahaja melambatkan proses *build*, malah setiap data yang dipindahkan melalui rangkaian awan, ada kosnya. Pengalaman saya, dulu ada satu projek *mobile app* yang *build time* nya mencecah 45 minit, dan majoriti masanya dihabiskan untuk memuat turun *library* Gradle.
Setelah kami implementasi *remote caching*, masa *build* boleh dipotong kepada kurang dari 10 minit! Perbezaan yang sangat ketara, bukan? Ini menunjukkan betapa pentingnya *cache* dalam ekosistem CI/CD kita.
Ia seperti menyimpan barang keperluan dapur di rumah, tidak perlu ke pasar setiap kali nak memasak, menjimatkan masa dan tenaga.
Menggunakan Cache Build Dependencies
Perkara paling asas dalam caching adalah menyimpan *dependencies* projek. Untuk projek Java, Maven atau Gradle ada *cache* tempatan. Untuk Node.js, atau juga ada.
Tetapi, apabila *build* berjalan dalam persekitaran yang baru setiap kali (seperti *container* baru), *cache* tempatan itu akan hilang. Jadi, kita perlukan *remote cache*.
Alat seperti Artifactory atau Nexus boleh digunakan untuk menyimpan *artifacts* dan *dependencies* secara terpusat. Atau, untuk yang lebih mudah, banyak platform CI/CD moden seperti GitHub Actions atau GitLab CI/CD menawarkan fungsi *caching* terbina dalam yang membolehkan anda *cache* direktori , , atau antara *runs*.
Ini bermakna, *build agent* anda tidak perlu memuat turun *dependencies* yang sama berulang kali. Ia akan semak dulu *cache* yang ada, kalau sama, terus guna.
Ini dapat mengurangkan masa *build* dengan drastik dan secara tidak langsung, mengurangkan kos penggunaan sumber *build agent* anda.
Caching Docker Images dan Layers
Bagi projek yang menggunakan Docker, *caching Docker images* adalah kunci untuk *build* yang pantas. Setiap kali anda *build* imej Docker, ia akan melalui beberapa *layer*.
Jika ada sebarang perubahan pada *layer* awal, semua *layer* selepas itu perlu dibina semula. Namun, jika tiada perubahan pada *Dockerfile* atau *context* yang berkaitan dengan *layer* tertentu, *layer* itu boleh diambil dari *cache*.
Menggunakan *Docker registry* tempatan atau *private registry* boleh membantu menyimpan *intermediate layers* ini. Selain itu, strategi yang lebih canggih seperti *build cache* (contohnya BuildKit) yang banyak platform CI/CD moden sokong, membolehkan *layer cache* disimpan merentasi *builds*.
Ini amat penting terutama bagi projek *microservices* di mana anda mungkin ada puluhan atau ratusan imej Docker yang perlu dibina setiap hari. Mengurangkan masa *build* imej ini secara langsung mengurangkan masa *compute* dan akhirnya, bil anda.
Memilih Perkakas CI/CD yang Bijak dan Berkesan
Dunia CI/CD ini penuh dengan pelbagai jenis perkakas, dari yang sumber terbuka hinggalah yang berbayar dengan pelbagai ciri. Kadang-kadang, kita terkeliru dan terlampau gembira memilih yang paling canggih atau paling popular, tanpa betul-betul meneliti kesesuaian dan kos jangka panjangnya.
Saya sering ingatkan rakan-rakan pembangun, perkakas yang mahal atau yang banyak *feature* tidak semestinya yang terbaik untuk semua. Ada kalanya, penyelesaian yang lebih ringkas dan sumber terbuka adalah jawapan terbaik, terutama untuk syarikat PKS (Perusahaan Kecil dan Sederhana) di Malaysia yang ingin berjimat.
Ini bukan soal kedekut, tapi soal bijak berbelanja. Kita perlu lihat kepada keperluan sebenar, adakah *feature* A, B, C itu memang kita akan guna atau sekadar hiasan?
Pengalaman saya, dulu pernah ada satu syarikat *startup* ini menggunakan platform CI/CD berbayar yang premium dengan bayaran bulanan yang agak tinggi, padahal *workload* mereka tak banyak pun.
Setelah kami tukar kepada penyelesaian sumber terbuka yang *self-hosted*, bil bulanan mereka jatuh mendadak, hampir 70%! Ini membuktikan, pilihan perkakas yang tepat itu sangat kritikal.
Meneroka Solusi Sumber Terbuka (Open Source)
Penyelesaian sumber terbuka seperti Jenkins, GitLab CI/CD (versi *Community Edition*), atau Tekton adalah pilihan yang sangat menarik bagi mereka yang ingin mengurangkan kos.
Walaupun memerlukan sedikit usaha untuk *set up* dan *maintain* sendiri, kelebihan utamanya adalah tiada kos lesen perisian. Anda hanya perlu membayar untuk infrastruktur yang anda gunakan untuk *hosting* perkakas tersebut.
Saya sendiri banyak pengalaman dengan Jenkins, dari projek kecil hinggalah ke projek korporat gergasi. Walaupun ada keluk pembelajaran, komuniti yang besar dan fleksibilitinya yang tinggi menjadikan ia pilihan yang sangat *powerful*.
Untuk GitLab CI/CD, ia datang sekali dengan platform GitLab itu sendiri, jadi kalau anda sudah menggunakan GitLab untuk *version control*, ia adalah integrasi yang sangat lancar dan menjimatkan.
Memang nampak macam kerja lebih pada awalnya, tapi jika anda pandai menguruskan server, penjimatan jangka panjangnya memang berbaloi.
Membandingkan Kos Platform Berbayar
Jika anda memang perlukan kemudahan dan sokongan dari platform berbayar, jangan terus pilih yang paling mahal. Buat perbandingan terperinci. Platform seperti GitHub Actions, CircleCI, Travis CI, atau Bitbucket Pipelines masing-masing ada model harga yang berbeza.
Ada yang bayar mengikut minit penggunaan, ada yang mengikut jumlah *concurrent jobs*, dan ada juga yang mengikut saiz *instance* yang digunakan. Perhatikan juga ciri-ciri tambahan yang ditawarkan.
Contohnya, adakah ia menawarkan *free tier* yang mencukupi untuk pasukan kecil anda? Adakah ia mempunyai *built-in caching* yang efektif? Adakah ia mudah untuk diintegrasikan dengan servis awan yang lain?
Buat kira-kira kasar berapa minit penggunaan yang anda jangka setiap bulan, dan bandingkan harga setiap platform. Kadang-kadang, perbezaan harga antara platform boleh jadi sangat besar untuk *workload* yang sama.
| Strategi Penjimatan | Penerangan Ringkas | Potensi Penjimatan Kos | Tahap Kesukaran Implementasi |
|---|---|---|---|
| Optimalisasi Instance | Menyesuaikan saiz sumber komputasi (CPU/RAM) agen pembangunan mengikut keperluan sebenar setiap tugas CI/CD. | Sederhana hingga Tinggi | Sederhana |
| Penggunaan Spot Instances | Memanfaatkan *virtual machine instances* yang tersedia dengan diskaun besar, sesuai untuk beban kerja yang boleh diganggu. | Tinggi | Sederhana hingga Tinggi |
| Caching Dependencies/Imej Docker | Menyimpan *dependencies* projek atau *Docker image layers* untuk digunakan semula, mengurangkan masa dan sumber yang diperlukan untuk *build*. | Sederhana hingga Tinggi | Sederhana |
| Pembersihan Sumber Automatik | Mengautomatikkan pemadaman sumber yang tidak digunakan atau usang (cth: *artifacts* lama, *logs*). | Sederhana | Sederhana |
| Migrasi ke Serverless (untuk tugas kecil) | Menggunakan fungsi tanpa server untuk tugas-tugas kecil dan *event-driven* dalam pipeline, hanya membayar untuk masa penggunaan. | Sederhana | Sederhana |
Automasi Pembersihan Sumber untuk Elak Pembaziran Senyap
Saya ibaratkan pembaziran sumber dalam CI/CD ni macam bil air atau elektrik yang kita terpaksa bayar, sedangkan paip bocor atau lampu tak tutup. Ia berlaku secara senyap, perlahan-lahan, tapi lama-lama boleh jadi bukit!
Pengalaman saya, salah satu punca utama pembaziran yang sering terlepas pandang adalah sumber-sumber lama yang tidak dibersihkan. *Artifacts build* yang usang, *Docker images* yang tidak lagi digunakan, *logs* yang bertimbun-timbun—semua ini memakan ruang simpanan dan, secara langsung atau tidak langsung, kos.
Ada syarikat yang saya kenal, mereka simpan *artifacts* setiap *build* sejak projek dimulakan, kononnya untuk tujuan audit. Tapi, selepas diselidik, hanya 1% sahaja yang pernah diakses semula.
Selebihnya hanya memakan ruang. Ini satu contoh yang sangat jelas tentang bagaimana kebaikan yang berlebihan boleh membawa kepada pembaziran. Jadi, automasi pembersihan sumber ini bukan saja membantu mengurangkan kos, malah menjadikan sistem kita lebih kemas dan teratur.
Menetapkan Polisi Penyimpanan Artifacts
Setiap *build* dalam CI/CD biasanya akan menghasilkan *artifacts* seperti fail , , *Docker images*, laporan ujian, dan sebagainya. Penting untuk kita menetapkan polisi penyimpanan yang jelas untuk *artifacts* ini.
Contohnya, simpan *artifacts* untuk *build* yang berjaya hanya untuk 30 hari, dan untuk *build* yang gagal hanya untuk 7 hari. Atau, hanya simpan *artifacts* untuk *build* yang telah di-*deploy* ke persekitaran produksi.
Banyak platform CI/CD menyediakan fungsi untuk menetapkan polisi *retention* ini secara automatik. Jangan biarkan *artifacts* ini terkumpul tanpa had, kerana ia akan memenuhi ruang simpanan awan anda, dan kos simpanan ini, walaupun nampak kecil pada mulanya, boleh jadi besar apabila terkumpul.
Bayangkan kalau anda menyimpan ribuan fail yang bersaiz gigabait setiap satu!
Membersihkan Imej Docker yang Tidak Digunakan
Dalam persekitaran *containerized* yang menggunakan Docker, *images* dan *layers* yang tidak digunakan boleh memakan ruang cakera yang sangat banyak. Setiap kali anda *build* imej Docker baru, *intermediate layers* mungkin terbentuk.
Jika imej-imej lama atau *layers* usang ini tidak dibersihkan, ia akan terus menumpang dalam *registry* atau pada *build agent* anda. Gunakan arahan atau implementasikan *lifecycle policies* pada *container registry* anda (seperti AWS ECR, Google Container Registry) untuk membersihkan imej-imej yang tidak digunakan atau sudah lama secara automatik.
Saya sarankan untuk jadikan proses pembersihan ini sebahagian daripada pipeline CI/CD anda sendiri, mungkin sebagai *scheduled job* yang berjalan pada waktu malam atau hujung minggu.
Ini memastikan persekitaran anda sentiasa bersih dan kos simpanan imej terkawal.
Memantau dan Menganalisis Perbelanjaan Berterusan
Sama seperti menguruskan kewangan peribadi, tanpa memantau, kita takkan tahu ke mana duit kita pergi. Dalam konteks CI/CD, memantau perbelanjaan adalah langkah kritikal untuk memastikan kita sentiasa berada di landasan yang betul dari segi kos.
Saya pernah lihat banyak syarikat, terutamanya *startup*, yang hanya sedar bil awan mereka melambung tinggi apabila sudah terlambat, iaitu bila bil sampai di hujung bulan.
Masa itu, memang paniklah! Pengalaman saya mengajar, pemantauan perlu dilakukan secara berterusan, bukan hanya apabila ada masalah. Dengan alat pemantauan yang betul, kita boleh nampak corak penggunaan, mengenal pasti di mana pembaziran berlaku, dan mengambil tindakan segera.
Ini seperti kita pasang meter pintar di rumah, boleh tengok penggunaan elektrik atau air kita secara masa nyata, jadi kita boleh kawal sebelum terlewat.
Menggunakan Alat Pengurusan Kos Awan
Platform awan utama seperti AWS, Azure, dan Google Cloud Platform (GCP) menyediakan alat pengurusan kos terbina dalam yang sangat berkuasa. AWS Cost Explorer, Azure Cost Management, dan Google Cloud Billing Report membolehkan anda melihat perbelanjaan mengikut perkhidmatan, tag, atau projek.
Penting untuk anda *tag* sumber-sumber CI/CD anda dengan betul (contohnya, , , ) supaya anda boleh menjejak perbelanjaan dengan lebih granular. Saya selalu nasihatkan rakan-rakan untuk mulakan dengan ini.
Dari situ, anda boleh kenal pasti perkhidmatan mana yang paling banyak menyumbang kepada bil anda. Adakah ia *compute*, *storage*, atau *network egress*?
Dengan data ini, barulah anda boleh buat keputusan yang lebih tepat dan strategi penjimatan yang lebih berkesan.
Mewujudkan Budjet dan Makluman Perbelanjaan
Jangan sesekali mengabaikan penetapan budjet. Tetapkan had perbelanjaan bulanan atau mingguan untuk operasi CI/CD anda. Kebanyakan alat pengurusan kos awan membolehkan anda menetapkan budjet dan menghantar makluman apabila perbelanjaan hampir atau melebihi had yang ditetapkan.
Ini sangat penting untuk mengelakkan kejutan bil pada akhir bulan. Saya sendiri pernah terselamat daripada bil yang melambung tinggi kerana makluman budjet ini.
Ada satu kali, *bug* dalam pipeline menyebabkan *build agents* tidak dimatikan selepas *job* selesai, dan ia berjalan berjam-jam tanpa disedari. Makluman budjetlah yang menyelamatkan saya daripada kerugian besar.
Ia seperti kita menetapkan had perbelanjaan pada kad kredit kita, supaya tidak terlebih belanja dan terjerat hutang. Makluman ini memberikan kita peluang untuk bertindak segera sebelum masalah menjadi lebih besar.
Membangunkan Struktur Microservices yang Mesra Kos
Trend *microservices* memang sangat popular kebelakangan ini, dan saya sendiri akui kehebatannya dalam meningkatkan kelajuan pembangunan dan skalabiliti.
Tapi, ada satu perkara yang ramai terlepas pandang: struktur *microservices* yang tidak diurus dengan baik boleh jadi punca utama kepada bil CI/CD yang melambung tinggi.
Bayangkan, anda ada 50 *microservices*, dan setiap satu ada pipeline CI/CDnya sendiri. Jika setiap pipeline mengambil masa dan sumber yang sama seperti *monolith*, bayangkan berapa banyak kos yang perlu ditanggung!
Pengalaman saya, ada satu projek yang bertukar kepada *microservices*, tapi mereka masih mengekalkan cara *build* yang lama, iaitu *full build* setiap kali ada perubahan.
Ini menyebabkan *build time* mereka berganda-ganda dan bil awan mereka pun turut berganda. Kunci di sini adalah untuk memastikan setiap *microservice* dibangunkan dan diurus dengan bijak, mengambil kira aspek kos dari awal.
Menerapkan Continuous Integration untuk Microservices
Bagi *microservices*, konsep CI perlu diadaptasi sedikit. Daripada menjalankan *full build* untuk semua *microservices* setiap kali ada perubahan kecil, kita perlu fokus pada *build* dan *test* hanya *microservice* yang terjejas, atau *microservices* yang mempunyai *dependencies* langsung dengannya.
Gunakan *tooling* seperti Bazel atau Nx untuk *monorepos* yang boleh mengenal pasti *changesets* dan hanya membina semula atau menguji bahagian kod yang terjejas.
Ini bukan sahaja menjimatkan masa *build*, malah mengurangkan penggunaan sumber dengan ketara. Saya pernah bantu satu pasukan yang *build* mereka ambil masa 2 jam untuk semua *microservices*.
Dengan menerapkan strategi ini, mereka boleh mengurangkan *build time* kepada 15-20 minit sahaja untuk *changes* kecil, kerana hanya satu atau dua *microservices* yang dibina semula.
Ia seperti kita hanya baiki satu tayar yang pancit, bukan tukar semua empat tayar apabila hanya satu yang rosak.
Mengurangkan Duplikasi dalam Pipeline Microservices
Duplikasi dalam pipeline *microservices* juga merupakan pembaziran yang senyap. Ada kalanya, setiap *microservice* mempunyai *build step* yang hampir sama, memuat turun *dependencies* yang sama, atau menjalankan ujian yang serupa.
Kita perlu cari cara untuk mengoptimumkan ini. Wujudkan *reusable components* atau *templates* untuk pipeline CI/CD anda. Banyak platform CI/CD moden membolehkan anda membuat *reusable workflows* atau *templates* yang boleh digunakan semula merentasi semua *microservices*.
Ini bukan sahaja menjimatkan masa pembangunan pipeline, malah memastikan konsistensi dan mengurangkan kos dengan memastikan kita tidak melakukan perkara yang sama berulang kali.
Ini adalah satu amalan terbaik yang saya sangat sarankan, ia menjadikan pengurusan pipeline lebih mudah dan kos lebih terkawal.
Menggunakan Strategi Pengujian yang Lebih Efisien
Ujian, ia adalah nadi kepada kualiti perisian kita. Tanpa ujian yang menyeluruh, kita takkan yakin dengan apa yang kita *deploy*. Tapi, ujian juga boleh jadi salah satu punca terbesar kepada perbelanjaan dalam CI/CD, terutamanya jika ia tidak diuruskan dengan cekap.
Saya pernah lihat pipeline CI/CD yang mengambil masa berjam-jam semata-mata untuk menjalankan *end-to-end tests* yang redundan atau tidak memberikan nilai tambah yang signifikan.
Masa yang dihabiskan untuk ujian ini, adalah masa *build agent* anda berjalan, dan setiap saat itu ada harganya. Pengalaman saya, ada satu syarikat yang *end-to-end tests* mereka mengambil masa 4 jam, dan ini menyebabkan *deployment cycle* mereka sangat perlahan dan mahal.
Setelah kami kaji semula strategi ujian mereka, kami dapati banyak ujian boleh dioptimumkan atau dipindahkan ke peringkat yang lebih awal. Penjimatan masa dan kos yang terhasil memang sangat memberangsangkan.
Kita perlu bijak dalam memilih jenis ujian dan bila untuk menjalankannya.
Mengutamakan Unit dan Integration Tests
Prinsip “piramid ujian” adalah panduan terbaik di sini. Utamakan *unit tests* dan *integration tests* kerana ia lebih pantas dijalankan dan lebih murah dari segi kos.
*Unit tests* menguji komponen-komponen kecil secara terasing, manakala *integration tests* menguji bagaimana komponen-komponen ini berfungsi bersama. Kedua-dua jenis ujian ini boleh dijalankan dengan cepat dalam pipeline CI/CD anda, memberikan *feedback* segera tanpa memerlukan sumber yang banyak.
Hanya apabila ini semua sudah lulus, barulah kita beralih kepada ujian yang lebih berat seperti *end-to-end tests* atau *performance tests*. Ini memastikan kita mengesan *bug* pada peringkat awal, di mana ia lebih murah untuk diperbaiki, dan mengurangkan keperluan untuk menjalankan ujian yang mahal berulang kali.
Saya sendiri sentiasa tekankan kepada pasukan saya, lebih baik ada 100 *unit tests* yang pantas daripada 10 *end-to-end tests* yang mengambil masa berjam-jam untuk dijalankan.
Mengimplementasi Parallel Testing
Jika anda mempunyai suite ujian yang sangat besar dan mengambil masa yang lama untuk diselesaikan, *parallel testing* boleh menjadi penyelamat. Dengan *parallel testing*, anda membahagikan ujian anda kepada beberapa bahagian dan menjalankannya secara serentak pada *build agents* yang berbeza.
Ini secara drastik mengurangkan masa keseluruhan yang diperlukan untuk menyiapkan ujian anda. Walaupun ini mungkin bermakna anda menggunakan lebih banyak *build agents* pada satu-satu masa, jumlah masa *compute* keseluruhan seringkali lebih rendah atau sama, tetapi anda mendapat *feedback* yang lebih cepat.
Banyak alat ujian dan platform CI/CD menyokong *parallel testing* secara *native*. Saya pernah mengimplementasikan ini untuk sebuah projek *web application* yang mempunyai lebih 2000 *integration tests*.
Dengan *parallel testing* pada 4 *agents*, masa ujian berjaya dikurangkan dari 2 jam kepada 30 minit. Ini memang pelaburan yang berbaloi untuk kelajuan dan penjimatan kos jangka panjang.
글을 마치며
Saya harap perkongsian kali ini benar-benar membuka mata anda tentang betapa pentingnya mengoptimumkan kos dalam pipeline CI/CD kita. Ia bukan sekadar tentang teknologi, tetapi juga tentang pengurusan kewangan yang bijak dan mentaliti yang betul. Jangan biarkan pembaziran kecil menjadi lubang besar dalam bajet projek anda. Setiap langkah yang anda ambil untuk mengoptimumkan, sama ada dari segi pemilihan *instance*, strategi *caching*, atau pemantauan berterusan, pasti akan membawa impak positif yang ketara. Saya percaya, dengan sedikit usaha dan perhatian, anda mampu membina pipeline CI/CD yang bukan sahaja efisien dan pantas, tetapi juga sangat mesra poket. Cuba dan rasai sendiri perbezaannya!
알아두면 쓸모 있는 정보
1. Sentiasa mulakan dengan audit kos sedia ada anda. Gunakan laporan bil awan untuk mengenal pasti di mana perbelanjaan terbesar berlaku. Data ini akan menjadi panduan utama anda untuk tindakan seterusnya.
2. Jangan takut untuk bereksperimen dengan *spot instances* atau *serverless functions* untuk *workload* yang tidak kritikal atau boleh disambung semula. Potensi penjimatan kosnya sangat besar dan berbaloi untuk diterokai.
3. Prioritaskan *caching* di setiap peringkat pembangunan, dari *build dependencies* hingga *Docker image layers*. Ingat, setiap kali anda boleh mengelak muat turun atau membina semula sesuatu yang sama, anda menjimatkan masa dan duit.
4. Manfaatkan sepenuhnya alat *tagging* dan *billing report* yang disediakan oleh penyedia awan anda. *Tag* setiap sumber CI/CD dengan betul agar anda boleh menjejak perbelanjaan dengan lebih granular dan tepat.
5. Fokuskan usaha pengujian anda pada *unit tests* dan *integration tests* terlebih dahulu kerana ia lebih pantas dan murah untuk dijalankan. Ini membolehkan anda mengesan *bug* lebih awal dan mengurangkan pergantungan pada ujian *end-to-end* yang mahal.
중요 사항 정리
Secara ringkasnya, mengoptimumkan penggunaan sumber komputasi dalam pipeline CI/CD anda adalah kunci untuk mengurangkan bil awan. Bermula dengan menyesuaikan saiz *instance* mengikut beban kerja sebenar, beralih kepada *spot instances* atau *serverless* untuk tugas yang sesuai, dan mengaplikasikan strategi *cache* yang pintar, anda sudah berada di landasan yang betul. Pemilihan perkakas CI/CD yang bijak, sama ada sumber terbuka atau berbayar yang bersesuaian dengan bajet anda, juga memainkan peranan penting. Jangan lupa untuk mengautomasikan pembersihan sumber lama seperti *artifacts* dan *Docker images* yang tidak digunakan. Akhir sekali, pemantauan dan analisis perbelanjaan secara berterusan adalah sangat kritikal untuk memastikan anda sentiasa mengawal kos. Semua strategi ini, apabila digabungkan, bukan sahaja akan menjimatkan wang anda, tetapi juga meningkatkan kecekapan dan kelajuan pembangunan perisian anda.
Soalan Lazim (FAQ) 📖
S: Kenapa kos operasi CI/CD ni selalu sangat jadi isu, dan macam mana nak yakinkan bos yang ia tetap berbaloi walaupun ada kos?
J: Haa, ini soalan cepumas! Sejujurnya, saya pun pernah berdepan situasi yang sama. Kos CI/CD boleh melambung tinggi sebab kita terlampau bergantung pada sumber pengkomputeran awan, terutamanya untuk menjalankan ujian yang banyak dan proses pembangunan yang berulang kali.
Setiap kali kod dihantar, pipeline kita akan berputar, menggunakan masa CPU, memori, dan storan, yang mana semuanya ada cajnya. Kalau kita tak pantau, memang boleh terkejut bila bil awan sampai hujung bulan!
Untuk meyakinkan pengurusan, kita kena tukar perspektif. CI/CD ni bukan sekadar perbelanjaan, tapi pelaburan strategik. Cuba bayangkan, tanpa CI/CD, berapa lama masa yang diambil untuk melancarkan sesuatu ciri baru?
Berapa banyak ‘bug’ yang terlepas pandasan masuk ke tangan pengguna? Dan berapa banyak masa yang dihabiskan oleh pasukan untuk membaiki dan mengulang semula kerja?
CI/CD membolehkan kita mengesan masalah lebih awal, mempercepatkan masa untuk pasaran (Time-to-Market), dan mengurangkan kerja-kerja manual yang membosankan.
Ini semua akan diterjemahkan kepada penjimatan kos jangka panjang dan kualiti produk yang lebih baik. Bagi saya, kecekapan yang dibawa oleh CI/CD itu sendiri adalah nilai paling tinggi, yang mengatasi kos operasi jika diurus dengan baik.
Cuba tunjukkan data bagaimana ia meningkatkan produktiviti dan mengurangkan ‘bug’ dalam produk kita; selalunya angka-angka inilah yang akan membuka mata mereka.
S: Apa langkah pertama yang paling berkesan untuk saya mula jimatkan kos CI/CD tanpa perlu pening kepala fikirkan perubahan besar?
J: Ini memang soalan praktikal! Daripada pengalaman saya sendiri, langkah pertama yang paling mudah dan berkesan ialah mengoptimumkan masa jalan (runtime) setiap proses dalam pipeline kita.
Cuba periksa semula setiap langkah dalam pipeline CI/CD anda. Adakah ada ujian yang mengambil masa terlalu lama untuk disiapkan? Adakah anda menjalankan semula proses yang tidak perlu?
Sebagai contoh, saya dapati banyak pasukan sering kali tidak mengoptimumkan caching untuk dependensi (dependency caching). Ini bermakna, setiap kali pipeline berjalan, ia akan memuat turun dependensi yang sama berulang kali, membazirkan masa dan sumber.
Dengan caching yang betul, kita boleh kurangkan masa build dengan ketara. Selain itu, pertimbangkan untuk menggunakan ‘runners’ yang lebih kecil atau ‘on-demand runners’ jika penyedia CI/CD anda menyokongnya.
Banyak penyedia awan mengenakan bayaran mengikut penggunaan CPU dan memori. Jadi, janganlah guna ‘instance’ yang paling besar kalau setakat nak jalankan ujian unit yang ringkas.
Saya sendiri pernah cuba ubah saiz ‘runner’ untuk projek-projek kecil dan ternyata, ia boleh jimatkan sehingga 30% dari bil bulanan saya! Memantau log dan metrik setiap langkah dalam pipeline boleh membantu anda kenal pasti ‘bottleneck’ dan bahagian yang boleh dioptimumkan.
Ingat, setiap saat yang dijimatkan bermakna penjimatan kos untuk dompet syarikat.
S: Adakah terdapat alat atau strategi khusus yang boleh membantu saya kurangkan bil infrastruktur awan yang sentiasa naik untuk CI/CD?
J: Sudah tentulah ada! Sebenarnya, ada banyak ‘trick’ yang boleh kita pakai. Dari segi alat, saya sangat galakkan untuk kita mula meneroka penggunaan ‘self-hosted runners’ atau ‘hybrid approaches’.
Kalau anda dah ada infrastruktur ‘on-premise’ yang tidak digunakan sepenuhnya, atau anda boleh gunakan mesin yang sedia ada (mungkin ada server lama yang boleh ‘diperkasa’ semula?), ia boleh mengurangkan kebergantungan kita pada penyedia awan yang kadang-kadang mengenakan bayaran yang tinggi.
Walaupun ada sedikit pelaburan awal untuk persediaan, kos jangka panjang selalunya lebih rendah. Strategi lain yang saya sendiri praktikkan adalah dengan melaksanakan polisi ‘cleanup’ yang ketat.
Contohnya, pastikan anda membuang ‘artifact’ atau ‘cache’ yang sudah tidak relevan selepas tempoh tertentu. Banyak platform CI/CD mengenakan bayaran untuk storan yang digunakan.
Selain itu, pertimbangkan untuk menggunakan ‘spot instances’ jika beban kerja CI/CD anda bersifat ‘fault-tolerant’ dan tidak memerlukan ketersediaan 24/7.
‘Spot instances’ selalunya jauh lebih murah berbanding ‘on-demand instances’, walaupun ia mungkin terganggu. Walaupun kadang-kadang ada cabaran sedikit untuk menguruskannya, penjimatan yang boleh dicapai memang berbaloi, terutamanya untuk projek-projek berskala besar.
Akhir sekali, sentiasa pantau dan analisis bil awan anda. Kadang-kadang, ada perkhidmatan yang kita tidak sedar masih berjalan dan mengenakan caj. Dengan pemantauan berterusan, kita boleh jadi lebih proaktif dalam menguruskan perbelanjaan.
