Big Mac Tanpa Daging

Ini bukan cerita tentang vegetarian yang lagi ngidam makan burger. Alkisah tadi pulang kantor udah hampir tengah malam, dengan perut sedikit keroncongan chatting-lah saya dengan si ibuk di rumah.

Ternyata di rumah juga gak ada makanan, akhirnya kita sepakat pesan McDonal’s.

Sambil menunggu pesanan datang, saya nerusin kerjaan sebentar. Gak berapa lama si ibuk kasih kabar kalau pesenan udah sampai. Ok, saya langsung beberes. Laptop saya tinggal aja ah, lagi males bawa-bawa backpack.

Sampai di rumah, say hello bentar ama Keke yang masih terlelap. Habis itu langsung buka bungkusan dari McD. Gak sampai lima menit ludeslah chicken snack wrap yang berukuran mini itu.

Si ibuk yang baru mulai bongkar-bongkar bungkusan McD nyeletuk, “Ternyata gak gede-gede amat ya Big Mac-nya”. Dalam hati saya menimpali “Iya, kok jadi kecil gitu ya?”

Setelah dibongkar ternyata si Big Mac gak ada dagingnya. Haiss, langsung deh komplain ke McD.

Tanpa banyak tanya dikirimlah satu Big Mac pengganti. Si mas yang nganter nyerahin paket pengganti sambil bilang “Maaf ya mas, mungkin tadi yang nyiapin sedang buru-buru”.

“Iya mas gak papa, makasih ya”.

Terindikasi ini bukan kejadian pertama, kata si ibuk (yang emang doyan jajan) udah beberapa kali kalau pesen untuk dibawa pulang ada aja pesenan yang kurang. Sampeyan pernah ngalami juga ?

 

Ruby di Fedora dan CentOS

Ruby adalah salah satu bahasa pemrograman yang beberapa tahun belakangan ini sedang naik daun. Seiring dengan berjalannya waktu, semakin banyak aplikasi/tools keren yang dibuat menggunakan bahasa ini.

Sayangnya ketersediaan paket-paket rpm ruby di CentOS atau pun di Fedora masih sangat minim. Untuk itulah komunitas Fedora membuatRuby SIG (Special Interest Group) yang bertujuan untuk meningkatkan dukungan terhadap aplikasi-aplikasi ruby, pustaka pendukungnya serta mengeluarkan standar untuk para pemaket ruby. Salah satu yang dihasilkan oleh SIG ini adalah panduan untuk para pemaket ruby rpm.

Kondisi di CentOS jauh lebih parah, versi ruby yang disertakan jauh tertinggal dari versi terbaru (CentOS 5 dan 6 menyediakan ruby versi 1.8.7). Padahal beberapa aplikasi mensyaratkan hanya bisa dipakai menggunakan ruby versi baru.

Ada 2 aplikasi yang ingin saya paketkan menjadi rpm, yaitu Redmine dan GitLab. Untuk redmine sebenarnya dia tidak butuh ruby versi terbaru, cukup dengan memasang ruby versi 1.8.7 (sudah tersedia di repositori). Hanya beberapa paket rubygem pendukungnya yang belum tersedia. Sementara gitlab mensyaratkan ruby versi 1.9.x.

Sebenarnya, untuk kedua aplikasi itu bisa saja dipasang di CentOS dengan mudah jika kita mengikuti panduan dari masing-masing pengembangnya. Tapi sebagai mantan sysadmin, saya berpendapat kalau masing-masing aplikasi yang akan dipasang di server memiliki standarnya sendiri-sendiri tentu akan merepotkan untuk proses deployment dan perawatannya. FYI, saya punya prinsip untuk tidak memasang tools development (semacam gcc, autoconf, dkk) di server production. Dan prinsip saya yang lain, proses deployment harus semudah mungkin dan harus dapat dijalankan ulang oleh siapa pun di mesin mana pun dengan hasil yang sama. Ini akan berguna kalau kita ingin membuat replika dari suatu sistem, atau ingin melakukan proses otomasi, dan sebagainya dan sebagainya (banyak sekali alasannya)

Ok, kembali ke masalah pemaketan ruby. Untung sudah tersedia paket rubygem-gem2rpm yang sangat membantu untuk proses pembuatan paket-paket rubygem. Setidaknya 90% berkas spec yang dihasilkan bisa langsung dieksekusi, paling cuma perlu melakukan sedikit penyesuaian. Oh iya, kali ini yang ingin saya coba adalah menyediakan paket-paket ruby 1.9.3 di CentOS, jadi saya mengikuti panduan dan konvensi dari Fedora dan membuild ulang semua paket ruby yang sudah ada di repositori untuk CentOS 6. Saya siapkan satu repositori yum khusus untuk ruby 1.9.3 ini (nanti ya saya unggah kalau sudah selesai semua).

Git, Gitolite, Gitorious dan Gitlab

Salah satu tools yang dipakai di tempat kerja saya adalah versioning system. Selama ini kita pakai subversion, dengan workflow dan modeldevelopment yang kita anut sebenarnya ini sudah mencukupi. Meski di beberapa kesempatan kita pun juga memanfaatkan git.

Ada rencana iseng untuk menggantikan subversion dengan git. Kenapa harus diganti? Ada 1001 alasan, terlepas dari kenyataan teknis bahwa git jauh lebih superior dibandingkan dengan subversion.

Saya perlu menyiapkan sebuah git server (semacam github.com) yang nantinya akan dipakai untuk mempermudah kolaborasi. Kehadiran git server ini sebenarnya tidak wajib, karena git mengusung konsep sistem versioning yang terdistribusi, artinya setiap orang yang ingin berkolaborasi bisa langsung mengakses ke repositori lokal masing-masing developer. Tapi tentunya ini akan merepotkan, karena komputer sideveloper belum tentu hidup 24/7.

Dari hasil jalan-jalan, akhirnya saya mencoba beberapa alternatif solusi ini:

1. Gitolite + cgit
2. Gitorious
3. Gitlab

Gitolite + cgit

Gitolite, yang merupakan penyempurnaan dari gitosis, sebenarnya cukup sederhana dan keren. Manajemen repositori git ditangani menggunakan git itu sendiri :)

Cgit merupakan antarmuka web untuk mengakses repositori git, alternatif lainnya ada gitweb. Cgit cukup kencang waktu diakses karena dia menerapkan sistem caching untuk mengakses objek git.

Protokol http dan git disiapkan untuk akses read-only, sementara untuk akses write ditangani memakai ssh. Proses pemasangan dan konfigurasinya sangat sederhana. Setiap developer nantinya harus mengirimkan kunci publik ssh-nya ke admin git, untuk kemudian didaftarkan ke sistem. Gitolite mendukung konsep berbagi repositori antar developer dan masing-masing user juga bisa ditentukan hak aksesnya terhadap suatu repositori.

Paket gitolite dan cgit tersedia di repositori epel, jadi proses instalasinya relatif mudah.

Gitorious

Percobaan kedua saya jajal pasang gitorious. Aplikasi yang dibangun menggunakan ruby ini requirement yang dibutuhkan gak neko-neko, bisa dijalankan menggunakan ruby versi 1.8.7 (versi ruby yang secara bawaan terpasang di CentOS). Sayangnya progress pengembangan perangkat lunak ini terkesan lambat. Saat saya coba pasang notifikasi email menggunakan activemailer dengan metode smtp+tls (kebetulan saya coba kirim notifikasi menggunakan akun gmail) ternyata modul notifikasinya tidak kompatibel dengan activemailer versi baru. Harus diubah beberapa baris kode supaya proses pengiriman bisa berhasil. Akses ke antarmuka webnya terkesan agak berat.

Setiap project yang dibuat di gitorious dapat memiliki lebih dari satu repositori. Kalau di gitolite dibutuhkan peran serta admin untuk mendaftarkan user beserta kunci publik ssh-nya, di gitorious setiap user bisa membuat project dan repositorinya secara mandiri.

Proses Instalasi gitorious sebenarnya cukup ribet. Untuk mempermudah, saya coba menggunakan gitorious chef recipe punyanyamakewhatis

WARNING: saya tidak terlalu suka dengan cara instalasi yg dilakukan oleh chef recipe ini, alih-alih mengikuti pakem instalasi di CentOS, script ini justru mengadopsi model/gaya debian.

Gitlab

Terakhir, ini yang saya coba. Komunitas pengembang gitlab terlihat sangat aktif. Sayangnya dia butuh versi ruby yang lebih baru. Artinya harus ada usaha lebih untuk menyiapkan paket-paket pendukungnya, karena saya agak males kalau harus memasang sesuatu di luar pakem di server.

Versi terdahulu gitlab ini memanfaat gitolite sebagai backendnya, tapi di versi yang baru ketergantungan terhadap gitolite tersebut sudah dilepas, sebagai gantinya gitlab memakai gitlab-shell.

Sama seperti gitorious, di gitlab setiap user juga dapat mendaftar dan membuat project secara mandiri. Bedanya, setiap project di gitlab hanya memiliki satu repositori.

Kita bisa buat tim, grup dalam suatu project. Kemudian ada fitur merge request (request merge antar branch dalam satu project/repositori).

Atarmuka webnya terlihat modern, agak mirip github. Fitur pull-request masih belum ada di versi yang saya coba, katanya bakal tersedia di versi 5.2 yang akan datang.

Saat instalasi saya menggunakan gitlab-installer. Ada beberapa step di script tersebut yg harus dijalankan secara manual (mulai dari baris ke 157).
Sepertinya gitlab yang akan saya pakai nantinya, sementara ini masih dicoba-coba dulu manfaatin gitlab dengan berbagai skenario.