Configuration over Convention
Setting Up
Membuat sebuah web app menggunakan teknologi terbaru bukanlah tugas yang mudah untuk dikerjakan. Teknologi baru yang dimaksud disini adalah Function as a Service atau disingkat menjadi FaaS. Lebih sulit lagi jika pembuatan web app tersebut memiliki ketergantungan yang sangat tinggi terhadap suatu vendor, yaitu Amazon Web Service, atau sering disebut AWS.
Penggunaan framework yang cocok dan pengaturan awal yang baik sangat diperlukan untuk memastikan bahwa tidak akan ada masalah besar yang menghalangi ketika proses development dimulai. Proses konfigurasi inilah yang memakan waktu paling lama di sprint pertama mata kuliah PPL ini. Mengemban tugas sebagai DevOps juga menambah kesulitan sprint pertama ini karena bisa dibilang saya lah yang bertanggungjawab atas konfigurasi Docker.
Docker? How?
Masalah yang sering dihadapi developer suatu web app adalah hal-hal yang sebenarnya kurang berkaitan dengan business logic dari web app yang mereka buat, namun memainkan peran yang sangat penting dalam pembuatan web app, seperti server, alokasi resource ketika banyaknya request sedang banyak atau sedikit, dan lainnya. Ketika Docker muncul, masalah ini sudah mulai berkurang. Namun, konfigurasi Docker juga memerlukan keterampilan yang baik agar penggunaannya dapat dioptimalkan, sehingga membuat developer kembali lagi ke masalah awal. Function as a Service (FaaS) dibuat untuk menyelesaikan masalah ini, once and for all.
Ketika saya melihat bahwa client kami menginginkan penggunaan teknologi Serverless, saya cukup excited karena artinya saya tidak perlu berkutat dengan Docker maupun hal-hal berbau deployment lainnya. Namun, rasa excited itupun berubah menjadi kebingungan ketika semua kelompok di mata kuliah PPL diminta untuk mengimplementasikan Docker.
Kebingungan saya adalah bagaimana sesuatu yang awalnya dibuat agar Docker tidak perlu lagi digunakan, namun kami diminta untuk tetap menggunakannya? Akhirnya setelah bertanya kepada dosen dan asisten dosesn khusus DevOps, saya diperbolehkan untuk menggunakan Docker untuk automasi ketika deployment ke AWS.
Saya membuat 2 jenis docker-compose dan Dockerfile, yaitu untuk local develoment dan deployment. Docker local adalah Docker yang digunakan untuk menyalakan local server. Docker deployment adalah Docker yang digunakan untuk melakukan deploy ke AWS. Alasan dari penggunaan Docker untuk local adalah supaya tidak ada error ketika web app dijalankan di mesin dengan OS yang berbeda-beda.
Jenis Docker kedua adalah Docker deployment. Services ini berfungsi untuk melakukan deployment ke AWS S3 dan AWS Lambda.
Pada service frontend, terdapat command yang akan meng-copy semua file yang telah di build oleh React ke AWS S3 bucket. Karena bucket tersebut sudah disiapkan menjadi bucket untuk static website hosting, maka user dapat langsung mengakses sebuah URL ke bucket tersebut dan akan langsung membuka halaman index.html
Pada service backend, terdapat command yang akan melakukan deploy ke AWS Lambda. Setelah semua file TypeScript di compile menjadi file JavaScript di stage build, semua file JavaScript tersebut dan dependencies- nya akan di-copy ke stage deploy dan di deploy ke AWS.
Proses deploy akan ditangani oleh Serverless Framework yang kami gunakan. Pada dasarnya, Serverless Framework akan melakukan compression kepada file-file handler untuk setiap fungsi dan semua dependencies-nya. Hasil compression ini kemudian akan diupload ke sebuah AWS S3 bucket yang akan disiapkan oleh Serverless Framework. Selanjutnya dengan memanfaatkan CloudFormation stack, stack tersebut akan melakukan deploy dari file yang ada di AWS S3 bucket ke AWS Lambda dan resource-resource lain yang membutuhkan. Semua konfigurasi terkait handler files dan resource AWS yang akan digunakan dapat ditemukan di file serverless.yml
Lets’s Code!
Pada sprint pertama ini, kelompok kami memilih untuk mengambil 6 sprint backlog dari semua PBI yang ada. Keenam sprint backlog tersebut dipecah lagi menjadi 18 tasks, yang akan dibagi menjadi 3 task per anggota kelompok. Ketiga task yang akan saya kerjakan adalah:
- Membuat API untuk generate AWS S3 signed URL yang akan digunakan untuk upload file ke AWS S3
- Membuat API untuk Create Badge Class
- Implementasi username and password sign in menggunakan Amazon Cognito
Task pertama dan kedua merupakan bagian dari sprint backlog “Create Badge Class”, dan task ketiga merupakan bagian dari sprint backlog “Sign In with Username and Password”.
Git Flow
Berdasarkan panduan Git Flow dari mata kuliah PPL, Git branch dibuat dari sebuah sprint backlog untuk mempermudah penilaian, walaupun menurut saya yang seharusnya dibuat menjadi Git branch adalah task, bukan sprint backlog.
Website yang kami gunakan untuk meletakkan repository adalah Gitlab milik Fasilkom UI. Langkah pertama yang dilakukan di Gitlab ketika memulai sebuah sprint adalah membuat issues yang melambangkan sebuah sprint backlog.
Saat pertama kali seseorang ingin mengerjakan bagian dari backlog tersebut, maka dia harus membuat branch dari issue tersebut dan melakukan merge request ke branch “staging”. Proses ini sangat dipermudah oleh Gitlab karena dapat dilakukan hanya dengan beberapa step saja.
Setelah branch untuk issue dan merge request ke branch staging dibuat, maka seorang anggota tim bisa langsung melakukan commit ke branch untuk issue yang baru saja dia buat.
Seringkali kita membutuhkan API yang telah dibuat oleh anggota tim lain untuk digunakan di dalam pekerjaan kita. Hal ini dapat diselesaikan dengan cara meminta anggota tim kita untuk melakukan merge ke branch staging. Jika tidak ada merge conflict, sudah dilakukan code review dan semua tes sudah berhasil, maka kita tinggal melakukan pull dari remote branch staging ke local branch staging kita dan melakukan merge dari local branch staging kita ke branch dimana kita sedang mengerjakan pekerjaan kita yang membutuhkan API tersebut.
Test Driven Development
TDD merupakan salah satu metode pengembangan software yang sekarang banyak digunakan. TDD digunakan agar code yang dibuat tidak melenceng dari apa yang pada awalnya akan dibuat. Fase-fase yang ada di metode TDD adalah RED, GREEN, REFACTOR.
Langkah awal dari TDD yang baik dan benar adalah pembuatan unit test yang menyesuaikan dengan rancangan pembuatan software. Pada saat unit test tersebut dijalankan, tentu saja unit tests tersebut akan gagal. Proses ini dapat disebut sebagai fase RED dari siklus TDD.
Langkah kedua dari TDD yang baik dan benar adalah pembuatan implementasi dari fungsi yang sebenarnya. Pembuatan implementasi ini akan terus berjalan hingga semua unit test berhasil. Hal ini menandakan bahwa kita sudah membuat fungsi-fungsi yang sesuai dengan rancangan awal software. Proses ini disebut sebagai fase GREEN dari siklus TDD.
Langkah terakhir dari TDD yang baik dan benar adalah melakukan refactor pada code setelah test telah berhasil. Refactor seringkali dilakukan untuk optimasi code dan menerapkan best practice yang sebelumnya belum sempat diterapkan. Tests disini berguna agar setelah mengubah code kita, kita yakin bahwa perubahan kita tidak merusak code yang sebelumnya sudah kita buat. Jika setelah refactor test masih berhasil, maka kita telah sukses melakukan refactor. Jika setelah refactor test kembali gagal, maka refactor yang kita lakukan malah merusak code dan kita harus memperbaikinya kembali sampai hasil test kembali berhasil.
