DevOps Pipeline

Sebagaimana yang kita ketahui bersama, DevOps adalah gerakan yang

merevolusi struktur organisasi dengan menyatukan tim Developer dan IT

Operations. Hasilnya adalah perubahan kultur di mana kedua tim tersebut

saling bekerja sama, menerapkan automasi, meningkatkan kecepatan

proses deployment, dan membuat perusahaan menjadi lebih fleksibel. 

Selain itu, manfaat utama dari implementasi DevOps adalah memperbaiki

dan merampingkan alur deployment, sekaligus mengurangi frekuensi dan

dampak insiden. Oleh karenanya, kita perlu suatu cara yang dapat

memudahkan tim dalam mengurusi proses deployment. Nah, salah satu

praktiknya adalah memanfaatkan DevOps Pipeline.

DevOps Pipeline (atau biasa disebut juga sebagai CI/CD Pipeline)

merupakan serangkaian proses dan tools terotomatisasi yang

memungkinkan Developer dan IT Operations untuk bekerja secara kohesif

untuk men-deploy kode ke lingkungan production.

DevOps Pipeline merupakan salah satu contoh implementasi yang cocok

kita kaitkan dengan CALMS Framework yang baru saja dibahas dalam

modul sebelumnya. DevOps Pipeline terdiri dari beberapa fase yang

melibatkan tim Developer dan IT Operations. Mari kita tengok kaitannya

DevOps Pipeline dengan unsur-unsur pada CALMS Framework.

 Culture

Pada praktiknya, DevOps Pipeline melibatkan tim Developer dan IT

Operations yang menuntut mereka untuk terus bekerja sama dan

 berkolaborasi demi menghadirkan aplikasi yang komprehensif untuk

pengguna. Selain itu, DevOps Pipeline terdiri dari beberapa fase

pengembangan aplikasi, yang mana setiap fasenya harus

menyertakan keamanan tanpa kompromi. Ini menunjukkan bahwa

DevOps pipeline dan CALMS Framework selaras pada praktiknya.

 Automation

Automation adalah hal yang penting pada DevOps Pipeline. Tanpa

adanya automation, maka proses handoff akan manual dan

memakan waktu. Untuk itu, saat menggunakan DevOps Pipeline,

Developer dan IT Operations harus bisa memaksimalkan peran

automation di setiap fase agar bisa mengirimkan fitur dengan cepat.

 Lean

Salah satu tujuan umum dari DevOps adalah perusahaan dapat

melakukan deployment sesering dan secepat mungkin. Karena fase-

fase pada DevOps Pipeline straightforward, proses yang

semula belibet bisa menjadi cepat dan ringkas.

 Measurement

Salah satu fase pada DevOps Pipeline adalah monitor, artinya kita

memantau aplikasi secara menyeluruh melalui metrik-metrik yang

mengukur seluk-beluk infrastruktur guna memastikan bahwa aplikasi

berjalan sesuai dengan yang diharapkan.

  Sharing

Karena melibatkan dua pihak, yakni Developer dan IT Operations,

DevOps Pipeline dapat mewujudkan lingkungan yang saling berbagi

pengetahuan dan tanggung jawab. Kedua tim tersebut sama-sama

memiliki peran untuk menyajikan aplikasi yang komprehensif melalui

sebuah tools bersama. Jadi, jika aplikasi gagal beroperasi, mereka

sama-sama harus menyelidiki dan memperbaiki masalahnya.

Kendati DevOps Pipeline bisa saja berbeda-beda untuk setiap

perusahaan, tetapi umumnya mencakup komponen fundamental,

seperti continuous integration, continuous delivery/deployment, automation

testing, validation, dan reporting. DevOps Pipeline pun dapat mencakup

satu atau lebih tahapan manual yang memerlukan campur tangan

manusia sebelum kode diizinkan untuk diproses ke fase selanjutnya. 

Berikut adalah gambar yang menunjukkan tahapan-tahapan dalam

DevOps Pipeline.

Semoga Anda tidak bingung ya melihat gambar di atas. Apabila Anda

masih merasa kesulitan dalam memahami DevOps Pipeline, mari kita

bedah setiap tahapan satu per satu.

 Code

Pada tahap ini, tim Developer menulis dan mengembangkan kode

aplikasi dalam bahasa pemrograman tertentu, entah itu Java,

JavaScript, Python, C#, dsb. Mereka menulis kode di lingkungan

development agar segala perubahan atau penambahan fitur tak

berimbas ke aplikasi yang dipakai pengguna, seperti misalnya di

komputer pribadi menggunakan IDE alias Integrated Development

Environment.

Nah, selepas kode siap, Developer kemudian

mengirimkan/mengunggah (push) kode yang telah ditulis ke sebuah

lokasi terpusat, umumnya adalah Git repository.

 Build

Selepas kode di-push ke repository dan dipastikan aman untuk lanjut

ke fase berikutnya, kode tadi lantas dieksekusi melalui proses build.

Dalam konteks pengembangan aplikasi, “build” mengacu pada

proses yang mengubah file dan aset lainnya menjadi produk

perangkat lunak dalam bentuk final atau siap di-deploy.

Langkah-langkahnya sebagai berikut:

o Meng-compile kode.

o Memeriksa gaya dan standar dari kode.

o Menganalisis tingkat kompleksitas dan pemeliharaan kode.

o Memvalidasi dependencies pada kode.

 o Membuat sebuah artifact, seperti container

image, compressed file (jar, zip, dll), installer, package, dan

sebagainya.
o Menjalankan unit test.

Usai semua proses ini sukses, barulah kita bisa masuk ke fase

berikutnya.

 Test

Tahapan berikutnya adalah test alias pengujian. Di sini, artifact yang

sedianya sudah dibuat akan diuji apakah memenuhi persyaratan

fungsional, kinerja, desain, dan implementasi yang ditentukan atau

tidak.

Berikut beberapa contoh praktik pengujian yang dilakukan.

o Functional testing: Memvalidasi sistem aplikasi dengan

kebutuhan fungsional.
o Integration testing: Setiap unit atau komponen aplikasi

