Pengalaman Dalam Penerapan GitFlow dengan Gitlab
Artikel ini dibuat sebagai bagian dari Individual Review PPL 2021
GitFlow adalah sebuah panduan development software Git. GitFlow memberi panduan tentang branch Git mana saja yang harus dibuat dan fungsi dari branch-branch tersebut.
Artikel ini akan bertumpu pada Panduan Git PPL 2021.
Branch dalam GitFlow
Branch dalam GitFlow PPL Git 4.0 memiliki dua branch utama, yaitu branch master sebagai branch yang menyimpan source code yang siap di deploy dan branch staging sebagai branch utama dalam tahap pengembangan. Akan tetapi, Kelompok sprint saya menambahkan branch baru, yaitu cabang development yang berfungsi sebagai branch utama dari semua PBI branch.
Setiap feature yang dibuat memiliki branchnya sendiri, dalam GitFlow PPL Git 4.0, Branch ini bernama PBI. PBI Branch adalah feature branch versi GitFlow PPL 2021. PBI branch dibuat sesuai fitur yang ditentukan pada saat sprint planning
Saat proses merge ke branch master, hasil merge tersebut tidak lepas dari bugs / error. Maka dari itu, GitFlow menyarankan sebuah Branch khusus untuk memperbaiki error tersebut, yaitu branch hotfix.
Ketika masa Sprint Review, ada kemungkinan Product Owner akan menolak feature-feature yang telah dibuat. Untuk mengatasi masalah ini, dibentuklah branch coldfix yang berfungsi sebagi branch rollback dari sebuah fitur yang ditolak.
Saya menyukai struktur-struktur dari branch GitFlow ini karena dengan implementasi fitur-fitur dan bugs fix pada masa development lebih terstruktur dan terstandardisasi sehingga memudahkan proses development.
Commit Message
Dalam Panduan PPL 2021 Git ver 4.0, tag commit message pada masa development mengikuti aturan tag commit message TDD (Test Driven Development) dan terdapat tag commit message khusus untuk pekerjaan yang tidak berhubungan dengan pekerjaan TDD tersebut. Tag commit message ini diterapkan setelah ada commit yang membuat public interface/class/skeleton/stubs sesuai dengan framework atau bahasa pemrograman yang digunakan.
- tag [RED] adalah tag yang menandai pekerjaan membuat test dari sug atu implementasi class atau fungsi kosong.
- tag [GREEN] adalah tag yang menandai pekerjaan implementasi suatu fungsi / class untuk lulus unit testing.
- tag [REFACTOR] adalah tag yang menandai pekerjaan perbaikan implementasi kode yang sudah dibuat sebelumnya.
- tag [CHORES] adalah tag yang menandai pekerjaan yang tidak berhubungan dengan fungsionalitas, seperti menambah assets image pada proyek.
Tag commit ini menambah penjelasan jenis pekerjaan apa yang kita lakukan di commit tersebut yang membantu developer lain untuk mengerti pekerjaan apa yang dilakukan di commit itu.
Merge Request
Bagian ini merupakan bagian favorit saya dalam masa development proyek ini. Merge request tidak dilakukan secara manual dengan Git, merge request dilakukan pada online repository Gitlab.
Kenapa merge request harus dilakukan di repository online Gitlab? Karena terdapat beberapa aturan dari untuk melakukan merge pada Branch tertentu seperti PBI, development, staging, dan Master. Branch PBI, development, dan staging memerlukan code review minimal 2 anggota kelompok sebelum melakukan merge request. Branch master memerlukan persetujuan dosen / product owner sebelum melakukan merge request. Maka dari itu, Gitlab digunakan karena memiliki fungsi yang dapat mendukung aturan tersebut.
Gitlab menyediakan fasilitas merge request di mana pada menu ini kita dapat memberikan judul dan penjelasan pekerjaan apa yang kita lakukan pada merge request saya. Bagian yang saya sukai dari ini adalah anggota kelompok dapat melakukan code review pada code yang saya kerjakan dan memberi komentar dan saran pada code yang saya telah buat. Hal ini membuat saya merasa diapresiasi atas pekerjaan yang saya buat walaupun mekanisme ini membutuhkan waktu yang lebih lama ketimbang dengan proses development yang saya lakukan sebelumnya.
Sebelum saya melakukan suatu pekerjaan bugs fixing / enchancement, saya biasanya memulai issue dengan fitur Gitlab Issues.
Gitlab Issues
Gitlab menyediakan fitur issue yang menampung isu-isu yang ditemukan selama masa development. Issue ini memiliki dua tampilan, yaitu List dan Board.
Fitur yang saya sukai dalam Gitlab issue ini adalah saya dapat memulai sebuah thread di dalam issue untuk membahas issue yang terkait dengan. Hal ini bagi saya, dapat meningkatkan semangat dalam mengerjakan proyek ini karena saya dapat berdiskusi melalui issue ini dan mencari solusi dari issue ini bersama.
Penutup
Secara keseluruhan, saya merasa puas dengan GitFlow PPL dan implementasinya di Gitlab. GitFlow PPL membuat pekerjaan saya terasa lebih terstruktur dan rapi dan Implementasinya dengan Gitlab membuat saya lebih bersemangat dalam mengerjakan pekerjaan saya karena adanya elemen diskusi dan apresiasi pekerjaan di Gitlab.
