Sebelum post ini dibuat, pilihan teknologi yang dipilih dalam blog ini adalah:

  • Hugo: sebagai framework yang dipakai, salah satu _Static Site Generator _yang popular.
  • Gitlab Page: untuk menghosting konten statis dari website blog ini.
  • Gitlab CI: untuk mengotomatisasi deployment ke Gitlab Page.

Dalam postingan sebelumnya, saya menuliskan hal ini:

Memilih Hugo sebagai blog engine, saya dihadapkan satu konsekuensi (yang masih oke menurutku): hanya Gitlab Page yang mendukung Hugo, yang menawarkan seamless integration dengan Gitlab CI untuk proses otomatisasi publikasi website blog saya. Kebalikannya, GitHub Page hanya mendukung Jekkyl saja 😒, tapi tidak apa-apa.

Sebenarnya bisa saja saya menggunakan GitHub Page, tapi effort yang digunakan akan lebih menyita waktu dalam hal membangun CI/CD, GitHub belum punya offering CICD yang seamless dengan GitHub Page. Gitlab sebaliknya lebih simpel: mereka punya Hugo Blog Template dan Hugo CICD template, itu saja sudah cukup memenangkan hati saya ❀️

Benar saja, Gitlab Page dan Gitlab CI sangat simpel dan mudah untuk digunakan bagi pemula seperti saya. Kedua komponen itu membuat saya fokus belajar memakai Hugo selama 2 jam pertama ketika memulai bootstrap blog ini.

Selama 2 jam pertama itu pula, saya mulai memikirkan bagaimana flow yang ideal (bagi saya) dalam penulisan blog dan melakukan tuning sistem blog.

Ini adalah inisial pemikiran saya saat itu: untuk setiap 1 task, seperti: menambahkan/memperbaiki konten blog, memperbaiki sistem komentar di blog, dll:

  1. Buat branch baru dari branch master
  2. Buat perubahan di repositori
  3. Panggil hugo serve di lokal untuk mengetes langsung bagaimana dampak dari perubahan yang dilakukan
  4. Perbaiki kalau ada kesalahan dan dicoba terus sampai poin 3 benar-benar sesuai yang diinginkan, lalu
  5. Merge ke branch master
  6. Push ke origin Gitlab, dan Gitlab CI akan melakukan langkah selanjutnya untuk men-deploy website ke Gitlab Page

Tapi, saya sadar bahwa terdapat beberapa kekurangan dari flow tersebut:

  • Tidak dapat mereview secara langsung (baca: online) perubahan dari suatu branch (terkait dengan perubahan yang dilakukan ke blog sistem maupun konten blog). Ini kelemahan terbesar menurutku, karena jika memungkinkan, memperbaiki kelemahan ini akan menyelesaikan beberapa gap seperti:

    • Melakukan tes final sebelum mendeploy perubahan tersebut ke production. Ini hal yang penting dan praktikal, karena testing blog di local environment tidak bisa mengungkap beberapa bug, terutama terkait dengan integrasi ke pihak ketiga. Contohnya: sistem komentar Disqus tidak dapat dipakai di local environment dan fitur social sharing memiliki limitasi jika dijalankan di local environment. Bahkan ada beberapa bug yang hanya akan terlihat ketika live online, biasanya terkait dengan hyperlink dan url path.
    • Memudahkan ketika ingin meminta teman untuk proof read terkait postingan blog terbaru, tanpa harus melakukan perubahan langsung ke blog versi production.
  • Flow di atas terlalu mengandalkan pemakaian laptop/komputer hanya untuk melakukan blogging. Ini bukanlah komplain besar, tapi menurutku sangat oke jika ada solusi yang membuat penulisan blog, tidak hanya melalui komputer/laptop, tapi juga smartphone.

    • Contoh kasus: saya butuh traveling atau jalan-jalan keluar kota, saya biasanya membuat draft blog di smartphone. Namun untuk melakukan posting blog langsung secara online, saya harus mendapat akses komputer (dan telah disetup dengan kredensial ke repository Gitlab). Tentu saja ini sangat membatasi kemampuan kita dalam melakukan blog kapanpun dan di manapun. Flow saat ini intinya masih membutuhkan akses ke terminal: untuk mamakai command git (commit dan push) serta hugo serve untuk pengecekan di lokal.

