Sebuah versi aplikasi perlu dapat ditelusuri sampai ke kode dan artefak yang dihasilkan. Tanpa hubungan itu, nama rilis hanya menjadi label yang belum menjelaskan apa yang siap dijalankan.
Saya baru menambahkan workflow rilis untuk aplikasi portal. Prosesnya dimulai dari tag versi, lalu membuat release dan membangun image. Saat menyusun alurnya, ada satu hal yang perlu diperjelas: kapan sebuah versi benar-benar dapat disebut siap digunakan?
Menentukan keluaran setiap tahap
Sebelum menyusun workflow, saya menyarankan membedakan tiga keluaran: kode yang dipilih, artefak hasil build, dan catatan release. Deployment ke lingkungan pengguna merupakan langkah berikutnya yang perlu dijelaskan tersendiri.
Workflow yang saya tambahkan dua hari lalu berjalan ketika tag dengan pola
v[0-9]* dikirim. Setelah itu, workflow memeriksa versi, membuat GitHub Release, serta membangun dan mengirim image ke registry.Untuk saat ini, alur yang saya susun mencakup build dan rilis image. Deployment ke server masih berada di luar workflow ini, sehingga kesiapan artefak dan kondisi aplikasi yang berjalan perlu diperiksa pada tahap masing-masing.
Peta workflow
Bagian | Peran dalam workflow |
Pemicu tag | Memilih perubahan melalui tag versi. |
check-version | Memeriksa bentuk versi dan menghasilkan informasi prerelease. |
create-release | Membuat GitHub Release dengan nama tag. |
build-images | Menyiapkan build, metadata image, autentikasi registry, serta build dan push image. |
Pola tag adalah penyaring awal. Pemeriksaan versi tetap dijalankan pada job tersendiri. Dengan susunan ini, penamaan versi menjadi bagian yang dinyatakan dalam konfigurasi.
Menyatukan versi dengan artefak
Workflow tersebut menggunakan Docker metadata action untuk menyusun tag image berdasarkan versi. Tujuan image-nya mencakup Docker Hub dan GitHub Container Registry.
Secara umum, saya menyarankan mencatat identitas kode dan artefak yang dipakai untuk suatu rilis. Jika sebuah masalah muncul kemudian, pertanyaan pertama dapat dibuat konkret: versi kode mana yang dibangun, image mana yang dihasilkan, dan image mana yang dijalankan?
Tag dan catatan release membantu penelusuran, tetapi keberadaan namanya belum membuktikan bahwa seluruh langkah selesai. Hasil job dan ketersediaan artefaknya tetap perlu diperiksa.
Catatan dari workflow saya
Ada detail menarik pada konfigurasi awal ini. Job
create-release dan build-images sama-sama bergantung pada check-version. Keduanya tidak saling menunggu.Artinya, setelah pemeriksaan versi selesai, pembuatan release dapat berjalan tanpa menunggu build image. Jika build gagal, halaman release mungkin sudah tersedia sementara image belum siap. Karena itu, saya perlu membedakan keberadaan release dengan keberhasilan seluruh proses.
Jika kebijakan sebuah aplikasi mengharuskan release baru tersedia setelah artefak selesai, dependency job perlu mengikuti kebijakan itu. Pilihan lainnya adalah mempertahankan proses terpisah dengan status dan kriteria selesai yang jelas.
Otomatisasi memerlukan batas pemeriksaan
Workflow ini belum mencakup pengujian aplikasi atau pemeriksaan kesehatan layanan setelah deployment. Build dan push image merupakan bagian dari proses rilis; pemeriksaan aplikasi yang akan digunakan pengguna tetap perlu mendapat tempat tersendiri.
Untuk penerapan umum, saya menyarankan menentukan pemeriksaan sebelum artefak diberi status siap: pengujian yang relevan, keberhasilan build, serta pemeriksaan aplikasi dalam lingkungan uji. Kebutuhannya mengikuti jenis aplikasi dan risiko perubahannya.
Ada pula konfigurasi yang perlu dijaga sepanjang proses. Saya mengambil beberapa nilai melalui secrets di workflow. Penggunaannya tetap perlu diperiksa bersama Dockerfile agar nilai yang diperlukan saat build dan saat aplikasi berjalan ditangani dengan tepat.
Memulai dari proses yang dapat dijelaskan
Tuliskan urutan manual lebih dahulu, tentukan keluaran setiap tahap, lalu pindahkan langkah yang sudah jelas ke workflow. Setelah itu, uji jalur berhasil dan cara mengenali kegagalannya.
Manfaat otomatisasi yang paling cepat terasa adalah keterbacaan: orang lain bisa melihat pemicu, dependency, dan hasil yang diharapkan tanpa bertanya.