digabungkan dan diuji sebagai sebuah grup/kelompok.

o Regression testing: Menjalankan kembali functional dan non-

functional test untuk memastikan bahwa aplikasi yang telah

dikembangkan dan diuji sebelumnya masih berfungsi setelah

terjadi perubahan kode.

o Acceptance testing: Pengujian dilakukan oleh klien,

pengguna, atau entitas resmi lainnya guna menentukan

apakah kebutuhan aplikasi dan proses bisnis sudah terpenuhi

atau belum.
 o Load testing: Pengujian kinerja aplikasi yang menyimulasikan

beban kerja atau traffic pada dunia nyata.

o Security testing: Mengidentifikasi kerentanan, kelemahan,

ancaman, dan risiko keamanan pada aplikasi guna mencegah

serangan berbahaya dari penyusup.

Pengujian yang dilakukan tentunya disesuaikan dengan kebutuhan

pada masing-masing perusahaan. Bisa jadi, suatu perusahaan hanya

menerapkan beberapa praktik pengujian saja. Namun, dalam kasus

lain, mungkin saja ada perusahaan yang menerapkan semua praktik

pengujian. Oke, setelah semua pengujian berhasil lolos, tahapan

selanjutnya pun dimulai.

 Release

Tahapan selanjutnya selepas test adalah release. Di fase ini, artifact

yang telah lolos pengujian kemudian dikemas/dibungkus dengan

nomor versi (version number) tertentu sebelum nanti akhirnya di-

deploy.

Pemberian nomor versi tidak hanya untuk menunjukkan bahwa

suatu produk telah diubah atau diperbarui, melainkan juga dapat

digunakan untuk mengomunikasikan informasi penting lainnya,

seperti urutan rilis, tingkat perubahan, dan tanggal rilis.

 Deploy

Usai diberi nomor versi, artifact akan di-deploy ke target

environment/lingkungan (kumpulan sumber daya–seperti server, dll–

 untuk meng-hosting aplikasi) yang sesuai, entah itu ke lingkungan

test, staging, alpha, beta, atau production sekalipun.

 Monitor

Fase terakhir pada siklus DevOps pipeline adalah monitor. Dalam

tahap ini, umumnya aplikasi sudah di-deploy ke lingkungan

production dengan sempurna sehingga bisa dinikmati oleh

pengguna. Oleh karenanya, kita perlu memonitor aplikasi agar bisa

mendeteksi error ataupun kejanggalan dengan cepat dan secara

tanggap langsung memperbaikinya.

Nah, sekarang sudah paham nih fase-fase atau tahapan pada siklus

DevOps pipeline. Lantas, pertanyaan yang selanjutnya muncul adalah,

“Bagaimana jika terjadi kegagalan di salah satu tahapan?” Jawabannya

jelas, proses yang tengah dilakukan akan dihentikan sehingga tak bisa

lanjut ke fase berikutnya. 

Misalnya, Developer push kode ke Version Control System. Dengan ini,

DevOps pipeline pun akan bekerja secara otomatis melakukan build, lalu

test. Apabila ada salah satu dari sekian test yang gagal, Developer harus

memperbaiki kodenya terlebih dahulu dan melakukan push kembali. Terus

begitu sampai setiap tahapan tereksekusi dengan sempurna.

Selain itu, saat kita belajar DevOps pipeline atau CI/CD pipeline, akan erat

kaitannya dengan istilah-istilah seperti Continuous Integration, Continuous

Delivery, dan Continuous Deployment. 

Tahukah Anda bahwa istilah CI/CD pada dasarnya diambil dari ketiga

istilah tersebut. Sebenarnya, CI/CD merupakan akronim dari Continuous

Integration dan Continuous Delivery/Deployment. Apa sih perbedaan

mendasar di antara ketiganya?

Mungkin sebagian dari Anda sudah ada yang tahu. Nah, bagi yang belum

familier dan mulai penasaran, Mari kita bedah ketiganya satu per satu.

 Continuous Integration

Continuous integration (CI) merupakan praktik pada proses

pengembangan aplikasi di mana Developer dengan rutin dan teratur

memasukkan (commit) atau menggabungkan (merge) setiap

perubahan kode (code changes) mereka ke sebuah repositori

terpusat (central repository) dan/atau ke mainline trunk (seperti

branch master/main), setelah itu proses build dan unit test secara

otomatis pun dijalankan.

Tujuan utama dari continuous integration adalah untuk menemukan

dan mengatasi bug atau error lebih cepat, meningkatkan kualitas

 aplikasi, dan mengurangi waktu yang diperlukan untuk memvalidasi

dan merilis pembaruan perangkat lunak (software update).

Kemudian, mengapa praktik CI ini diperlukan? Di masa lampau,

Developer bekerja secara terpisah dan terisolasi dari tim lain dalam

waktu yang lama. Ditambah, mereka melakukan penggabungan

(merge) perubahan kode ke central repository dan/atau ke mainline

trunk hanya jika tugas mereka komplet. Nah, hal ini membuat proses

penggabungan perubahan kode menjadi sulit dan memakan waktu,

bahkan kerap pula mengakibatkan bug yang terakumulasi untuk

waktu yang lama tanpa koreksi sama sekali. Inilah faktor-faktor yang

mempersulit penyampaian update ke pengguna dengan cepat.

Nah, dengan hadirnya CI, Developer kini bisa rutin memasukkan

(commit) kode ke central repository dan/atau ke mainline trunk

menggunakan version control system seperti Git. Pada praktiknya,

proses CI secara otomatis akan melakukan build dan menjalankan

unit test pada setiap perubahan kode yang baru agar dapat

mengidentifikasi bug atau error dengan segera.

 Continuous Delivery

Continuous delivery (CD) adalah praktik pada proses

pengembangan aplikasi di mana perubahan kode (code changes)

secara otomatis dipersiapkan sebelum nantinya dikirim ke

lingkungan production.
Continuous delivery merupakan teknik lanjutan dari continuous

integration. Jika di CI hanya sampai proses build dan unit test, di CD

ini prosesnya hingga deploy semua perubahan kode ke lingkungan

testing, staging (pre-production), dan/atau production. Namun, untuk

bisa men-deploy ke production, perlu melalui persetujuan manual

(manual approval) terlebih dahulu, entah itu oleh Developer yang

lebih senior, manajer, atau siapa pun yang berhak.

Selain itu, continuous delivery pun memungkinkan Developer untuk

melakukan pengujian otomatis di luar unit test saja sehingga mereka

dapat menguji dan memverifikasi kualitas software update yang

akan di-deploy ke production (yang pada akhirnya sampai ke

pengguna). Pengujian ini dapat mencakup UI testing, load testing,

integration testing, dll. Dengan begitu akan membantu pengembang

memvalidasi pembaruan secara lebih menyeluruh dan menemukan

masalah secara pre-emptive.

Bila praktik CD diimplementasikan dengan tepat, niscaya Developer

senantiasa memiliki artifact yang sudah siap deploy karena telah

melewati berbagai standar pengujian.

Salah satu kesalahpahaman tentang continuous delivery adalah jika

kita mengatakan bahwa proses ini men-deploy langsung setiap

perubahan kode ke lingkungan production. Padahal, poin dari

 continuous delivery bukanlah itu, melainkan sekadar memastikan

bahwa setiap perubahan kode siap untuk di-deploy ke production

melalui beberapa cara, umumnya adalah dengan men-deploy kode

yang sudah di-build sebelumnya ke lingkungan testing untuk

dilakukan pengujian otomatis. Jika mendapatkan persetujuan dari

pihak terkait, barulah aplikasi di-deploy ke production.

Nah, justru praktik deploy aplikasi langsung ke lingkungan

production adanya di continuous deployment.

 Continuous Deployment

Continuous delivery dan continuous deployment pada hakikatnya

adalah proses yang “serupa tapi tak sama”. Perbedaannya,

continuous delivery memiliki proses persetujuan manual (manual

approval) sebelum aplikasi di-deploy ke production, sementara

continuous deployment tidak memiliki hal tersebut.

Jadi, dengan continuous deployment, proses deploy aplikasi ke

lingkungan production berlangsung secara otomatis tanpa ada

persetujuan eksplisit dan intervensi manusia. Dengan begitu,

continuous deployment memungkinkan pemberian feedback yang

berkelanjutan oleh pengguna setiap kali suatu fitur atau update

sampai ke perangkat mereka.

Kesimpulannya, DevOps pipeline atau CI/CD pipeline merupakan contoh

yang tepat bagaimana tim Developer dan IT Operations bekerja sama

dalam menggunakan tools untuk merampingkan alur kerja dan

menstandardisasi praktik pada proses pengembangan aplikasi.

Selain itu, DevOps pipeline pun dapat memastikan bahwa kualitas kode

akan terjaga, keamanan akan terjamin, dan proses deployment akan

berlangsung cepat dan konsisten.

DevOps Tools

Kita sudah memahami cara mempraktikkan DevOps melalui DevOps

pipeline. Namun, pembahasan tersebut belumlah sepenuhnya genap.

Mengapa begitu? Ketahuilah bahwa praktik DevOps sejatinya

membutuhkan tools agar penerapannya menjadi lebih mudah, konsisten,

dan terprediksi. Oleh karena itu, kali ini kita akan ulas mengenai DevOps

tools secara lengkap. 

Tools yang akan kita bahas di sini bervariasi, mulai dari yang disediakan

oleh cloud provider ternama seperti AWS hingga yang umum sekalipun.
Kali ini, Anda hanya perlu mengetahui nama dan fungsi tools yang akan

disebutkan terlebih dahulu, tak usah pening memikirkan cara

menggunakannya. Kelak, di kelas-kelas berikutnya barulah Anda akan

praktikkan. 

AWS adalah salah satu cloud provider yang menyediakan layanan dan

tools untuk membantu kita dalam mempraktikkan DevOps di perusahaan.

AWS memiliki rentetan DevOps tools yang bisa kita gunakan kapan saja

dan di mana saja sesuai kebutuhan dengan hanya membayar melalui

mekanisme pay-as-you-go (bayar sesuai pemakaian).

Oke, cukup soal pengenalan AWS-nya, mari kita kembali ke topik DevOps.

Dalam mendukung kesuksesan praktik DevOps di suatu perusahaan, ada

beberapa kategori best practice yang perlu kita perhatikan beserta tools

yang sesuai untuk menerapkannya (akan dibagi antara tools yang bersifat

umum dan AWS). 

Komunikasi dan Kolaborasi

Dalam mempraktikkan DevOps, tim Developer dan IT Operations perlu

menetapkan kultur yang kuat seputar transparansi informasi dan

komunikasi supaya keduanya punya rasa saling memiliki satu sama lain.

Dengan begitu, alih-alih hanya peduli dengan pekerjaan masing-masing

tim, mereka justru akan melihat kebutuhan proyek secara kolektif.

Selain itu, penting pula bagi tim Developer dan IT Operations untuk
membangun rasa empati dan kepercayaan di antara mereka agar mampu

berkolaborasi menuju tujuan bersama. Maka dari itu, diperlukan DevOps

tools untuk mendukung proses dan alur kerja yang terkonsolidasi.

Berikut beberapa tools yang bisa mengimplementasikan komunikasi dan

kolaborasi antartim di perusahaan.

 Platform komunikasi dan kolaborasi terpadu

Perusahaan bisa memfasilitasi hal ini dengan menyediakan platform

atau aplikasi agar setiap tim bisa saling berkomunikasi dan

 berkolaborasi satu sama lain. Hal ini pun dapat mempercepat

komunikasi ke seluruh tim Developer, IT Operations, dan bahkan

tim-tim lain di perusahaan seperti Marketing atau Sales. Dengan

begitu, semua orang bisa lebih dekat dan selaras dengan tujuan dan

proyek yang sedang digarap.

Berikut beberapa contoh platform komunikasi dan kolaborasi terpadu

(dibagi berdasarkan tools umum dan tools AWS).

Umum

Microsoft Teams
Slack
Workplace
Cisco Webex Teams

 Sekilas tentang Amazon Chime, ia adalah layanan komunikasi yang

memungkinkan kita untuk mengadakan rapat, mengobrol, dan

melakukan panggilan bisnis di dalam dan di luar perusahaan,

 semuanya hanya dengan satu aplikasi.

 Cloud

Selanjutnya adalah Cloud. Tim Developer dan IT Operations tentu

perlu berinovasi dengan cepat demi menghadirkan aplikasi yang

andal dan aman. Untuk itu, perusahaan bisa mengandalkan cloud

computing untuk berbagai teknologi guna mendukung upaya

pengembangan aplikasi.

Alih-alih harus membeli dan memelihara perangkat-perangkat server

secara fisik, Anda bisa dengan mudah membuat

suatu environment (yang berisi server, jaringan, penyimpanan, dll)

secara on-demand (sesuai permintaan) menggunakan cloud

provider seperti AWS.

Selain itu, AWS pun menyediakan layanan atau tools terkait DevOps

yang sudah siap pakai sehingga memungkinkan kolaborasi dengan

lebih mudah dan pada akhirnya dapat meraih tujuan bersama

 dengan lebih cepat.

 IDE

IDE alias integrated development environment dapat membantu

para Developer untuk menulis, menjalankan, dan men-debug kode

aplikasi dengan mudah.

Percayalah, penggunaan IDE sesungguhnya dapat meningkatkan

produktivitas Developer berkat hadirnya fitur-fitur seperti syntax

highlighting, autocomplete, dan banyak lagi.

Selain itu, tim Developer dan IT Operations pun perlu terus

berkolaborasi. Maka dari itu, akan semakin ciamik lagi bila Anda

menggunakan collaboration tool. Dengan begitu, setiap orang bisa

menulis kode secara bersamaan secara real-time pada suatu

project.

Memanfaatkan collaboration tool memungkinkan terjadinya proses

komunikasi dan kolaborasi yang baik, entah itu sesama Developer

atau bahkan dengan IT Operations sehingga mereka bisa

berkontribusi untuk memperbaiki kode agar kestabilan infrastruktur

dapat terjaga saat proses deployment.

Berikut beberapa contoh IDE yang mendukung collaboration

tool (dibagi berdasarkan tools umum dan tools AWS).

 Umum

Visual Studio dengan fitur Live Share AW

Intellij IDEA dengan fitur Code With Me

 Sekilas mengenai AWS Cloud9, ia merupakan IDE berbasis cloud

dari AWS yang dapat kita gunakan untuk menulis, menjalankan, dan

men-debug kode hanya dengan web browser. Keren, kan? Nggak

perlu unduh atau instal aplikasi sama sekali.
 Sela  n itu, kita juga bisa menggunakan AWS Cloud9 untuk me

m-push (mengunggah) perubahan atau penambahan

Oke, itu poin pembahasan mengenai komunikasi dan kolaborasi beserta

tools yang dipakai. Bila Anda simak baik-baik, poin pembahasan

mengenai Komunikasi dan Kolaborasi ini relevan dengan CALMS

Framework yang kita bahas pada modul sebelumnya, yakni tentang

Culture dan Sharing. Selanjutnya, mari kita bahas tentang CI/CD.

CI/CD

Ingatan Anda mungkin masih segar soal ini karena kita baru saja

membahas CI/CD di submodul sebelumnya.

Ketahuilah bahwa praktik semacam continuous integration (CI) dan

continuous delivery/deployment (CD) akan sangat efektif dan berjalan

dengan baik apabila didukung oleh tools yang tepat. Dengan begitu, CI/CD
akan menghadirkan kontinuitas tanpa batas di setiap fase pada proses

pengembangan aplikasi. 

Tools terkait CI/CD ini nantinya mampu untuk mengotomatiskan

pengintegrasian kode aplikasi yang dikembangkan setiap orang,

memeriksa compliance (kepatuhan) terhadap standar tertentu,

menjalankan berbagai pengujian, mengoper kode ke lingkungan testing,

dan men-deploy aplikasi ke lingkungan production. Proses ini dilakukan

berulang kali dan secara andal setiap kali ada perubahan atau

penambahan kode baru.

Dalam poin CI/CD ini, tools yang digunakan dibagi menjadi beberapa

kategori berdasarkan siklus DevOps pipeline.

 Code

Tahapan ini terjadi setelah Developer selesai menulis kode di IDE

dan memasukkannya ke sebuah repository atau version control

system.

Version control system merupakan tools untuk mengelola berkas-

berkas proyek yang kita garap. Dengan tools tersebut, setiap orang

yang berhak bisa mengakses dokumen pendukung proyek dan kode

aplikasi, melihat riwayat perevisian, membandingkan perubahan

kode dari waktu ke waktu, atau mengembalikan kode ke versi

sebelumnya. Dengan begitu, akan memudahkan bagi Developer

ataupun IT Operations untuk berkolaborasi dalam menggarap

proyek bersama.

Berikut beberapa contoh version control system yang bisa Anda

pakai (dibagi berdasarkan tools umum dan tools AWS).

Umum AWS

GitHub
GitLab AWS CodeCommit
BitBucket

 Sekilas tentang AWS CodeCommit, ia adalah layanan version

control system milik AWS yang menyediakan repositori berbasis Git

yang aman. Cara kerjanya mirip seperti GitHub, hanya saja ini
 dikelola oleh AWS. Layaknya version control system pada

umumnya, AWS CodeCommit memungkinkan kita menyimpan

berkas-berkas dan kode aplikasi yang kita punya secara aman di

sebuah tempat terpusat yang dinamakan repository.

Dari AWS CodeCommit, Anda bisa mengonfigurasi agar setiap

perubahan atau penambahan kode yang terjadi bisa langsung

dilakukan proses build.

 Build

Seperti yang sudah kita pelajari sebelumnya, proses build ini

berguna untuk mengubah file dan aset lainnya menjadi produk

perangkat lunak dalam bentuk final atau siap di-deploy.

Berikut beberapa contoh tools yang digunakan pada proses build

(dibagi berdasarkan tools umum dan tools AWS).

Umum AWS

Jenkins
Travis CI AWS CodeBuild
CircleCI

 AWS CodeBuild adalah layanan build yang dikelola oleh AWS yang

dapat secara otomatis meng-compile kode aplikasi, menjalankan

pengujian, dan memproduksi software packages atau artifact yang

siap untuk di-deploy.

 Test

Tahapan ini sebenarnya tergantung pada jenis pengujian yang

dilakukan. Apabila sekadar unit test, pengujian bisa dilakukan saat

proses build berlangsung. Namun, jika ingin melakukan load testing,

kita perlu men-deploy-nya terlebih dahulu ke lingkungan testing

dengan bantuan AWS CodeDeploy. Opsi lain, jika Anda

menginginkan suatu pengujian yang spesifik, bisa juga

memanfaatkan third-party tools yang tersedia di AWS Marketplace,

seperti Gremlin, Testable, LoadRunner, UFT One, dll.

 Release

Fase ini sebenarnya sederhana. Kode aplikasi yang telah lolos

pengujian kemudian disimpan ke repository, registry, atau storage

dalam bentuk software packages, container image, dsb., dengan

diberi nomor versi tertentu yang menandakan bahwa aplikasi sudah

final dan siap di-deploy.

Apabila artifact yang dimaksud berbentuk compressed file, kita bisa

menaruhnya di object storage seperti Amazon S3. Akan tetapi, jika

berbentuk container image, berikut adalah contoh tools yang bisa

digunakan (dibagi berdasarkan tools umum dan tools AWS).

Umum AWS

Docker Hub Amazon ECR

JFrog Artifactory AWS CodeArtifact
 Sedikit pembahasan mengenai Amazon ECR (Elastic Container

Registry) dan AWS CodeArtifact.

o Amazon ECR merupakan layanan penyimpanan (registry)

untuk container image di AWS. Jadi, kita bisa dengan

mudah push (simpan) container image secara aman ke

Amazon ECR. Saat ingin menjalankannya di server, kita

tinggal pull (ambil) dari registry tersebut sesuai dengan tag

yang Anda tetapkan pada container image tersebut.

o AWS CodeArtifact adalah layanan artifact repository dari

AWS untuk menyimpan, memublikasikan, dan

membagikan software packages yang digunakan pada proses

pengembangan aplikasi. Layanan ini dapat bekerja dengan

package manager dan build tools yang umum seperti Maven,

Gradle, npm, yarn, twine, dan pip.

Dua layanan AWS ini bisa Anda pilih sesuai dengan tipe aplikasi

yang Anda miliki.

 Deploy

Aplikasi akan masuk tahap ini apabila kode sudah dipastikan benar-

benar aman dan siap untuk di-deploy ke lingkungan production.

Setelah di-deploy, perubahan atau penambahan kode yang

dilakukan akan bisa langsung dirasakan oleh pengguna.

Berikut adalah beberapa contoh tools yang bisa digunakan untuk

deploy aplikasi (dibagi berdasarkan tools umum dan tools AWS).

 Umum AWS

Heroku AWS CodeDeploy

Netlify AWS Elastic Beanstalk
GitHub Pages

 Mari kita bahas selintas tentang AWS CodeDeploy dan AWS Elastic

Beanstalk.
o AWS CodeDeploy adalah layanan yang mengotomatiskan

deployment aplikasi sehingga memungkinkan Anda untuk

men-deploy dengan andal dan cepat. Layanan ini akan

mengotomatiskan proses deployment kode ke berbagai

layanan komputasi yang tersedia di AWS, termasuk Amazon

EC2 (server virtual), AWS Fargate (komputasi serverless

untuk container), AWS Lambda (platform serverless untuk

menjalankan kode), atau server on-premise (lokal).

o AWS Elastic Beanstalk merupakan layanan platform-as-a-

service yang memungkinkan kita untuk men-deploy dan

mengelola aplikasi di AWS dengan cepat tanpa harus

mengurusi persoalan infrastruktur. Kita hanya perlu

mengunggah kode aplikasi dan Elastic Beanstalk secara

otomatis akan mengurusi setiap detail yang diperlukan untuk

menjalankan aplikasi.

Anda bisa memilih opsi target deployment yang diinginkan, apakah ke

server, container, serverless, dsb. Itu semua tentunya kembali ke

kebutuhan masing-masing perusahaan.

  Monitor

Selepas aplikasi di-deploy ke production dan dapat dinikmati

pengguna, langkah penting selanjutnya adalah

memonitor/memantau berjalannya aplikasi tersebut. Pemantauan ini

menjadi penting karena kita perlu mengetahui bagaimana aplikasi

bekerja di dunia nyata.

Apakah sesuai dengan yang diharapkan? Apakah server akan

kewalahan menghadapi lonjakan pengguna? Apakah semua fitur

berjalan dengan semestinya saat diakses pengguna? Nah,

pertanyaan-pertanyaan semacam ini akan bisa kita temukan

jawabannya jika melakukan pemantauan dengan baik dan benar.

Berikut adalah beberapa contoh tools yang bisa digunakan untuk

memantau aplikasi (dibagi berdasarkan tools umum dan tools AWS).

Umum AWS

Prometheus AWS X-Ray

Elastic Stack Amazon CloudWatch
Dynatrace

 Kita akan bahas soal AWS X-Ray dan Amazon CloudWatch nanti di

poin Monitoring dan Logging.

Nah, itu dia penjelasan dari setiap tahapan beserta tools yang dapat

digunakan pada CI/CD pipeline. Mungkin sebagian dari Anda bingung

dengan tools yang terpisah sehingga memunculkan pertanyaan, “Apakah

ada layanan yang bisa memadukan semua tools di atas sehingga

membuat proses CI/CD menjadi lebih mudah?” Ah, tentu saja ada. Anda

harus berkenalan dengan layanan bernama AWS CodePipeline.

AWS CodePipeline adalah layanan continuous delivery yang