Dari kelemahan di atas, saya akhirnya memutuskan untuk mencari solusi termudah dan simpel yang bisa menutupi poin kekurangan di atas, dan alhamdulillah ketemu juga 😏

Online Site Preview dari Branch Pull Request

Gitlab Page dan Github Page; kedua produk yang mirip-mirip dan berasal dari kedua perusahaan berbeda; hanya support menampilkan konten dari 1 branch utama saja, standarnya adalah branch master. Ini adalah kelemahan utama menurutku.

Untungnya saya menemukan ada Netlify. Apa itu Netlify? Kalau saya ambil quote dari website resminya:

Build, deploy, and manage modern web projects

An all-in-one workflow that combines global deployment, continuous integration, and automatic HTTPS. And that’s just the beginning.

Kalau difrasekan dengan Bahasa Indonesia, Netlify itu adalah platform untuk:

  1. Membangun, deploy, dan mengelola projek web moderen.
  2. Platform yang menyediakan solusi flow all-in-one, yang menggabung deployment secara global, CI, dan HTTPS secara otomatis (membuat website lebih aman).

Saya berpikir ini adalah solusi yang dicari-cari. Membaca lebih lanjut mengenai Netlify:

  • Mereka menyediakan integrasi yang mulus dengan GitHub/Gitlab/dan beberapa major git hosting provider lainnya. Jadi, saya tetap bisa mempertahankan penggunaan Git sebagai penyimpanan konten blog ini.
  • Telah mensupport kebanyakan framework Static Website Generator, salah satunya Hugo. Netlify secara otomatis dapat mengkonfigurasi CI/CD yang tepat dan cocok untuk website berbasis Hugo.
  • Punya fitur Deploy Preview yang dapat dikonfigurasi agar mempreview blog ketika ada commit terbaru di branch Pull Request. Ini dia yang dicari-cari πŸ˜„
  • Netlify juga memiliki fitur notifikasi yang superb. Contohnya mereka dapat menotifikasi kalau deployment blog saya berhasil atau gagal ke email pribadi. Jadi tidak perlu melihat proses deployment, cukup tunggu notifikasinya saja.



Dengan fitur Deploy Preview, saya dapat mem-preview branch PR secara online dan melakukan integration test yang sebelumnya sangat sulit bahkan tidak bisa dilakukan di lokal. Online preview dapat diakses melalui url yang random, digenerate oleh Netlify. Contoh formatnya seperti ini: https://xxxxxxx-<user>.netlify.com.

Akhirnya, saya mencoba migrasi blog dari Gitlab Page ke Netlify dan sukses tanpa kesulitan berarti karena Netlify sendiri memiliki integrasi yang hebat dengan kebanyakan Git hosting provider + Hugo. Saya bahkan menginvestasikan duit untuk menyewa domain agung.io melalui Netlify. Selain karena free HTTPS/SSL certificate + karena lagi diskon gede banget untuk domain agung.io. Thanks, Netlify!

CMS untuk Admin/Author

CMS atau Content Management System adalah jawaban dari poin kelemahan yang kedua: mengurangi bahkan menghilangkan dependensi terhadap penggunaan laptop untuk blogging. Normalnya dengan CMS, kita ingin beberapa fitur standar:

  • draft postingan terbaru,
  • meng-upload image, dan
  • melakukan preview secara online terkait perubahan tersebut.

Memiliki WYSIWYG (What You See Is What You Get) editor menurutku juga suatu nilai plus. Semua task tersebut tentunya harus dapat dikerjakan melalui interface web, karena berharap CMS punya aplikasi di smartphone sepertinya terlalu naive hehe. Lagipula, smartphone jaman sekarang sudah powerful, kemampuan browser di smartphone juga sangat baik menurutku.

