Selama ini, bila kita membuat aplikasi yang ada fitur kirim emailnya (reset password, pengumuman, newsletter, dan sebagainya), biasanya kita menggunakan protokol SMTP. Akan tetapi, beberapa tahun belakangan ini, layanan SaaS (software as a service) bermunculan seperti cendawan di musim hujan. Sebagian besar di antaranya tidak lagi menggunakan protokol SMTP, tapi menyediakan API di atas protokol HTTP.
Ada banyak penyedia jasa layanan email, diantaranya:
SendGrid
MailerLite
Amazon
GMail
Pada artikel ini kita akan membahas yang paling populer saja, yaitu GMail. GMail menyediakan dua pilihan bila kita ingin mengirim email dari aplikasi kita : SMTP atau HTTP API. Kita akan gunakan HTTP API.
Pada artikel sebelumnya, kita sudah membahas tentang workflow development baik sebagai kontributor maupun sebagai maintainer. Dengan dua artikel tersebut, kita sudah bisa membuat perubahan dalam source code, dan juga bisa menerima dan mengintegrasikan hasil pekerjaan orang lain ke repo utama.
Walaupun demikian, kita belum membahas bagaimana cara mengelola siklus pengembangan aplikasi. Kita terutama ingin mengatasi beberapa permasalahan berikut:
bagaimana semua kontributor bisa bekerja sama dengan baik
bagaimana memastikan kode program yang dihasilkan oleh kontributor bisa direview dengan seksama
bagaimana melakukan rilis ke testing server dan production
bagaimana menangani bug yang terjadi di production sambil tetap mengerjakan development untuk versi selanjutnya
bagaimana meng-copy bugfix yang sudah kita kerjakan di atas production release (hotfix) ke development
bagaimana mengotomasi proses rilis menggunakan continuous integration/delivery
TLDR; Workflow yang kita gunakan di ArtiVisi adalah sebagai berikut:
single permanent branch : master
develop di topic branch
push branch ke remote
raise pull request dari branch
merge pull request
hapus branch setelah merge
deploy ketika ada tag dibuat
A.B.C-M.xxx : deploy ke dev (otomatis)
A.B.C-RC.xxx : deploy ke test (otomatis)
A.B.C-RELEASE : deploy ke production (manual)
bugfix di release branch, kemudian merge ke master
Pada artikel sebelumnya, kita sudah membahas tentang apa yang harus dilakukan oleh kontributor agar hasil pekerjaannya siap untuk digabungkan dengan repository utama/induk/upstream, yaitu membuat Pull Request.
Sebagai maintainer project, tugas kita adalah memilah semua kontribusi yang masuk. Bila kontribusinya bagus, maka kita masukkan ke dalam project. Bila kurang bagus, kita pandu untuk memperbaikinya.
Kita bisa menerima kontribusi dalam berbagai bentuk, misalnya:
Pull Request di aplikasi version control (Github, Gitlab, Bitbucket, dsb)
Link repository kontributor dan branchnya
File patch
Begitu kita mendapatkan kontribusi, ada beberapa hal yang harus kita lakukan, yaitu:
Beberapa waktu belakangan ini, saya membuat beberapa aplikasi yang kemudian dirilis secara open source. Karena kultur open-source di Indonesia masih berkutat di level user, maka masih jarang yang mau ikut berkontribusi. Mungkin perlu dukungan dari perusahaan agar karyawannya terlibat dalam project open source, ataupun merilis aplikasi yang dibuatnya dengan lisensi open source.
Kendala-kendala yang biasanya terdengar antara lain:
tidak punya cukup waktu luang
tidak tertarik dengan aplikasi atau teknologi yang digunakan
merasa belum cukup mahir coding
tidak familiar dengan cara kerja menggunakan Git
Masalah yang pertama dan kedua, saya tidak ada solusinya.
Untuk yang ketiga, seharusnya coba saja kontribusi. Satu dua baris tetap diterima. Kalaupun ada yang perlu diperbaiki, biasanya akan saya berikan feedback yang jelas.
Sejak beberapa waktu yang lalu, blog ini sebetulnya sudah pindah hosting dari Github ke Gitlab. Alasannya sederhana, Github sampai saat artikel ini ditulis tidak mendukung SSL untuk custom domain. Ada sih akal-akalan menggunakan CloudFlare, seperti dijelaskan di artikel ini, tapi tetap saja koneksi dari CloudFlare ke Github tidak terproteksi.
Oleh karena itu, saya pindahkan hostingnya ke Gitlab. Berikut langkah-langkah untuk memasang sertifikat SSL.