memungkinkan kita untuk membuat model, memvisualisasikan, dan

mengotomatiskan langkah-langkah yang diperlukan untuk merilis

perangkat lunak. Dengan layanan ini, kita bisa mengonfigurasi tahapan-

tahapan pada CI/CD pipeline sehingga memudahkan proses

pengembangan aplikasi.

Berikut gambaran DevOps pipeline atau CI/CD pipeline bila kita

memanfaatkan tools dari AWS.

Bisa Anda lihat bahwa AWS CodePipeline mengintegrasikan beberapa

layanan seperti AWS CodeCommit, AWS CodeBuild, dan AWS

CodeDeploy (masih banyak layanan lain yang bisa diintegrasikan).

Supaya lebih jelas, berikut diagram yang menunjukkan contoh proses

perilisan perangkat lunak menggunakan AWS CodePipeline.

Dalam contoh ini, ketika Developer melakukan perubahan, pembaruan,

atau perbaikan kode dan mengunggahnya ke version control system, AWS

CodePipeline secara otomatis akan mendeteksi perubahan tersebut dan

kemudian dilakukan proses build. Jika ada pengujian seperti unit test,

pengujian tersebut akan dijalankan selama proses build.

Setelah unit test dan proses build selesai, kode segera dikirim ke

lingkungan testing untuk dilakukan pengujian seperti load testing, dan lain-

lain. Apabila pengujian tersebut berhasil dan secara manual disetujui oleh

pihak terkait untuk lanjut ke production, CodePipeline segera men-deploy

kode ke lingkungan production (berisi server supaya aplikasi bisa live ke

publik).

Setelah aplikasi bisa digunakan oleh pengguna, mereka akan senantiasa

mengirimkan feedback berupa ide untuk versi aplikasi berikutnya,

permintaan fitur tertentu, atau pelaporan bug. Feedback ini kemudian

diterima oleh Developer dan akan diimplementasikan ke aplikasi. Siklus ini

akan berulang terus-menerus selama aplikasi tersedia di pasaran.

Nah, itulah beberapa DevOps tools yang perlu kita ketahui dalam proses

CI/CD. Intinya, dengan menggunakan DevOps tools yang tadi

disampaikan, niscaya akan membantu kita untuk mengasah ketangkasan

pada proses pengembangan (development) dan penggelaran

(deployment) aplikasi, seraya senantiasa memberikan feedback yang

konstruktif dan memperingatkan kepada tim terkait tentang segala isu

yang muncul.

Perlu Anda ingat kembali bahwa tahapan-tahapan pada DevOps pipeline

atau CI/CD pipeline tidaklah mutlak. Itu artinya, setiap perusahaan bisa

jadi memiliki urutan atau tahapan yang berbeda tergantung keputusan

bisnis dan tentu jenis aplikasi yang digunakan.

Bila Anda simak baik-baik, poin pembahasan CI/CD ini relevan dengan

CALMS Framework yang kita bahas pada modul sebelumnya, yakni

tentang Automation dan Lean.

Infrastructure as Code

Kita sedari tadi kerap menyebutkan soal lingkungan development, testing,

dan production. Mereka sejatinya sama-sama terdiri dari sekumpulan

perangkat keras dan perangkat lunak, yang membedakan adalah

peruntukannya.

Lingkungan development biasanya menggunakan komputer pribadi milik

Developer agar bebas diotak-atik. Lingkungan testing umumnya adalah

server yang dibuat mirip dengan production dengan tujuan

menyimulasikan dunia nyata. Sementara itu, lingkungan production terdiri

dari server yang sudah dikonfigurasi sedemikian rupa agar mampu

menghadapi pengguna sesungguhnya.

Masalahnya, apabila kita membuat dan mengonfigurasi environment

(lingkungan) tersebut secara manual, tentu akan rawan kesalahan dan

menjadi tidak fleksibel. Namanya juga manusia, bisa jadi sewaktu-waktu

salah mengonfigurasi server dan ujung-ujungnya aplikasi tidak berjalan

sesuai dengan apa yang kita harapkan.

Oleh sebab itu, hadirlah prakarsa mengenai Infrastructure as Code alias

IaC, yang merupakan praktik di mana infrastruktur (seperti server,

jaringan, dll) dibuat dan dikelola menggunakan kode serta teknik

pengembangan perangkat lunak, seperti version control system dan

continuous integration.

Salah satu contoh manfaat dari penerapan Infrastructure as Code adalah

ia dapat membantu tim Developer dalam membangun aplikasi

di production-like environment (seperti lingkungan testing atau staging),

yang berguna untuk mendeteksi masalah lebih dini sebelum di-deploy ke

production.

Dalam pembahasan Infrastructure as Code ini, umumnya terdapat 2

kategori yang perlu kita bedah, yakni infrastructure automation dan

configuration management.

 Infrastructure automation

Infrastructure automation dalam hal ini adalah pembuatan

infrastruktur dan sumber daya sejenis secara otomatis hanya

dengan menggunakan kode. Dengan cara ini, baik Developer

maupun IT Operations dapat berinteraksi dengan infrastruktur

secara terprogram dalam skala besar tanpa harus

mengonfigurasinya secara manual.

 Selain itu, musabab didefinisikan oleh kode, kita bisa

memperlakukan infrastruktur dengan cara yang serupa dengan kode

aplikasi. Kita bisa men-deploy infrastruktur dan server dalam waktu

singkat, memperbaruinya dengan patch dan versi terbaru,

mengembalikan versi sebelumnya, atau menduplikasinya dengan

cara yang berulang.

Bahkan, Anda juga dapat melacak perubahan yang terjadi,

mengoptimalkan resource (sumber daya), dan meningkatkan system

uptime (waktu kerja sistem).

Berikut adalah contoh tools yang bisa digunakan untuk kategori

infrastructure automation (dibagi berdasarkan tools umum dan tools

AWS).

Umum AWS

Terraform AWS CloudFormation

 Sekilas tentang AWS CloudFormation, ia merupakan layanan

Infrastructure as Code (IaC) yang dapat membantu menyiapkan

AWS resource (sumber daya AWS) sehingga kita bisa

menghabiskan lebih sedikit waktu untuk mengelola infrastruktur dan

lebih banyak waktu untuk berfokus pada aplikasi yang berjalan di

AWS.

Kita tinggal buat template (berisi kode untuk membuat infrastruktur)

 yang mendefinisikan semua AWS resource yang dibutuhkan (seperti

server, jaringan, database, dll), AWS CloudFormation pun akan

menangani pembuatan dan pengonfigurasian resource tersebut.

Dengan begitu, kita tidak perlu lagi membuat atau mengonfigurasi

resource satu per satu.

 Configuration management

Dengan configuration management (manajemen konfigurasi), tim

Developer dan IT Operations bisa menggunakan kode untuk

mengautomasi pengonfigurasian sistem operasi dan server, tugas

operasional, serta banyak lagi. Penggunaan kode semacam ini

membuat perubahan konfigurasi menjadi repeatable (dapat diulang)

dan standardized (distandardisasi) sehingga membebaskan

Developer dan IT Operations dari konfigurasi sistem operasi,

aplikasi sistem, atau perangkat lunak server yang manual.

Berikut adalah beberapa contoh tools yang bisa digunakan pada

kategori configuration management (dibagi berdasarkan tools umum

dan tools AWS).

Umum AWS

Chef
Puppet AWS OpsWorks
Ansible

 Selintas mengenai AWS OpsWorks, ia adalah layanan configuration

management (manajemen konfigurasi) yang menyediakan server

 terkelola untuk Chef dan Puppet. Chef dan Puppet adalah platform

automasi yang memungkinkan kita menggunakan kode untuk

mengotomatiskan konfigurasi server.

Dengan Chef dan Puppet, AWS OpsWorks dapat membantu kita

dalam mengotomatiskan proses konfigurasi, deploy, dan

pengelolaan server di seluruh Amazon EC2 instance atau

lingkungan on-premise.

Itu dia beberapa DevOps tools terkait Infrastructure as Code yang perlu

diketahui. Bila Anda simak baik-baik, poin pembahasan ini relevan dengan

CALMS Framework yang kita bahas pada modul sebelumnya, yakni

tentang Automation.

Arsitektur Microservices

Arsitektur microservice merupakan sebuah pendekatan desain untuk

membangun aplikasi sebagai kumpulan service (layanan) yang loosely

coupled (setiap service tidak bergantung satu sama lain, tetapi tetap satu

kesatuan). 

Masing-masing service dirancang hanya memiliki kemampuan tertentu

dan berfokus pada pemecahan suatu masalah atau tujuan bisnis. Setiap

service tidak perlu saling berbagi kode atau implementasi dengan service

yang lain karena komunikasi yang terjadi di antara service dilakukan

melalui API (application programming interface).

Aplikasi yang loosely coupled akan membuat timnya dapat membangun,

mengubah, dan memperbaiki bagiannya secara independen dari tim lain.

Independensi ini penting sebab dapat menghidari tim yang "saling tunggu"

atau membutuhkan "verifikasi" dari tim lain. Perubahan yang dibangun pun

bisa di-deploy sesering mungkin tanpa mengganggu komponen lain yang

dikembangkan oleh tim yg berbeda.

Berbeda dengan aplikasi dengan arsitektur monolitik (sudah kita bahas di

modul pertama), aplikasi yang menggunakan pendekatan microservice,

setiap service atau komponennya di-develop (dikembangkan), di-

test (diuji), dan di-deploy (digelar) secara independen dari service yang

yang lain. Dengan mengimplementasikan microservice, pengembangan,

pembaruan, dan deployment aplikasi bisa menjadi lebih cepat.

Ketika berbicara tentang microservice, ada dua topik hangat yang perlu

kita bahas, yakni container dan serverless.

 Container

Container merupakan suatu cara standar untuk mengemas atau

membungkus kode, konfigurasi, beserta dependencies yang

diperlukan untuk menjalankan aplikasi. Dengan cara ini, aplikasi bisa

menjadi portabel dan dapat berjalan di server mana pun.

Container dapat menyederhanakan cara kita dalam

mengembangkan, menguji, dan men-deploy aplikasi ke berbagai

environment (lingkungan). Namun, supaya lebih mudah untuk

membuat dan mengelola container, kita memerlukan container

 orchestration tools.

Berikut beberapa contoh tools yang bisa digunakan terkait container

orchestration tools (dibagi berdasarkan tools umum dan tools AWS).

Umum AWS

Kubernetes Amazon EKS

OpenShift Amazon ECS
Nomad

 Mari kita bahas sedikit tentang Amazon ECS dan Amazon EKS.
o Amazon ECS (Elastic Container Service) adalah layanan

manajemen container yang bisa kita pakai untuk menjalankan

dan mengelola container pada cluster yang dikelola oleh AWS

dengan mudah.
o Amazon EKS (Elastic Kubernetes Service) merupakan

layanan yang dapat kita gunakan untuk menjalankan

Kubernetes di AWS tanpa perlu menginstal, mengoperasikan,

dan memelihara Kubernetes control plane atau node sendiri.

Bila belum familier, Kubernetes adalah sistem yang open

source untuk

mengotomatiskan management (pengelolaan), scaling (penye

suaian kapasitas), dan deployment (penggelaran) aplikasi

yang menggunakan container.

Kedua opsi layanan di atas bisa Anda pilih sesuai kebutuhan

perusahaan.
 Serverless

Serverless merupakan pendekatan komputasi di mana kita bisa

membangun dan menjalankan kode tanpa perlu memikirkan

infrastruktur dan server yang mendasarinya. Kita hanya perlu fokus

terhadap kode dan serahkan segala urusan infrastruktur ke cloud

provider seperti AWS.

Dalam konteks ini, serverless yang akan kita bahas berkaitan

dengan Function as a Service (FaaS). Dengan kata lain, cloud

provider menyediakan platform agar pelanggan bisa mengeksekusi

kode sebagai response (reaksi) terhadap event (suatu peristiwa)

yang terjadi, tentu saja tanpa perlu memelihara infrastruktur.