Setelah googling, saya menemukan 1 solusi yang gratis dan open source (yang saat ini saya tahu). CMS ini juga mensupport Hugo. Dan ternyata CMS ini juga dikembangkan oleh Netlify, yaitu Netlify CMS. I ❀️ Netlify.

Managemen User di Netlify CMS

Untuk mengelola siapa saja yang bisa mengakses CMS interface di blog, Netlify juga memiliki fitur Netlify Identity. Dengan Netlify Identity, kita bisa mengeset siapa saja yang memiliki akses ke CMS ini. Jadi lebih aman ya.

Netlify Identity Login
Netlify Identity - Using Google and GitHub Auth Provider

CMS x Git Hosting

Agar Netlify CMS bekerja dengan benar, saya harus mengkonfigurasi hostingan blogku di Netlify untuk menggunakan Git Gateway. Dengan begitu, komponen CMS memiliki _read _dan write permissions ke blogku di Gitlab.

CMS Editorial Workflow

Di Netlify CMS Admin ada konsep yang disebutEditorial Workflow, di mana seorang editor dapat menambah/mengedit postingan blog dan mengeset statusnya ke status berikut: Draft, In Review, and Ready.

  • Draft adalah status postingan tersebut masih bersifat in-development oleh editor,
  • In Review adalah status dimana editor (dan kemungkinan oleh kontributor lainnya) sedang melakukan review,
  • Ready adalah saat editor menyatakan postingan baru tersebut sudah siap untuk dipublikasikan. Ketika Ready, maka postingan baru tersebut dapat di-push ke production.

Under the hood proses di atas: ketika membuat suatu draft (edit post atau menambah post baru), CMS akan membuat suatu branch baru dari master and membuat PR (pull request). Dan juga untuk men-track status (Draft, In Review, dan Ready), CMS ini menggunakan low-level metadata di git.

Nah, di sini lah saya menemukan keterbatasan di Gitlab. Editorial Workflow hanya bisa disupport oleh GitHub, tapi Gitlab tidakπŸ˜“. Tapi tidak apa-apa, migrasi dari Gitlab ke GitHub mudah sekali (dan saya akhirnya migrasi ke GitHub πŸ˜„).

Dashboard Netlify CMS

CMS Admin - Home Dashboard
CMS Admin - Editorial Workflow
CMS Admin - WYSIWYG Editor

Ada 1 poin minor dari Netlify CMS. Ketika diakses dari layar iPhone 7 Plus, saya terpaksa mengeset mode landspace agar dapat memunculkan beberapa tombol penting, karena tidak kelihatan kalau pakai mode portrait.

Summary

Jadi setelah 2-3 jam perjuangan dalam melakukan setup blog yang ideal (menurutku), saya berhasil mengubah sistem blog dari menggunakan Gitlab + Gitlab Page + Gitlab CI ke GitHub + Netlify (Hosting + CICD). Sekarang, workflow penulisan blogku lebih baik dari harapan awalnya. Saya juga telah menggunakan platform blog ini selama > 4 minggu dan so far sangat memuaskan.

Workflow penulisan blogku saat ini seperti berikut:

  1. Bikin branch baru dari master
  2. Buat perubahan di repositori
  3. Panggil hugo serve di lokal untuk mengetes langsung bagaimana dampak dari perubahan yang dilakukan
  4. Perbaiki kalau ada kesalahan dan dicoba terus sampai poin 3 benar-benar sesuai yang diinginkan, lalu
  5. Kalau perubahan sangat kompleks: push ke remote GitHub, buat Pull Request, dan cek Deploy Preview di Netlify; commit; push; sampai puas.
  6. Merge ke branch master dan Netlify CI akan mendeploy perubahan ke production secara otomatis.

Terima kasih sudah membaca blog postku!

Referensi: