Belajar IoT Engineer - Firmware CI/CD & DevOps

#Pendahuluan

Di episode 16 kita membangun pengujian yang lengkap. Sekarang muncul masalah baru: siapa yang menjalankan semua pengujian itu, dan kapan? Kalau semua manual, butuh berhari-hari per rilis dan manusia bisa lupa langkah. Inilah wilayah DevOps untuk firmware.

Mengapa CI/CD firmware penting? Firmware adalah software yang paling sulit diperbaiki setelah terlanjur tersebar: untuk update saja butuh OTA bertahap (episode 9). Semakin awal bug tertangkap, semakin murah perbaikannya. CI/CD menjadikan "selalu lulus tes" sebagai standar, bukan harapan.

#Apa yang Berbeda dari CI/CD Web

CI/CD firmware punya kekhasan:

Aspek	Web	Firmware
Build	npm/bundle	Cross-compile ke binary per board
Test	Unit + integration	Unit + HIL (butuh hardware)
Artifact	Container/image	Binary per board + manifest
Deployment	Server	OTA + gradual rollout
Rollback	Instant	A/B partition, lambat

Langkah paling penting dan sering diabaikan: build untuk semua board yang dipakai. Satu proyek PlatformIO bisa punya target esp32dev, esp32s3, dan nodemcu — CI harus membangun dan menguji semuanya, karena bug bisa hanya muncul di board tertentu.

#Pipeline CI Ideal

Pipeline CI firmware

Push → lint + format
     → build semua board (pio run -e <board>)
     → unit test (pio test -e native)
     → cek ukuran binary & flash/RAM usage
     → build release (bump version, tag)
     → publish artifact (firmware.bin + manifest)
     → trigger OTA rollout (gradual)

Setiap stage berhenti jika gagal — binary yang berukuran terlalu besar atau melewati ambang RAM tidak boleh lanjut ke release.

#Praktik: GitHub Actions untuk PlatformIO

Buat workflow CI dasar di repository firmware:

.github/workflows/ci.yml

name: firmware-ci
 
on:
  push:
    branches: [main]
  pull_request:
 
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
 
      - name: Install PlatformIO Core
        run: pip install platformio
 
      - name: Build semua board
        run: pio run -e esp32dev -e esp32s3
 
      - name: Jalankan unit test native
        run: pio test -e native
 
      - name: Cek ukuran binary
        run: |
          pio run -e esp32dev
          ls -la .pio/build/esp32dev/firmware.bin

Setiap pull request otomatis menjalankan build dan test. Jika ada yang gagal, PR tidak bisa di-merge — bug tidak pernah sampai ke release.

#Menambah Analisis Memori

Firmware di MCU harus muat di flash dan RAM. PlatformIO melaporkan penggunaan memori saat build:

Cek pemakaian flash/RAM

pio size -e esp32dev

Contoh output pio size

RAM:   [==        ]  25.0% (used 81920 bytes from 327680 bytes)
Flash: [==        ]  22.8% (used 953760 bytes from 4194304 bytes)

Jadikan ini gate: jika pemakaian flash melewati ambang (mis. 80%), CI gagal. Tambahkan ke workflow:

.github/workflows/ci.yml - gate ukuran binary

      - name: Verifikasi ukuran dalam ambang
        run: |
          SIZE=$(stat -c%s .pio/build/esp32dev/firmware.bin)
          echo "firmware.bin = $SIZE bytes"
          test "$SIZE" -le 3000000 || exit 1

Gate ini mencegah regresi diam-diam: satu dependency baru yang besar bisa memaksa firmware keluar dari flash — dan baru ketahuan saat upload gagal di lapangan.

#Release dan Versioning Firmware

CI build release harus menghasilkan artifak bernomor versi yang terhubung ke kode:

Artifak release

firmware-v1.3.0-esp32dev.bin
firmware-v1.3.0-esp32s3.bin
manifest-v1.3.0.json   ← versi + hash + ukuran tiap board

Manifest versi menjadi dasar OTA: perangkat membandingkan versinya dengan manifest, bukan menebak. Hubungkan versi firmware ke tag git dan jaga anti-downgrade (episode 9) — server menolak OTA ke versi yang lebih tua.

Tip

Gunakan semantic versioning untuk firmware: v1.3.0. Breaking change di API perangkat atau protokol = major bump (mis. v2.0.0), karena perangkat lama yang belum di-update tidak akan kompatibel. Git tag + manifest harus selalu sinkron.

#DevSecOps untuk Firmware

Keamanan masuk ke pipeline sejak episode 11. Tambahkan di CI:

Secret scanning — tolak commit yang mengandung kredensial (WiFi password, AWS key).
Dependency audit — periksa library PlatformIO terhadap CVE.
Signature — tanda tangani firmware di CI sebelum publish; perangkat memverifikasi (episode 9, 11).

Tanda tangani firmware di CI

openssl dgst -sha256 -sign release.key firmware.bin > firmware.bin.sig

Private key signing disimpan sebagai GitHub Secret — CI tidak pernah melihat isinya, hanya memakai tanda tangannya.

Warning

Jangan pernah menyimpan private key signing di repository — termasuk di file .env yang "kebetulan" ikut commit. Kehilangan private key = penyerang bisa membuat firmware palsu yang diterima semua perangkat. Rotasi kunci yang bocor adalah operasi yang sangat mahal.

#Kesalahan Umum

CI hanya build satu board — bug spesifik board lolos sampai produksi.
Test tidak otomatis — "nanti saya jalankan lokal" = tidak pernah berjalan.
Ukuran binary tidak di-gate — firmware tiba-tiba tidak muat di flash saat release.
Versi tidak sinkron dengan git tag — OTA bingung membedakan versi.
Kredensial masuk CI/repo — bocor sekali, seluruh fleet berisiko.
Firmware tidak ditandatangani — siapa pun bisa menyuntikkan firmware palsu.

#Penutup

Inti yang harus dibawa pulang:

CI/CD firmware: build semua board → unit test → cek ukuran → release → OTA gradual.
GitHub Actions + PlatformIO membuat CI ringan dan gratis untuk repo publik.
Jadikan flash/RAM usage sebagai gate otomatis di CI.
Versioning: semantic version + git tag + manifest yang sinkron.
DevSecOps: secret scanning, dependency audit, dan tanda tangan firmware di pipeline.

Di episode 18 selanjutnya, kita akan mengamankan jaringan tempat perangkat berdiam: IoT network security — segmentasi jaringan, mTLS, dan protokol aman — plus praktik mengamankan jaringan lokal kalian dari perangkat sampai cloud. Keamanan itu lapisan, bukan titik!