Berikut beberapa contoh tools yang bisa digunakan terkait

serverless function as a service (dibagi berdasarkan tools umum dan

tools AWS).

Umum AWS

Serverless
OpenFaaS AWS Lambda
OpenWhisk

 Sekilas mengenai AWS Lambda, ia merupakan layanan komputasi

serverless yang memungkinkan kita untuk menulis kode dan

menjalankannya tanpa perlu membuat dan mengelola server.

Uniknya, kode yang kita tulis hanya akan berjalan saat dirinya

terpanggil (invoked).
 Dalam hal CI/CD pipeline, kita bisa menggunakan Lambda function

untuk berbagai hal, misalnya menyetujui aksi deployment pada

continuous delivery, menghentikan alur rilis, dan lain sebagainya.

Selain terkait Function as a Service, ada juga layanan komputasi

serverless untuk container seperti AWS Fargate. Ia merupakan

mesin komputasi serverless yang kompatibel dengan Amazon ECS

atau Amazon EKS sehingga kita bisa menjalankan container tanpa

perlu mengelola server atau cluster.

Itu dia pembahasan mengenai Arsitektur Microservice. Bila Anda simak

baik-baik, poin pembahasan ini relevan dengan CALMS Framework yang

kita bahas pada modul sebelumnya, yakni tentang Automation.

Monitoring dan Logging

Monitoring (pemantauan) dan logging (pencatatan setiap peristiwa yang

terjadi pada sistem) esensial digunakan untuk menilai seberapa efektif

perubahan pada aplikasi dan infrastruktur, serta mengevaluasi bagaimana

perubahan tersebut memengaruhi kinerja dan pengalaman pengguna

secara keseluruhan.
Monitoring dan logging juga merupakan aspek penting dari DevOps yang

akan membantu kita agar proaktif dalam mencegah suatu masalah

sebelum terjadi. Monitoring dan logging juga dapat membantu tim (baik

Developer maupun IT Operations) dalam bereaksi terhadap suatu

masalah, menjadikannya sebuah pelajaran, merencanakan dan

merancang agar masalah tersebut tidak terulang kembali, dan pada

akhirnya meningkatkan kualitas aplikasi dan pengalaman pengguna.

Ada banyak hal yang bisa kita pantau terhadap sistem kita, terutama yang

berurusan dengan CI/CD, seperti mengetahui frekuensi deployment,

mengidentifikasi keberhasilan atau kesuksesan deployment, traffic (lalu

lintas) pengguna pada aplikasi, dan masih banyak lainnya.  

Oleh karena itu, agar dapat diobservasi, sistem haruslah menghasilkan

data yang cukup dari semua resource (sumber daya), aplikasi, dan service

(layanan) dalam bentuk logs, metrics, dan traces untuk mendapatkan

visibilitas operasional di seluruh sistem.

Sebagai informasi, logs akan melaporkan peristiwa pada sistem, seperti

peringatan; metrics akan menangkap informasi seputar kesehatan dan

kinerja sistem, seperti request rate (seberapa banyak tingkat permintaan

pengguna) atau response time (waktu yang dibutuhkan sistem untuk

respons permintaan pengguna); sedangkan traces akan melaporkan

transaksi dan aliran data di seluruh sistem terdistribusi, seperti sistem

yang menggunakan pendekatan microservice. 

Dengan mengobservasi atau mengamati suatu sistem, kita dapat menarik

kesimpulan singkat tentang mengapa suatu peristiwa (misal, server down)

terjadi. Monitoring akan memberi tahu kita tentang apa yang terjadi

dengan sistem. Jika dipadukan dengan logging, kemudian kita

visualisasikan setiap data yang dikumpulkan oleh sistem dari waktu ke

waktu, kita bisa memperoleh wawasan mengenai kinerja, mengidentifikasi

tren, mengambil keputusan untuk mengatur alarm, serta membuat prediksi

tentang hasil yang diharapkan. 

Berikut adalah beberapa contoh tools yang bisa digunakan terkait

monitoring dan logging (dibagi berdasarkan tools umum dan tools AWS).

Umum AWS

Prometheus AWS X-Ray

Elastic Stack Amazon CloudWatch
Dynatrace

Mari kita bahas sebentar soal AWS X-Ray dan Amazon CloudWatch.

 AWS X-Ray

AWS X-Ray merupakan sistem pelacakan terdistribusi. Layanan ini

membantu kita untuk menganalisis dan men-debug aplikasi

terdistribusi, seperti yang dibangun menggunakan pendekatan

microservice.

AWS X-Ray akan mengumpulkan segala data mengenai request

(permintaan) yang dilayani oleh aplikasi dan menyediakan tools

 yang dapat kita gunakan untuk melihat, memfilter, dan mendapatkan

wawasan tentang data tersebut. Dengan begitu, kita bisa

mengidentifikasi masalah dengan cepat dan langsung melakukan

pengoptimalan sistem.

Bukan hanya akan mendapatkan informasi mendetail soal request

dan response, tetapi juga mengenai komunikasi yang dilakukan oleh

aplikasi Anda ke AWS resource, microservice, database, dan web

API.

 Amazon CloudWatch

Amazon CloudWatch adalah layanan yang bisa digunakan untuk

memantau resource dan aplikasi yang berjalan di AWS secara real

time. Kita bisa manfaatkan Amazon CloudWatch untuk memonitor

dan mengamati kinerja server dan aplikasi, mengumpulkan dan

mengobservasi file log, memecahkan masalah yang berulang kali

terjadi, dan mengatur pemberitahuan bila terjadi suatu peristiwa

yang tak diharapkan.

Oke, itulah tadi pembahasan kita mengenai DevOps tools pada Monitoring

dan Logging yang sekaligus menjadi penutup pada modul Praktik DevOps.

Bila Anda simak baik-baik, poin pembahasan ini relevan dengan CALMS

Framework yang kita bahas pada modul sebelumnya, yakni tentang

Measurement. Ke depannya, masih ada modul yang tak kalah

menariknya. Jadi, stay tuned, ya!