Release Management

[feryardiant]

Issue ini tidak hanya mencakup bagaimana tata kelola penomoran versi (versioning) semata namun juga proses distribusi / deployment secara umum baik untuk shared project open source, client project maupun di product kita sendiri, antara lain :

General Projects

• Otomatis generate CHANGELOG.md dan mencatat setiap perubahan atau commit di tiap versi nya.
• Otomatis membuat github release setiap kali push tag
• Otomatis deploy ke production tiap kali ada release untuk project app

Client' Projects

• Otomatisasi integrasi ke Jira jika memungkinkan
• Generate CHANGELOG.md yang berisi summary atas tasks yang dikerjakan

Our Products

• Notify pengguna baik pada aplikasi maupun email jika sudah memungkinkan

Workflows

Dalam hal ini kita gunakan convention yang sudah ada dan banyak digunakan aja biar gak ribet mikir lagi, selain itu biasanya sudah ada tools yang bisa kita pakai untuk menggunakan convention tersebut.

Seperti yang sudah saya terapkan selama ini walaupun mungkin bukan yang terbaik atau mungkin juga sudah ada yang lebih baik lagi saat ini, kita perlu gali lagi lebih lanjut. Yaitu dengan menggunakan tool antara lain :

• Conventional Commit : Seperti yang kita ketahui bahwa ini adalah default format commit message di setiap project di creasico. Tujuan utama nya tidak lain adalah untuk mempermudah proses otomasi pada tahap-tahap berikutnya.

  Dengan menggunakan default config-conventional hal yang masih jadi PR kita bersama adalah SCOPE dari commit tersebut.

• Version Bump : Saat ini kita menggunakan standard-version dimana tool ini (setidaknya untuk saat ini) cukup bisa diandalkan untuk salah satu poin yang ada di General Project diatas.

  Dan tiap kali ada perubahan versi si standard-version ini akan meng-update field version yang ada di file package.json, yang mana itu adalah tempat satu-satunya untuk menyimpan versi terakhir dari masing-masing repo. Apakah bisa diubah? jawabannya bisa! Tapi untuk saat ini biarkan default seperti itu dulu, kita diskusikan lagi ini nanti. Selain itu, saya prefer definisi di 1 tempat dan bisa digunakan di banyak tempat.

  Nah! dari situ, kendala saat ini adalah penggunaanya masih belum terimplementasi dengan baik khususnya di backend. Ini nanti ada kaitannya juga dengan release management di sentry.

• Continous Delivery : Kebetulan siang ini kita handle proses deployment salah satu project client kita ke production. Di diskusi tadi saya memutuskan :

  • Gunakan tag untuk deploy ke production, dan
  • Gunakan branch untuk deploy ke staging

  Dimana untuk handle task tersebut perlu konfigurasi github actions yang berbeda. Semua berjalan sesuai harapan, namun masih ada ruang untuk improvement agar proses ini bisa lebih komprehensive.