Push Merge Push Merge

Salah satu sistem version control

Dalam mengembangkan sebuah aplikasi bersama tim, tentu menggunakan Git adalah hal yang biasa. Git merupakan sistem version control untuk mempermudah proses integrasi yang dalam hal ini integrasi kode dari setiap developer. Pembagian tugas untuk masing-masing developer dilakukan dengan memecah user story menjadi task-task kecil. PPL Salemba menjadikan 1 user story menjadi 1 branch dengan tujuan dosen dapat mudah memonitor 1 user story 😜.

Pada awal pengembangan, setiap developer harus melakukan clone repository ke local mereka masing-masing.

$ git clone https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2019/<NAMA_KELOMPOK>.git

User Story

Satu product backlog item atau user story dikerjakan pada 1 branch. Pada 1 branch user story mungkin dikerjakan oleh lebih dari 1 anggota tim sebab setiap user story dibagi menjadi beberapa task kecil.

$ git checkout -b <NAMA_BRANCH_BARU>

Proses pembuatan branch user story dilakukan ketika tim sedang berkumpul merencanakan kegiatan sprint selanjutnya (Sprint Planning). Branch user story yang dibuat tentunya harus diinisialisasi dengan kode terbaru yang ada pada branch staging. Lalu setiap anggota sama-sama melakukan pull branch yang mereka akan kerjakan tersebut.

$ git pull origin staging

Ketika ingin mengimplementasikan kode, setiap anggota harus menuliskan kode tes terlebih dahulu yang disesuaikan dengan requirement setiap task. Setelah menuliskan kode tes, developer harus commit kode tersebut dengan tag [RED]. Artinya, kode tersebut belum memiliki implementasi. Setelah melakukan implementasi yang menyesuaikan kode tes, developer harus commit kode terbaru dengan tag [GREEN] yang berarti bahwa kode tersebut telah lulus unit test.

$ git add .
# Create unit test
$ git commit -m "[RED] Your commit message"
# Implement functions to pass unit test
$ git commit -m "[GREEN] Your commit message"

Proses commit yang dilakukan developer tentu tidak hanya sebatas RED dan GREEN. Developer mungkin saja melakukan hal-hal lain yang tidak berkaitan dengan penulisan kode tes dan implementasi saja. Misalnya penambahan image, css, font atau aset lain yang tidak termasuk dalam kategori RED atau GREEN. Penambahan asset tersebut dapat dicommit dengan menambahkan tag [CHORES] yang artinya perubahan yang dilakukan tidak mempengaruhi fungsionalitas aplikasi. Selain itu, developer juga mungkin untuk melakukan restruktur fungsi-fungsi yang telah ditulis sebelumnya. Restrukturisasi yang dilakukan developer ini dapat dicommit dengan menambahkan tag [REFACTOR] dengan catatan commit ini tidak boleh merusak hasil unit test sebelumnya.

# Restructuring code
$ git commit -m "[REFACTOR] Your commit message"
# Implement something but no production code change
$ git commit -m "[CHORES] Your commit message"

Setelah menuliskan kode sesuai task masing-masing. Developer harus melakukan push atau upload kode yang sudah dicommit. Hal ini dilakukan untuk memperbarui branch yang mungkin hasil implementasi satu developer dibutuhkan developer lain pada branch yang sama. Developer pada branch yang sama dan membutuhkan kode dari developer lain harus melakukan update branch localnya dengan melakukan pull. Siklus ini terus berlanjut hingga semua task selesai.

$ git push origin <NAMA_BRANCH>
$ git remote update origin --prune

Pada praktiknya, seringkali 1 user story membutuhkan hasil pekerjaan dari user story yang lain. Namun, developer dilarang untuk langsung mencuri hasil pekerjaan developer lain dari branch mereka. Terdapat birokrasi untuk mendapatkan hasil pekerjaan orang lain yaitu ketika developer user story lain telah menaruhkan kodenya pada branch staging.

# already on your branch
$ git merge staging

Apabila ingin pull dari staging atau pindah ke branch lain namun pekerjaan belum selesai, dapat melakukan command git stash untuk menyimpan pekerjaan secara temporer.

$ git stash

Setelah melakukan pull atau pindah branch dan ingin melanjutkan pekerjaan dapat melakukan pop pada stash.

$ git stash pop

Staging

Branch staging merupakan branch yang menyerupai master. Maksudnya adalah branch staging berisi seluruh kumpulan kode dari user-story. Namun, branch staging tidak seperti master yang dapat diakses oleh user. Apabila seseorang telah melaksanakan tugasnya dan terdapat anggota lain yang memiliki task pada branch lain, maka orang tersebut harus menaruhkan kodenya pada branch staging dengan melakukan merge request ke branch staging. Setelah hasil pekerjaan lulus tes dengan ditandai centang hijau dan disetujui oleh minimal 2 anggota kelompok lain, maka merge boleh dilakukan.

Pada praktiknya, kode pada branch staging tidaklah selalu baik-baik saja. Ada kasus ketika Product Owner menolak salah satu user story tetapi semua user story sudah tergabung pada 1 branch staging.

Coldfix

Apabila ada kasus yang mengharuskan untuk menghapus salah satu user-story, tim developer harus melakukan revert commit yang dilakukan pada branch coldfix. Setelah melakukan revert, tim harus memastikan kembali bahwa semua unit test terlewati lalu setelah GREEN lakukan merge dengan branch staging.

Siklus ini terus berlanjut hingga seluruh user story telah diimplementasikan. Apabila disetujui oleh product owner dan aplikasi siap diluncurkan, maka kode dari staging dapat dimerge ke branch master. Namun, sangat mungkin terdapat kesalahan pada branch master yang mengharuskan developer untuk menyelesaikan masalah tersebut.

Hotfix

Branch hotfix merupakan branch yang berfungsi sebagai tempat penyelesaian bug yang ada pada branch master. Setelah developer menyelesaikan bug yang ada, developer dapat langsung melakukan merge request ke branch master untuk meluncurkan perbaruan.