Penerapan GIT FLOW ‘seLaw’ selama Dua Sprint Terakhir
Dalam kegiatan PPL, saya membuat suatu software tidaklah sendirian melainkan bekerja dalam satu tim. Hal ini berarti, saya tidak coding sendirian melainkan bersama-sama dengan tim saya untuk menciptakan suatu software yang diinginkan. Kami menggunakan metode Agile yaitu Scrum sebagai panduan kami dalam melakukan pekerjaan.
Pada metode Agile Scrum ini setiap orang melakukan coding secara sendiri-sendiri yang nantinya setiap codingan tersebut akan digabungkan. Lalu bagaimana cara menggabungkan semua codingan tersebut dengan gampang tanpa harus melakukan ‘copy paste’ secara manual ke suatu folder baru?
GitLab lah jawabannya.
GitLab merupakan sebuah version control tools yang digunakan para developers untuk mengembangkan softwarenya. GitLab membantu para developer untuk mengintegrasikan atau menyatukan code dari tiap-tiap orang secara otomatis. Otomatis disini maksudnya adalah GitLab akan mencoba menyatukan secara langsung codingan tiap-tiap orang yang terdaftar pada suatu project dan akan memberikan message ‘conflict’ apabila ada code yang berbeda pada baris yang sama.
Sesuai judul yang di atas, sekarang kita akan membahas flow dari tim kami ‘seLaw’ menggunakan GitLab.
- Melakukan inisiliasi repository di GitLab.
Saat kita membuat repo kita, akan ada branch pertama yang terbentuk yaitu branch ‘master’, pada branch ini nantinya kita akan mengintegrasikan semua codingan kita yang sudah benar-benar baik dan aman untuk deploy maka dari itu branch ini dikunci untuk para developer sehingga tidak sembarang melakukan git push ke branch tersebut tanpa persetujuan dari Scrum Master sebagai orang yang memiliki wewenang penuh di branch ‘master’.
2. Pada kegiatan PPL tahun ini, kami ‘seLaw’ menggunakan 3 tahapan dalam men-deliver software kami yaitu developing, staging, production. Disini kami menggunakan branch berbeda pada tiap tahap. Untuk developing kami membuat branch-branch berdasarkan User Story kami seperti berikut :
Oh iya, untuk tulisan ‘BE’ pada branch tersebut artinya branch tersebut merupakan back-end dari user story tersebut dikarenakan suatu user story terkadang memiliki task untuk dikerjakan oleh front-end dan back-end secara bersama-sama sehingga kami memisahkannya. Jadi, kami disini membuat branch yang berbeda juga pada staging dan production-nya agar codenya tidak tercampur-campur.
Untuk staging kami membuat 2 branch yaitu ‘staging-be’ dan ‘staging-fe’. Tiap dari branch staging tersebut merupakan hasil integrasi dari back-end untuk ‘staging-be’ dan dari front-end untuk ‘staging-fe’.
Begitupula dengan branch ‘master’ terbagi menjadi dua yaitu ‘master’ untuk back-end dan ‘master-fe’ untuk front-end.
3. Pada tahapan developing, setelah membuat branch berdasarkan user story hal yang selanjutnya dilakukan adalah membuat branch tersendiri untuk mengerjakan task-task yang dipecah berdasarkan user story tersebut.
Dalam membuat branch task, kita dari awal melakukan ‘merge-request’ terhadap branch user story tersebut dan membuat branch baru berdasarkan branch untuk user story tersebut.
Dapat dilihat ada tulisan ‘WIP’ di atas, artinya branch tersebut sedang dalam proses pengerjaan dan menunggu 2 approval dari teman-teman ‘seLaw’ jika ingin di-merge.
4. Untuk melakukan commit-an disini harus memiliki TAG agar terlihat lebih rapi dan tujuan commit-nya juga jelas. TAG tersebut adalah [RED], [GREEN], [CHORES], [REFACTOR]. Untuk RED dan GREEN lebih terhadap fungsionalitas coden-nya. RED biasanya adalah commit-an awal yang pasti memiliki pipeline failed karena berisikan testing-code yang belum disertain code yang ditesting. GREEN adalah commit-an yang sudah berhasil lewat dari testing. CHORES adalah semua commit-an yang tidak ada sangkutan dengan fungsionalitas seperti membuat README.MD. Untuk REFACTOR adalah tag terkait perubahan isi codingan dari codingan yang sudah lulus pipeline test (GREEN), dan juga harus berakhir GREEN ketika di-commit ulang.
5.Pada PPL ini kita menerapkan TDD. Dengan menggunakan TDD artinya commit-an GitLab kita terdiri dari RED dan GREEN. RED disini maksudnya adalah pipelinenya akan mengembalikan warna merah apabila code yang kita buat gagal lewat testing. GREEN disini maskudnya pipeline mengembalikan warna hijau ketika code kita buat sudah lewat dari testing dan berhasil.
6. Selanjutnya, pada tahapan sebelumnya kita kan sudah membuat merge-request maka kita akan meminta teman kita melakukan code review sebelum meng-approve merge request kita untuk digabungkan ke dalam branch user story yang nantinya akan digabungkan ke staging-be atau staging-fe.
7. Selanjutnya, melakukan tahapan diatas secara berulang sampai masa sprint review yang nantinya akan menunggu persetujuan dari PO untuk dinaikkan ke production (disatukan ke branch master dan master-fe).
Wah ternyata banyak juga ya tahapan yang harus dilakukan ‘seLaw’ dalam menjalankan PPL-nya. Tentu saja walaupun panjang, ini semua demi membuat software yang baik tentunya.
Sekian dari kami seLaw, TUNGGU CERITA KAMI SELANJUTNYA !
