Penerapan Consumer Driven Contract di Blibli.com

Pada artikel mengenai Consumer Driven Contract (CDC) yang dibagikan sebelumnya, telah dibahas prinsip-prinsip dasar dan cara kerja dari konsep tersebut. Blibli.com memutuskan untuk menggunakan Spring Cloud Contract (SCC) dalam menerapkan CDC pada microservices yang sudah / akan dikembangkan.

CDC merupakan pola pengembangan perangkat lunak dan SCC adalah alat bantu yang dikembangkan untuk menerapkan pola tersebut. Bagaimana alat ini digunakan dan hasil seperti apa yang akan tercapai menjadi fokus kita selanjutnya.

Target awal Blibli.com adalah agar setiap microservice memiliki definisi kontraknya masing-masing secara lengkap dan berhasil menjalankan tes yang di-generate dari kontrak tersebut menggunakan lingkungan yang menyerupai production.

Kelengkapan Kontrak

Yang dimaksud dengan kelengkapan kontrak adalah bagaimana sebuah microservice mengetahui semua consumer yang memanggil dirinya. Hal ini penting untuk memastikan perubahan pada microservice tidak mengakibatkan kegagalan (breaking changes) pada consumer-nya.

Banyaknya jumlah microservices menjadikan kelengkapan ini hal yang cukup menantang. Untuk microservice yang baru dikembangkan hal ini relatif mudah karena kita sudah lebih dulu mengetahui consumer yang akan menggunakan sistem baru tersebut, namun hal tersebut tidak berlaku untuk sistem lama.

Sesuai dengan konsep yang kita gunakan: consumer-driven, setiap microservice akan mengajukan kontrak ke setiap producer yang ia butuhkan tanpa terkecuali. Dengan demikian, ketika CDC sudah diterapkan pada semua sistem, kelengkapan kontrak sudah terjamin.

Standar Kontrak

Kontrak pada SCC berbentuk pasangan HTTP Request dan HTTP Response. Setiap kontrak yang dibuat akan menjadi sebuah test skenario dimana HTTP request akan menjadi input bagi sistem dan response yang dihasilkan akan dicocokkan dengan HTTP Response pada kontrak.

Test skenario yang baik memiliki positive dan negative flow. Oleh karena itu Blibli.com mempunyai ketentuan sebagai berikut dalam pembuatan kontrak:

• HTTP method GET: skenario data ditemukan dan tidak ditemukan
• HTTP method POST: skenario data berhasil dan gagal disimpan
• HTTP method PUT&PATCH: skenario data berhasil diubah dan tidak ditemukan
• HTTP method DELETE: skenario data berhasil dihapus dan tidak ditemukan

Lingkungan yang menyerupai Production

Berbeda dengan unit test dimana sebagian besar komponen pada sistem dipalsukan sesuai skenario (mocking), test yang dibuat dari kontrak akan dijalankan pada sistem dengan konfigurasi semirip mungkin dengan production. Adapun beberapa pengecualian yang digunakan Blibli.com:

• Outbound
  Panggilan ke luar dari sistem akan diarahkan ke stub yang dibuat dari kontrak yang sudah diajukan ke producer
• Database
  Koneksi ke database akan diarahkan ke in-memory database yang di-initialize sebelum tes dijalankan.
• Properties
  Nilai-nilai konfigurasi yang digunakan sama dengan Production kecuali untuk alamat dari stub dan database

Komparasi Test dan Production Environtment

Konfigurasi Tes

Spring Cloud Contract bukanlah sebuah library atau tool siap pakai melainkan kumpulan dari library dan tool yang bisa digunakan untuk me-implement CDC. Beberapa komponen utama yang digunakan di Blibli.com antara lain:

• spring-cloud-contract-maven-plugin: membuat tes dan stub
• spring-cloud-starter-contract-verifier: menjalankan tes
• spring-cloud-contract-stub-runner: mengunduh stub kemudian menjalankannya di port tertentu
• spring-cloud-contract-wiremock: membuat mock producer berdasarkan stub

Tes yang dibuat akan dijalankan menggunakan kombinasi konfigurasi dari spring-boot-test dan beberapa komponen di atas seperti stub-runner dan wiremock.

Hal penting lain yang perlu diperhatikan adalah konfigurasi tes yang dibuat harus terpisah dari konfigurasi untuk unit test. Pada kasus dimana konfigurasi unit test yang ada juga menggunakan spring-boot-test, konflik konfigurasi akan terjadi dan mengakibatkan kedua tes (kontrak dan unit test) gagal.

Sekian pembahasan pada artikel ini, nantikan pembahasan lebih lanjut pada artikel berikutnya yang mencakup antara lain struktur repository kontrak, versioning, serta definisi kontrak yang mengandung pattern.

Penasaran dengan tahap lanjutan dari penerapan Consumer Driven Contract? Ingin terlibat dalam desain pola pengembangan perangkat lunak? Ingin melihat langsung bagaimana desain ini diterapkan di Blibli.com? Silahkan email ke henry.jonathan@gdn-commerce.com untuk berbincang-bincang ataupun menjajaki kemungkinan untuk bergabung dengan kami!