Sprint 5 — Almost done

Halo! kembali lagi bersama saya, yusuf. Singkat cerita, pada sprint kali ini kelompok kami sudah berhasil menyelesaikan MVP. Kemarin, kami melakukan sprint review di kantor gojek. Tidak seperti biasanya, kali ini PO kami cukup senang dan menerima fungsionalitas dari aplikasi kami! Namun, untuk UI/UX sendiri masih perlu ditingkatkan. Begitulah cerita singkat kami, langsung saja kita menuju topik.

What we’ve done

1. Refactoring

Ketika sebuah customer melakukan order, muncul halaman sebagai berikut:

Halaman akan tetap seperti itu hingga customer mendapatkan sebuah driver. Berikut adalah flow detailnya:

order flow

Terdapat banyak sekali kelemahan pada flow lama yang kami gunakan, yaitu:

• Customer harus menunggu hingga maksimal 3 menit apabila tidak menemukan driver sama sekali.
• Aplikasi menjadi berat di sisi koneksi karena client harus tetap membuka koneksi HTTP.

Setelah kami berbincang-bincang dengan teman dan PO kami, akhirnya kami membuat flow nya menjadi berbeda. Kami menambahkan sebuah worker yang mengurus pencarian driver. Berikut untuk lebih jelasnya:

New order flow

Sekarang, kedua permasalahan tersebut telah selesai:

• Customer tidak perlu menunggu waktu sama sekali, dan langsung bisa melakukan hal-hal lain terhadap aplikasi. Untuk hasil dari pencarian order, tunggu saja sebuah notifikasi apabila driver ditemukan atau tidak ditemukan.
• Aplikasi tidak terus menerus membuka koneksi HTTP ke server.

Hal tersebut tidak akan tercapai apabila kita tidak berdiskusi baik dengan PO (sebagai customer), dan teman-teman sekelompok.

2. Complete order flow

Kami berhasil menyelesaikan seluruh flow. Urutannya adalah sebagai berikut:

1. Searching driver
2. Mitra found
3. Schedule order
4. Pick up order
5. Complete order
6. Cancel order

Karena pengangkutan sampah tidak dilakukan secara real time, maka terdapat schedule order yang menentukan kapan sampah akan diambil.

Persona

Data diatas merupakan person yang diberikan oleh partner kami. Terdapat banyak komponen yang dapat dilihat diatas, yaitu:

Goals

Merupakan tujuan user kami.

Frustration

Menggambarkan kesusahan atau masalah yang dialami user untuk mencapai goals.

Insights

Setelah mengetahui karakteristik dari calon user melalui persona, maka yang akan dilakukan selanjutnya adalah solusi pemecahan masalah. Pada kali ini, saya akan membahas design yang akan diubah, yaitu:

Menurut PO kami yang sedang berperan sebagai sebuah user, today’s statistic tidak mencerminkan permasalahan yang akan diselesaikan, karena aplikasi order tidak bersifat real-time, melainkan scheduled dari sisi customer dan pengangkut. Oleh karena itu, statistic akan diubah dari today’s statistic menjadi weekly’s statistic dikarenakan scheduled dapat bertempo maksimal satu minggu.

Selain itu, kembali pada topik awal refactoring tadi, dikarenakan target kami adalah customer yang secara umum ingin menggunakan aplikasi dengan mudah (dalam hal ini tidak ingin memperhatikan mobile secara terus-menerus), maka tidak mungkin apabila order harus ditunggu selama 30 detik terlebih dahulu. Oleh karena itu, kami memutuskan untuk menggunakan worker untuk mencarikan sebuah driver.

Deployment, CI/CD

Apa itu CI/CD?

CI adalah singkatan dari Continuous Integration. CI merupakan pengintegrasian dari beberapa proses, dimana terdapat urutan-urutan yang diselesaikan secara kontiyu. Artinya apabila sebuah proses gagal, maka tidak dapat melanjutkan ke tahap berikutnya. Tahap-tahap tersebut saling terintegrasi dan terautomasi. Pada aplikasi kami, CI berisi menjalankan test, linter, dan menampilkan code coverage. Berhubungan dengan CI, Continuous Deployment (CD) berarti mendeploy aplikasi secara kontinyu melalui beberapa tahap terlebih dahulu.

Langsung saja, mengingat kembali aplikasi kami terdiri dari 3 komponen:

• Server (Backend)
• Mitra app
• Customer app

Berikut adalah CI/CDnya:

Yuk-Recycle Deployment Diagram

Saya akan mencoba menjelaskan apa yang terjadi pada deployment backend:

Backend Test

Pada tahap tersebut, terdapat pemindahan direktori menjadi direktori pada file di repository. Karena bersifat monorepo, maka harus berpindah terlebih dahulu ke direktori backend. Setelah itu, menjalankan pengambilan seluruh dependency pada aplikasi direktori backend secara rekursif dengan go get -t ./… .

Setelah berhasil mendapatkan dependency, lalu saatnya menjalankan test. Test dilakukan terhadap seluruh file yang terletak di direktori seacara rekursif dengan menggunakan go test ./… -coverprofile=coverage/coverage.out. Coverprofile adalah command yang berisi hasil dari test yang telah dijalankan. Oleh karena itu, untuk menampilkan hasil dari test, gunakan perintah go tool cover -func=coverage/coverage.out untuk menampilkan coverage pada setiap fungsi, dan -html=coverage/coverage.out untuk menampilkan hasil dengan format html.

Sekali lagi, script tersebut dijalankan apabila terdapat perubahan pada folder backend/… saja, yaitu dengan perintah only: changes: backend/**/*.

Setelah tahap test berhasil, jalankan linter. Yaitu sebagai berikut:

Sama seperti sebelumnya, script dijalankan pada direktori backend dan menginstall package golint. Setelah itu jalankan golint terhadap seluruh direktori. Terdapat perintah dependencies: backend:test yang artinya script ini berjalan apabila backend:test berhasil.

Sekian, semoga bermanfaat!