Model Waterfall

Waterfall adalah salah satu dari sekian banyak model proses pengembangan
aplikasi (alias SDLC atau Software Development Life Cycle). Model Waterfall
ini merupakan metode kerja yang menekankan fase-fase yang berurutan dan
sistematis. Disebut waterfall lantaran proses yang terjadi dalam
mengembangkan sebuah perangkat lunak atau aplikasi mengalir satu arah
“ke bawah” bak air terjun.

Gambar di bawah ini adalah contoh sederhana dari penerapan model

Waterfall.

Pada model waterfall, setiap fase saling bergantung satu sama lain. Kita tak
bisa lanjut ke fase berikutnya sebelum fase yang sedang dikerjakan saat ini
benar-benar selesai. Misalnya, kita tak bisa melakukan pengujian (test) jika
proses pengodean (code) dari keseluruhan aplikasi belum beres. Begitu juga
dengan proses deploy, kita tidak bisa men-deploy aplikasi jika keseluruhan
komponen belum lolos fase pengujian (test). Begitu seterusnya.

Bayangkan saja, kita harus menunggu keseluruhan kode aplikasi (fase Code)
selesai terlebih dahulu sebelum akhirnya bisa lanjut ke tahap pengujian (fase
Test). Lantas, bagaimana jika pengujiannya ternyata gagal? Ya harus balik
lagi ke fase Code.

Ketahuilah bahwa proses perpindahan dari satu fase ke fase lainnya pun
memakan waktu yang lama, salah satu penyebabnya adalah tim yang
bertanggung jawab perlu menyesuaikan tools yang mereka gunakan terlebih
dahulu.

Belum lagi jika di tengah-tengah proses pengembangan aplikasi tetiba ada

perubahan kebutuhan, fitur, atau antarmuka; repotlah jadinya karena harus
kembali ke fase awal, yakni penentuan persyaratan/kebutuhan (requirement).

Huft! Harus menunggu berapa lama hingga akhirnya aplikasi bisa dinikmati
pengguna? Tentunya akan melelahkan dan menghabiskan banyak waktu.
Itulah mengapa model waterfall ini terkenal lambat, kaku terhadap
perubahan, dan punya siklus rilis yang panjang.

Mungkin sekarang Anda akan berpikir, “Mana ada sih perusahaan yang pakai
model seperti ini?” Eits, jangan gegabah. Faktanya hingga saat ini model
Waterfall masih banyak loh yang menggunakannya. Ada banyak alasan
mengapa mereka tidak mau–atau mungkin tidak bisa–pindah dari model
Waterfall, salah satunya karena kultur yang sudah mendarah daging
sehingga tampaknya sukar sekali untuk lepas dari cengkeramannya.
Utamanya lagi, dibutuhkan effort yang luar biasa besar untuk mengubah
semua proses yang telah berlangsung lama itu.

Pada akhirnya, hanya inovasi dan persaingan pasarlah yang mampu

mengubah kultur tersebut. Hmm, rasa-rasanya mirip seperti mitos yang
mengatakan bahwa digigit tokek itu hanya bisa dilepas saat ada petir, ya?

Untuk itulah kita belajar DevOps di kelas ini untuk menghapus stigma bahwa
pengembangan aplikasi itu kaku dan lama. Niscaya, setelah memahami
DevOps, Anda serasa dibawa ke dunia yang berbeda.

Arsitektur Monolitik

Tak cukup model Waterfall yang membuat proses pengembangan aplikasi

menjadi hal yang mendongkolkan, masih ada lagi, yakni arsitektur aplikasi
yang monolitik. Apa sih yang dimaksud dengan monolitik itu?
Maksudnya, dikatakan arsitektur monolitik apabila kita menempatkan
berbagai komponen aplikasi di satu unit. Contoh sederhananya adalah ketika
kita men-deploy authentication service (layanan autentikasi), order
service (layanan pemesanan), dan account service (layanan akun) di satu
Back-End server yang sama.
Sebenarnya, arsitektur monolitik bukan berarti buruk sama sekali. Ia menjadi
langkah awal yang bagus bagi Anda yang baru memulai pengembangan
aplikasi agar bisa memahami kompleksitas sistem dan cakupan setiap
komponen lebih baik. Namun, seiring makin rumitnya sistem yang Anda
bangun, makin sulit pula untuk dikelola bila tetap menerapkan pendekatan
monolitik.

Pasalnya, itu berarti semua komponen (seperti authentication service, order

service, account service, dll) saling terikat dan bergantung satu sama lain.
Jika salah satu komponen gagal beroperasi, kemungkinan besar komponen
yang lain akan terkendala.

Oleh karena itu, apabila Anda memiliki aplikasi yang menggunakan

pendekatan monolitik dan dirasa sudah sangat kompleks sehingga sulit untuk
dikelola, sebaiknya modifikasilah arsitekturnya agar menerapkan pendekatan
microservice.

Proses Manual

Selain dua hal yang sudah kita bahas sebelumnya, ihwal lain yang menjadi
problem saat pengembangan aplikasi adalah prosesnya yang masih manual.
Tentu kita tahu apa imbasnya. Proses yang dilakukan secara manual akan
membuat pengembangan aplikasi menjadi lambat, tidak konsisten, dan
rawan kesalahan.
Sebagai contoh, pengaturan dan pengonfigurasian infrastruktur (seperti
server) secara manual merupakan proses yang sangat memakan waktu.
Bagaimana tidak, melakukan proses ini ke beberapa server yang ada terus-
menerus secara manual bisa menguras tenaga dan menghabiskan waktu
hingga berhari-hari. Ditambah lagi, rentan sekali adanya kemungkinan bahwa
satu atau dua langkah terlewat sehingga pada akhirnya timbul kesalahan
konfigurasi.

Contoh lainnya adalah melakukan pengujian secara manual. Coba

bayangkan sejenak, kita harus memberi tahu setiap Developer untuk
memastikan kode mereka diuji atau di-test secara menyeluruh sebelum
mereka boleh melakukan push (dengan kata lain, mengunggahnya)
ke repository (seperti GitHub atau GitLab misalnya).

Kendatipun para Developer melakukannya, proses manual ini akan berjalan

lambat dan tetap ada kemungkinan seseorang lupa melakukan satu atau dua
pengujian. Ujung-ujungnya malah bisa melahirkan kemelut di
lingkungan production dan merepotkan seisi perusahaan.

Struktur Tim Tertutup

Sekarang kita memasuki masalah yang cukup krusial nan utama pada proses
pengembangan aplikasi, yakni tentang manusia. Tentu Anda paham bahwa
makin banyak orang yang bergabung ke dalam suatu proses, makin banyak
pula perspektif dan ide yang bisa kita dapatkan. Akan tetapi, terkadang juga
itu malah menghadirkan masalah lain. Yakinlah, mengubah model, arsitektur,
dan proses akan jauh lebih mudah ketimbang mengurusi manusia.

Begitu juga dalam proses pengembangan aplikasi yang melibatkan banyak

pihak di dalamnya. Umumnya, proses ini melibatkan 2 tim penting, yakni
Developer dan IT Operations. Dua jenis profesi ini acap kali kita sebut sejak
awal modul, memangnya apa sih mereka itu?

Oke, bagi yang belum terlalu familier dengan keduanya, simak uraiannya di
bawah ini.

 Developer: Seseorang atau tim yang mampu merancang (plan),

menulis kode (code), mengemas kode (build), dan menguji (test)
perangkat lunak atau aplikasi.
 IT Operations: Biasa disingkat juga sebagai Operations, adalah
seseorang atau tim yang bertanggung jawab untuk merilis (release)
dan menggelar (deploy) aplikasi, serta mengoperasikan (operate) dan
memantau (monitor) infrastruktur (seperti server) yang menjalankan
aplikasi tersebut.
Developer dan IT Operations adalah dua tim yang krusial karena memiliki
tujuan yang sama, yakni menyajikan aplikasi yang komprehensif dan stabil ke
pengguna; tetapi sering kali mereka tertutup satu sama lain dan seakan-akan
tercerai. Baik Developer maupun IT Operations, mereka memiliki prioritas,
peralatan, dan pola kerjanya sendiri-sendiri sehingga acap kali menimbulkan
pergolakan saat mereka bekerja sama.

Di satu sisi, Developer dituntut oleh perusahaan untuk dapat membuat

perangkat lunak, mengembangkan aplikasi, memperbaiki bug, dan
mengerjakan banyak fitur secepat mungkin. Sering kali yang diukur hanyalah
jumlah fitur yang dikerjakan sehingga justru inilah yang mengakibatkan
mereka tidak memperhatikan kualitas kode.

Di sisi lain, IT Operations dituntut untuk membuat infrastruktur (seperti server,

database, jaringan, dan sejenisnya) yang senantiasa stabil tanpa down. Nah,
masalahnya, salah satu hal yang kerap membuat infrastruktur tidak stabil
adalah perubahan yang terjadi pada aplikasi yang berjalan di dalamnya.
Selain perubahan, intensitas deploy yang tinggi pun akan memperbesar
potensi terjadinya masalah.

Di sinilah letak masalah antara tim Developer dan IT Operations berpusat,

kedua tim tersebut memiliki peran yang berseberangan satu sama lain.

Kebanyakan kasus di beberapa perusahaan, developer tidak mengetahui dan

bahkan tak peduli bagaimana aplikasi yang mereka buat dapat berjalan
dengan baik di lingkungan production. Developer hanya melempar kodenya
ke tim IT Operations dan berharap semuanya berjalan dengan sempurna.

Sementara itu, IT Operations hanya menerima kode dari Developer tanpa

tahu untuk apa kode tersebut. Akhirnya, ketika di-deploy, masalah pun
terjadi.

Tim IT Operations sering kali berasumsi bahwa kualitas kode yang buruk
berasal dari Developer. Yang dituduh tentunya tak akan menelan mentah-
mentah, tim Developer pun akan menyangkal hal tersebut. Pasalnya, selama
di lingkungan Development dan Testing, aplikasi bisa berjalan normal dan
tidak terjadi masalah sama sekali. Developer akan menyalahkan balik IT
Operations karena tidak bisa menjalankan kode aplikasi di production dengan
baik.
Tindakan saling menyalahkan ini tentu saja dapat menimbulkan kekacauan di
internal perusahaan dan membuat proses delivery (penyajian) aplikasi atau
fitur ke pengguna menjadi terhambat dan kelam kabut. Alhasil pengguna pun
kecewa, memberikan feedback buruk, dan perusahaan bisa kehilangan
pasarnya. Lihatlah, hanya karena ini seisi perusahaan menjadi kalut.

Lantas, bagaimana dong cara mengatasi masalah antara Developer dan IT

Operations ini? Bagaimana agar keduanya bisa berkolaborasi dengan baik?
Nah, prakarsa mengenai DevOps pun muncul untuk menjadi solusi dari
problematika ini.

Jangan ke mana-mana, simaklah apa itu DevOps di modul berikutnya.

Pengertian DevOps
Kita sudah tahu nih sekarang apa aja masalah yang biasanya muncul saat
proses pengembangan aplikasi. Salah satu poin yang kita bahas adalah
struktur tim yang tertutup, utamanya antara Developer dan IT Operations.
Lantas, bagaimana dong cara memadamkan api pergolakan di antara
keduanya?

Solusinya adalah memadukan dan mengolaborasikan kedua tim tersebut

(Developer dan IT Operations) dengan sebuah kultur yang baik. Tahukah
Anda? Fakta menariknya, istilah DevOps merupakan gabungan kata dari
Developer (atau Development) dan IT Operations (atau Operations).
Catatan: Jika ingin memahami setiap fase yang tertera pada gambar, silakan
baca selengkapnya di halaman berikut.

Jadi, jika Anda berpikiran bahwa DevOps itu adalah sebuah posisi pekerjaan
atau sebatas aktivitas yang hanya bergelut dengan Docker, Jenkins, dan
Kubernetes, sepertinya Anda keliru. Mari kita luruskan.

DevOps adalah kombinasi dari filosofi kultur/budaya, sekumpulan praktik,

dan rangkaian alat (tools) yang dapat meningkatkan kemampuan
organisasi/perusahaan untuk menyajikan (deliver) aplikasi atau perangkat
lunak secara cepat [1].

Itu artinya, perusahaan mampu mengembangkan dan memperbaiki produk

mereka dengan lebih cepat ketimbang menggunakan model pengembangan
aplikasi dan proses manajemen infrastruktur yang tradisional, seperti model
Waterfall yang kita bahas sebelumnya. Dengan prosedur yang cepat,
memungkinkan perusahaan untuk melayani pengguna dengan lebih baik dan
mampu bersaing secara lebih efektif di pasar.

Seperti yang sudah dijelaskan, DevOps merupakan kombinasi dari filosofi

kultur, praktik, dan tools. Jika Anda bingung dengan ketiga istilah tersebut,
berikut adalah uraiannya.
  Filosofi kultur atau budaya yang dimaksud adalah dengan
menghilangkan segala hambatan yang terjadi pada proses
pengembangan aplikasi dan menerapkan berbagi tanggung jawab yang
sesuai ke masing-masing tim.
 Praktik di sini bertujuan untuk mencapai kecepatan dan kualitas proses
pengembangan aplikasi, yakni dengan merampingkan prosedur terkait
bagaimana cara tim bekerja.
 Tools yang dimaksud adalah dengan memanfaatkan peralatan atau
perangkat lunak yang selaras dengan proses pengembangan aplikasi
dan mengotomatiskan tugas-tugas yang berulang agar tidak dilakukan
secara manual. Dengan demikian, hal itu dapat membuat proses rilis
menjadi lebih efisien dan aplikasi menjadi lebih andal.

Intinya, DevOps menekankan kolaborasi dan efisiensi yang elok sehingga tim
dan perusahaan bisa berinovasi lebih cepat. Dengan begitu, pengguna pun
akan berkenan memberikan feedback yang berkualitas sehingga berujung
pada peningkatan nilai bisnis perusahaan.

Dengan mengimplementasikan DevOps, tim yang sebelumnya saling tertutup

dan terpisah (yakni Developer dan IT Operations) pada akhirnya mampu
bersatu, berkolaborasi, dan berkomunikasi untuk mengoptimalkan
produktivitas. Ucapkan selamat tinggal pada kekisruhan yang terjadi pada
internal perusahaan dan mari ciptakan suasana yang lebih damai.
Nah, itulah materi tentang pengertian DevOps. Semoga dengan pembahasan
ini, Anda bisa makin paham dengan terminologi DevOps. Selanjutnya, kita
perlu mengerti manfaat-manfaat apa saja yang akan didapat bila
menerapkan DevOps. Tentunya ada banyak, ya. Apa sajakah itu? Yuk, kita
cari tahu jawabannya di materi berikutnya!

Manfaat Penerapan DevOps

Perangkat lunak dan internet telah mentransformasi dunia beserta industri di
dalamnya, mulai dari belanja online, hiburan, hingga perbankan. Perangkat
lunak tidak sebatas hanya mendukung bisnis; melainkan menjadi komponen
yang berkelindan dengan setiap bagian aspek bisnis.

Kini sebagian besar perusahaan berinteraksi dengan pengguna melalui

perangkat lunak yang mereka sediakan sebagai layanan atau aplikasi online.
Perusahaan juga menggunakan perangkat lunak untuk meningkatkan
efisiensi operasional dengan mengubah setiap bagian dari rantai bisnis
mereka, seperti logistik, komunikasi, dan pemasaran.

Oleh karena itu, serupa seperti industri manufaktur yang mengubah cara
produksi mereka yang memanfaatkan automasi, semua perusahaan di dunia
saat ini pun semestinya mengubah cara mereka dalam membangun dan
menyajikan perangkat lunak ke pengguna.
Anda beruntung belajar di kelas ini karena kita akan belajar bagaimana cara
mengimplementasikan DevOps di perusahaan tempat Anda bekerja.

Namun, sebelum kita tahu cara-caranya, pertanyaan terakbar yang sering

terlontar saat belajar tentang DevOps–selain pengertiannya–adalah sebagai
berikut.

 Apa saja manfaat dari menerapkan DevOps?

 Mengapa kita perlu menerapkan DevOps?
 Apakah benar dengan menerapkan DevOps akan membuat proses
pengembangan aplikasi menjadi lebih baik?

Masih banyak pertanyaan-pertanyaan serupa lainnya, tetapi intinya merujuk

pada satu hal, yakni manfaat penerapan DevOps.

Apa pun ukuran dari perusahaan Anda, entah itu startup, medioker, hingga
korporasi sekalipun akan memperoleh manfaat bila mengadopsi DevOps.
Berikut ini adalah beberapa manfaat utama DevOps.

 Ketangkasan
Menerapkan DevOps dapat membuat perusahaan Anda unggul secara
kompetitif karena sanggup mengantisipasi kebutuhan pasar,
menciptakan inovasi dengan cepat, dan merengkuh pertumbuhan
bisnis yang lebih efisien.

Sebagai contoh, microservice dan continuous delivery (nanti kita

pelajari keduanya) memungkinkan tim untuk memiliki kepemilikan
terhadap komponen aplikasi sehingga memudahkan mereka untuk
merilis pembaruan lebih cepat dan tangkas.

 Proses rilis cepat

DevOps mampu meningkatkan frekuensi rilis aplikasi, fitur, atau
perangkat lunak sehingga Anda dapat berinovasi dan meningkatkan
kualitas produk dengan lebih cepat.

Makin cepat Anda merilis fitur baru atau memperbaiki bug, makin cepat
pula Anda bisa menanggapi kebutuhan pengguna. Continuous
integration dan continuous delivery/deployment (kita pelajari nanti)
merupakan praktik yang dapat mengotomatiskan proses rilis perangkat
lunak, dari mulai dari proses build hingga deployment.
 Keandalan
Saat melakukan pembaruan pada aplikasi atau perubahan terhadap
infrastruktur, pastikan kualitasnya tetap terjaga agar Anda dapat
menyajikan aplikasi yang ciamik, lebih cepat, dan andal sehingga
pengguna tetap mendapatkan pengalaman yang positif.

Dengan DevOps, Anda bisa menggunakan praktik

semacam continuous integration dan continuous
delivery/deployment (nanti kita pelajari ya) guna menguji bahwa setiap
perubahan dapat berfungsi dengan baik. Selain itu, praktik
seperti monitoring dan observability (nanti kita pelajari) juga mampu
membantu Anda agar tetap mendapatkan informasi mengenai kinerja
aplikasi secara real time.

 Skalabilitas
Hadirnya DevOps memungkinkan Anda untuk mengelola dan
mengoperasikan infrastruktur beserta proses pengembangan aplikasi
dalam skala besar. Automasi dan konsistensi dapat mempermudah
Anda dalam mengelola sistem yang kompleks secara efisien dengan
risiko yang lebih rendah.

Misalnya, Infrastructure as Code (nanti akan kita pelajari) dapat

membantu Anda mengelola lingkungan Development, Testing, dan
Production dengan cara yang andal dan lebih efisien.

 Kolaborasi meningkat
Anda bisa membangun tim yang lebih efektif dengan menerapkan
kultur DevOps, yang menekankan nilai-nilai seperti kepemilikan dan
akuntabilitas. Developer dan IT Operations akan berkolaborasi dengan
erat, berbagi banyak tanggung jawab, dan memadukan alur kerja
mereka. Dengan ini, pada akhirnya akan mengurangi inefisiensi
sekaligus menghemat waktu.

Misalnya, Developer hanya perlu fokus menulis kode tanpa perlu

memusingkan di lingkungan mana kode itu akan dijalankan. Ditambah,
tak ada lagi proses serah terima kode dari Developer ke IT Operations
secara manual. Musabab semuanya akan berjalan secara otomatis
adalah berkat kolaborasi alur kerja yang telah Developer dan IT
Operations buat sebelumnya.

 Keamanan
Jika menerapkan DevOps, bisnis Anda bisa bergerak lebih cepat
 sambil mempertahankan akses kontrol dan menjaga compliance. Anda
bisa kok mengadopsi DevOps tanpa mengorbankan keamanan, yakni
dengan menggunakan compliance policies (kebijakan compliance)
secara otomatis, kontrol akses yang mendetail, dan teknik manajemen
konfigurasi.

Misalnya, menggunakan Infrastructure as Code dan Policy as

Code (kita akan pelajari nanti) memungkinkan Anda untuk menentukan
dan melacak keamanan serta compliance dalam skala besar.
Itu dia manfaat-manfaat yang kelak Anda dapatkan bila menerapkan
DevOps. Harapannya, dengan mengetahui ini, Anda akan makin teguh dan
yakin untuk menerapkan DevOps di perusahaan.

Rangkuman Pengenalan DevOps

Masalah pada Proses Pengembangan Aplikasi

Kita semua tahu bahwa proses pengembangan aplikasi itu ruwet, bahkan di
beberapa kasus bisa jadi melibatkan banyak sekali pihak. Tidak hanya dari
segi model, ada juga beberapa masalah lain yang menghantui selama proses
pengembangan aplikasi, seperti arsitektur yang monolitik, proses yang
manual, dan struktur tim yang tertutup pun bisa menjadi bottleneck sehingga
menyebabkan keterlambatan dan ketidakefisienan dalam proses penyajian
aplikasi.

Oke, supaya lebih detail dalam memahami masalah-masalah ini, mending

langsung saja kita bedah satu per satu yuk.
Model Waterfall
Waterfall adalah salah satu dari sekian banyak model pada proses
pengembangan aplikasi (alias SDLC atau Software Development Life Cycle).
Model Waterfall ini merupakan metode kerja yang menekankan fase-fase
yang berurutan dan sistematis. Disebut waterfall lantaran proses yang terjadi
dalam mengembangkan sebuah perangkat lunak atau aplikasi mengalir satu
arah “ke bawah” bak air terjun.

Pada model waterfall, setiap fase saling bergantung satu sama lain. Kita tak
bisa lanjut ke fase berikutnya sebelum fase yang sedang dikerjakan saat ini
benar-benar selesai digarap. Misalnya, kita tak bisa melakukan pengujian jika
proses coding dari keseluruhan aplikasi belum beres. Begitu juga kita tak
bisa men-deploy aplikasi jika keseluruhan komponen aplikasi belum lolos
fase pengujian. Begitu seterusnya.

Ketahuilah bahwa proses perpindahan dari satu fase ke fase lainnya pun
memakan waktu yang lama, salah satu penyebabnya adalah tim yang
bertanggung jawab perlu menyesuaikan tools yang mereka gunakan terlebih
dahulu.

Belum lagi jika di tengah-tengah proses pengembangan aplikasi tetiba ada

perubahan kebutuhan, fitur, atau antarmuka; repotlah jadinya karena harus
kembali ke fase awal, yakni penentuan persyaratan/kebutuhan (requirement).

Arsitektur Monolitik
Apa sih yang dimaksud dengan monolitik itu? Maksudnya, dikatakan
arsitektur monolitik apabila kita menempatkan berbagai komponen aplikasi di
satu unit. Contoh sederhananya adalah ketika kita men-deploy authentication
service (layanan autentikasi), order service (layanan pemesanan), account
service (layanan akun), dll di satu Back-End server yang sama.

Sebenarnya, arsitektur monolitik bukan berarti buruk sama sekali. Ia menjadi

langkah awal yang bagus bagi Anda yang baru memulai pengembangan
aplikasi agar bisa memahami kompleksitas sistem dan cakupan setiap
komponen lebih baik. Namun, seiring makin rumitnya sistem yang Anda
bangun, makin sulit pula untuk dikelola bila tetap menerapkan pendekatan
monolitik.

Pasalnya, itu berarti semua komponen (seperti authentication service, order

service, account service, dll) saling terikat dan bergantung satu sama lain.
Jika salah satu komponen gagal beroperasi, kemungkinan besar komponen
yang lain akan terkendala.

Oleh karena itu, apabila Anda memiliki aplikasi yang menggunakan

pendekatan monolitik dan dirasa sudah sangat kompleks sehingga sulit untuk
dikelola, sebaiknya modifikasilah arsitekturnya agar menerapkan pendekatan
microservice.

Proses Manual
Proses yang manual membuat pengembangan aplikasi menjadi lambat, tidak
konsisten, dan rawan kesalahan.

Sebagai contoh, pengaturan dan pengonfigurasian infrastruktur (seperti

server) secara manual merupakan proses yang sangat memakan waktu.
Bagaimana tidak, melakukan proses ini ke beberapa server yang ada terus-
menerus secara manual bisa menguras tenaga dan menghabiskan waktu
hingga berhari-hari. Ditambah lagi, rentan sekali adanya kemungkinan bahwa
satu atau dua langkah terlewat sehingga pada akhirnya timbul kesalahan
konfigurasi.

Struktur Tim Tertutup

Proses pengembangan aplikasi melibatkan 2 tim penting, yakni Developer
dan IT Operations. Mereka adalah dua tim yang krusial karena memiliki
tujuan yang sama, yakni menyajikan aplikasi yang komprehensif dan stabil ke
pengguna; tetapi sering kali mereka tertutup satu sama lain dan seakan-akan
tercerai. Baik Developer maupun IT Operations, mereka memiliki prioritas,
peralatan, dan pola kerjanya sendiri-sendiri sehingga acap kali menimbulkan
pergolakan saat mereka tengah bekerja sama.

Di satu sisi, Developer dituntut oleh perusahaan untuk dapat membuat

perangkat lunak, mengembangkan aplikasi, memperbaiki bug, dan
mengerjakan banyak fitur secepat mungkin. Sering kali yang diukur hanyalah
jumlah fitur yang dikerjakan sehingga justru inilah yang mengakibatkan
mereka tidak memperhatikan kualitas kode.

Di sisi lain, IT Operations dituntut untuk membuat infrastruktur (seperti server,

database, jaringan, dan sejenisnya) yang senantiasa stabil tanpa down. Nah,
masalahnya, salah satu hal yang kerap membuat infrastruktur tidak stabil
adalah perubahan yang terjadi pada aplikasi yang berjalan di dalamnya.
Selain perubahan, intensitas deploy yang tinggi pun akan memperbesar
potensi terjadinya masalah.

Di sinilah letak masalah antara tim Developer dan IT Operations berpusat,

kedua tim tersebut memiliki peran yang berseberangan satu sama lain.

Lantas, bagaimana dong cara mengatasi masalah antara Developer dan IT

Operations ini? Bagaimana agar keduanya bisa berkolaborasi dengan baik?
Nah, prakarsa mengenai DevOps pun muncul untuk menjadi solusi dari
problematika ini.

Pengertian DevOps

DevOps adalah kombinasi dari filosofi kultur/budaya, sekumpulan praktik,

dan rangkaian alat (tools) yang dapat meningkatkan kemampuan
organisasi/perusahaan untuk menyajikan (deliver) aplikasi atau perangkat
lunak secara cepat.

Itu artinya, perusahaan mampu mengembangkan dan memperbaiki produk

mereka dengan lebih cepat ketimbang menggunakan model pengembangan
aplikasi dan proses manajemen infrastruktur yang tradisional, seperti model
Waterfall yang kita bahas sebelumnya. Dengan prosedur yang cepat,
memungkinkan perusahaan untuk melayani pengguna dengan lebih baik dan
mampu bersaing secara lebih efektif di pasar.

Dengan mengimplementasikan DevOps, tim yang sebelumnya saling tertutup

dan terpisah (yakni Developer dan IT Operations) pada akhirnya mampu
bersatu, berkolaborasi, dan berkomunikasi untuk mengoptimalkan
produktivitas. Ucapkan selamat tinggal pada kekisruhan yang terjadi pada
internal perusahaan dan mari ciptakan suasana yang lebih damai.

Manfaat Penerapan DevOps

Apa pun ukuran dari perusahaan Anda, entah itu startup, medioker, hingga
korporasi sekalipun akan memperolehhadirnyabila mengadopsi DevOps.
Berikut ini adalah beberapa manfaat utama DevOps.

 Ketangkasan
Menerapkan DevOps dapat membuat perusahaan Anda unggul secara
kompetitif karena sanggup mengantisipasi kebutuhan pasar,
menciptakan inovasi dengan cepat, serta merengkuh pertumbuhan
bisnis yang lebih efisien.
 Proses rilis cepat
DevOps mampu meningkatkan frekuensi rilis aplikasi, fitur, atau
perangkat lunak sehingga Anda dapat berinovasi dan meningkatkan
kualitas produk dengan lebih cepat.
 Keandalan
Saat melakukan pembaruan pada aplikasi atau perubahan terhadap
infrastruktur, pastikan kualitasnya tetap terjaga agar Anda dapat
menyajikan aplikasi yang ciamik lebih cepat dan andal sehingga
pengguna tetap mendapatkan pengalaman yang positif.
 Skalabilitas
Hadirnya DevOps memungkinkan Anda untuk mengelola dan
mengoperasikan infrastruktur beserta proses pengembangan aplikasi
dalam skala besar. Automasi dan konsistensi dapat mempermudah
Anda dalam mengelola sistem yang kompleks secara efisien dengan
risiko yang lebih rendah.
 Kolaborasi meningkat
Anda bisa membangun tim yang lebih efektif dengan menerapkan
kultur DevOps, yang menekankan nilai-nilai seperti kepemilikan dan
akuntabilitas. Developer dan IT Operations akan berkolaborasi dengan
erat, berbagi banyak tanggung jawab, dan memadukan alur kerja
mereka. Dengan ini pada akhirnya akan mengurangi inefisiensi
sekaligus menghemat waktu.
 Keamanan
Jika menerapkan DevOps, bisnis Anda bisa bergerak lebih cepat
sambil mempertahankan akses kontrol dan menjaga compliance. Anda
bisa mengadopsi DevOps tanpa mengorbankan keamanan, yakni
menggunakan compliance policies (kebijakan compliance) secara
otomatis, kontrol akses yang mendetail, dan teknik manajemen
konfigurasi.
Pengantar The Three Ways: Prinsip-Prinsip yang Mendasari DevOps
Setelah mengetahui pengertian DevOps, sekarang mari kita telaah lebih
dalam dengan memahami prinsip-prinsip yang ada pada DevOps.

Prinsip di balik pola kerja DevOps sejatinya mirip seperti yang diterapkan
pada saat mentransformasi dunia manufaktur. Pada tahun 1980-an, terdapat
konflik dalam bidang manufaktur yang saat itu begitu terkenal, yaitu
melindungi komitmen penjualan dan mengontrol biaya produksi.

Sebagai upaya untuk melindungi komitmen penjualan, sales

manager (manajer penjualan) menginginkan banyak persediaan barang di
gudang agar pelanggan selalu memperoleh produk yang mereka inginkan
(tidak kehabisan stok). Namun sebaliknya, untuk mengontrol (mengurangi)
biaya produksi, plant manager (manajer pabrik) justru ingin mengurangi
tingkat persediaan barang di gudang dan memangkas jumlah produk dalam
proses produksi (work in process alias WIP). Sebab, sales manager dan
plant manager tak mungkin meningkatkan dan menurunkan tingkat
persediaan barang secara bersamaan, keduanya pun terjebak dalam konflik
yang berkelanjutan.

Waktu berselang, banyak proses yang berubah menjadi lebih baik. Mereka
bekerja sama dan akhirnya mampu memecahkan konflik ini dengan
memperbaiki beberapa proses produksi, seperti mengurangi jumlah unit yang
diproduksi, mengurangi work in process, serta memperkuat umpan balik dari
pelanggan. Alhasil, beberapa perbaikan tersebut meningkatkan produktivitas
pabrik, kualitas produk, dan kepuasan pelanggan secara drastis.

Pada 1980-an, rata-rata order lead times adalah 6 minggu, dengan kurang
dari 70% pesanan dikirim secara tepat waktu. Namun, pada tahun 2005, rata-
rata order lead times menurun menjadi kurang dari 3 minggu, dengan lebih
dari 95% pesanan dikirim tepat waktu. Sebuah peningkatan yang signifikan,
bukan? Kala itu, perusahaan mana pun yang tak mampu meniru terobosan
kinerja seperti ini akan kehilangan pangsa pasar atau bahkan bisnisnya
gulung tikar.

Catatan: Order lead times adalah waktu yang diperlukan untuk beralih dari
“pesanan diterima oleh staf manajemen pabrik” menjadi “pesanan dikirim ke
pelanggan”.

Hal serupa pun berlaku pada DevOps. Alih-alih mengoptimalkan bagaimana

bahan mentah diubah menjadi barang jadi di pabrik manufaktur, DevOps
menunjukkan bagaimana suatu perusahaan dapat memaksimalkan
pemanfaatan IT, dengan cara mentransformasi kebutuhan bisnis menjadi
kemampuan dan layanan IT yang dapat memberikan nilai dan kegunaan bagi
pengguna.

Apabila dalam bidang manufaktur dikenal istilah order lead times, di dunia
DevOps terdapat istilah code deployment lead times, yakni waktu yang
diperlukan untuk beralih dari “perubahan atau penambahan kode yang di-
commit atau diunggah ke dalam version control system (seperti Git) oleh tim
Developer” menjadi “kode berjalan dengan baik di lingkungan production”.
Jangan khawatir, di modul yang akan datang, kita akan bahas tuntas tentang
alur code deployment ini melalui DevOps Pipeline. Untuk saat ini, mari fokus
ke prinsip-prinsip DevOps terlebih dahulu.

DevOps juga menggunakan prinsip-prinsip yang mirip seperti yang

diterapkan pada bidang manufaktur, yakni dengan merampingkan alur kerja,
menciptakan alur umpan balik dari pelanggan, serta terus belajar dan
bereksperimen demi menciptakan proses produksi (dalam hal ini
penambahan fitur dan peningkatan kualitas aplikasi) yang semakin baik.

DevOps mampu membawa perubahan yang signifikan pada dunia IT.

Bagaimana tidak? Keunggulan kompetitif yang diciptakan oleh DevOps
sangatlah besar. Ia mampu mempercepat waktu untuk merilis fitur,
menaikkan kepuasan pelanggan, memperluas pangsa pasar, meningkatkan
produktivitas dan kebahagiaan pegawai, serta memungkinkan perusahaan
untuk menang di pasaran.

Mengapa demikian? Sebabnya karena teknologi telah menjadi proses

penciptaan nilai yang dominan dan sarana akuisisi pelanggan yang semakin
penting (sering kali menjadi yang utama) di sebagian besar perusahaan.

Dahulu, perusahaan hanya mampu melakukan deployment (entah itu

penambahan fitur, perubahan kode, peningkatan kualitas aplikasi, dsb) dalam
beberapa minggu hingga bulan saja. Namun, bagaimana untuk sekarang?
Frekuensi seperti itu akan dibilang ketinggalan zaman oleh perusahaan lain.

Dengan hadirnya DevOps, perusahaan mampu melangkah di luar batas yang

mereka pikirkan. Bayangkan, pada tahun 2009, frekuensi deploy sebanyak
10x per hari sudah dianggap banyak. Akan tetapi, pada tahun 2012, Amazon
mencatat bahwa mereka melakukan deploy (rata-rata) sebanyak 23.000x per
hari. Sebuah peningkatan yang signifikan, bukan?

Pertanyaannya, bagaimana caranya agar DevOps yang kita terapkan di

perusahaan bisa sehebat itu?

Ketahuilah, sebelum bisa mengimplementasikan DevOps dengan baik, ada

prinsip-prinsip DevOps yang perlu diketahui supaya kelak Anda bisa
membawa perusahaan ke level yang lebih tinggi dari saat ini.

Terdapat 3 prinsip utama yang akan kita pelajari [2]:

 Prinsip terkait alur kerja yang mampu mengakselerasi penyelesaian

dan/atau penyerahan pekerjaan dari Developer, ke IT Operations,
hingga ke pengguna aplikasi.
 Prinsip terkait umpan balik yang memungkinkan perusahaan untuk
menciptakan sistem kerja yang lebih aman dan lebih baik.
 Prinsip terkait proses belajar dan eksperimen yang
berkelanjutan akan menciptakan kultur yang menumbuhkan dua hal,
seperti

o pemahaman bahwa pengulangan dan latihan merupakan syarat

untuk menguasai sesuatu; serta
o kesadaran betapa pentingnya eksperimen yang terus-menerus
guna meningkatkan keterampilan pengambilan risiko dan sebagai
proses belajar, baik dari keberhasilan maupun kegagalan.
Poin-poin di atas disebut dengan The Three Ways, yakni prinsip-prinsip yang
mendasari DevOps. Prinsip-prinsip ini menggambarkan nilai dan filosofi yang
dapat memandu Anda dalam mengimplementasikan dan mempraktikkan
DevOps di perusahaan Anda. Apabila prinsip-prinsip ini tidak diterapkan atau
tidak ada dalam proses pengembangan aplikasi Anda, sebenarnya Anda
belum sepenuhnya mengimplementasikan DevOps.
The Second Way: Prinsip terkait Umpan Balik
Jika The First Way menjelaskan tentang prinsip yang memungkinkan alur
kerja yang lancar dan cepat dari kiri ke kanan (Development ke Operations),
The Second Way ini mendeskripsikan prinsip yang memungkinkan feedback
(umpan balik) yang cepat nan konstan dari kanan ke kiri (Operations ke
Development).

Pada prinsip ini, fokus utamanya adalah untuk meningkatkan jumlah

feedback dan mempercepat proses penyampaian feedback dari Operations
ke Development (atau bisa juga dari pengguna ke tim terkait) guna
mencegah agar masalah tak terulang kembali, memungkinkan deteksi
masalah lebih dini, serta pemulihan infrastruktur lebih cepat.

Sebagai contoh, tim Developer telah menulis kode aplikasi dan kemudian
menyerahkannya ke tim IT Operations untuk di-deploy. Akan tetapi, saat
dilakukan pengujian pada lingkungan Test, performa dari kode aplikasi
tersebut kurang begitu bagus sehingga menyebabkan aplikasi tidak optimal.
Setelah itu, tim IT Operations memberikan feedback kepada Developer agar
kodenya diperbaiki supaya ke depannya bisa berjalan lebih baik. Dengan
begitu, tim Developer bisa melakukan perbaikan sesegera mungkin dan
akhirnya kualitas aplikasi makin meningkat.

Prinsip ini sangat penting untuk kita pahami agar tercipta sistem kerja yang
lebih aman sebab masalah dapat ditemukan sedini mungkin dan diperbaiki
lebih cepat sehingga kita terhindar dari kegagalan saat aplikasi sudah di-
deploy ke production a.k.a dirilis ke publik.

Menciptakan sistem kerja yang aman menjadi hal yang sangat penting dalam
proses pengembangan aplikasi, terutama bila kita bekerja dengan sistem
aplikasi yang kompleks. Pasalnya, kita harus bisa dan mampu mendeteksi
masalah (atau potensi masalah) sedini mungkin dan segera menyampaikan
feedback agar dapat langsung diperbaiki. Jika tidak, maka masalah akan
semakin melebar dan akhirnya melumpuhkan seluruh sistem.

Apabila sistem aplikasi yang kompleks ini ternyata down (lumpuh)

sepenuhnya, niscaya kita akan kesulitan dalam menghidupkannya kembali
karena diperlukan sejibun prosedur, menghabiskan waktu, dan memakan
biaya. Untuk itulah mengapa prinsip terkait umpan balik ini krusial untuk
diterapkan.

Namun, pertanyaannya adalah bagaimana cara agar prinsip terkait umpan

balik ini dapat diterapkan dengan baik? Tentu saja ada beberapa aspek
penting yang wajib kita pahami. Mari kita telaah satu per satu.

Swarming dalam Menyelesaikan Masalah

Ketika kita mengembangkan atau memelihara aplikasi, feedback (umpan

balik) akan datang kapan saja, entah itu berupa laporan masalah dari
pengguna ataupun hasil temuan oleh tim internal. Namun, kali ini mari kita
fokuskan terhadap feedback dari pengguna.

Sebelum DevOps hadir, banyak perusahaan IT yang mengelola insiden atau

masalah melalui mekanisme “three-tier support hierarchy”, di mana suatu
insiden haruslah diproses melalui 3 tingkatan, antara lain:

1. Level 1: Frontline Service Desk, yang bertugas untuk menangani

komunikasi yang masuk dari pengguna secara langsung, biasanya
dengan menjawab panggilan telepon, chat, dll.
Umumnya, Frontline Service Desk dipersiapkan untuk memberikan
dukungan teknis umum pada tingkat menengah saja, dengan tujuan
menghadirkan dukungan yang konsisten kepada pengguna, seraya
menyelesaikan sejumlah besar masalah yang masuk di lini pertama.
2. Level 2: Dukungan tingkat kedua, biasanya berkaitan dengan Service
Desk, tetapi dengan keterampilan atau spesialisasi yang lebih dalam.
Agen dukungan pada Level 2 ini umumnya memiliki pelatihan
tambahan untuk mendukung sistem operasi (seperti Microsoft
Windows) atau perangkat keras secara umum. Karenanya, mereka
dapat menyelesaikan masalah yang lebih kompleks.
 3. Level 3: Tim dukungan spesialis yang berfokus pada teknologi dan
aplikasi tertentu.
Untuk perusahaan yang mengembangkan perangkat lunak secara
internal, biasanya terdapat tim dukungan Level 3 khusus yang
ditugaskan untuk setiap aplikasi atau layanan.
Melalui mekanisme seperti ini, pengguna hanya akan berhadapan dengan
dukungan Level 1 (Level 1 Support). Semua masalah pengguna akan
berawal dan mungkin berakhir di level ini. Akan tetapi, bila ada masalah yang
terlalu kompleks untuk diselesaikan pada Level 1 Support, maka masalah
tersebut akan dieskalasi ke Level 2 Support dan/atau Level 3 Specialist.
Ketahuilah bahwa sistem seperti ini memiliki banyak kekurangan, terutama
dari sisi DevOps. Salah satunya masalah utamanya adalah ia dapat
membuat banyak antrean.

Seperti yang kita bahas sebelumnya, semua masalah yang tak bisa ditangani
oleh Level 1 Support akan dieskalasi ke Level 2 Support dan/atau Level 3
Specialist. Tak ayal mekanisme seperti ini sering kali menyebabkan banyak
antrean. Sebab masalah yang ditangani oleh Level 2 dan Level 3 lebih
kompleks ketimbang di Level 1, maka proses penyelesaian masalahnya pun
membutuhkan waktu yang lama dan berujung antrean yang kian menumpuk
untuk diselesaikan.

Parahnya lagi, terkadang ditemukan suatu insiden/masalah yang “bouncing”

alias memantul antarlevel. Maksudnya begini. Dalam sistem “three-tier
support hierarchy”, cara melakukan eskalasi ke tim lain adalah dengan
mengubah tim yang ditugaskan padanya. Langkah ini biasanya dilakukan
secara sepihak oleh tim pemberi tugas kepada tim penerima tugas.

Sayangnya, sangat umum untuk melihat suatu insiden/masalah memantul

kembali, misal dari Level 2 dikembalikan ke Level 1. Ini bisa disebabkan oleh
berbagai faktor, entah itu karena Level 2 memerlukan informasi yang lebih
detail atau karena mereka merasa itu bukan tugas mereka.
Perlu Anda pahami bahwa DevOps pada dasarnya dibangun berdasarkan
kolaborasi antara Developer dan IT Operations. Itu berarti, sudah jelas
bahwa mekanisme “three-tier support hierarchy” merupakan antitesis dari
prinsip DevOps.

Oleh karena itu, muncul sebuah terobosan baru dalam dunia pengelolaan
insiden/masalah bernama “swarming”. Model ini secara eksplisit menolak
mekanisme “three-tier support hierarchy” yang berbasis eskalasi dan lebih
mendukung proses berbasis kolaborasi.

Beberapa prinsip intinya antara lain:

 Tidak boleh ada tim dukungan yang bertingkat.

 Tidak boleh ada eskalasi dari satu tim ke tim lain.
 Suatu insiden atau masalah harus diserahkan langsung ke orang yang
paling mungkin dapat menyelesaikannya.
 Orang yang menangani masalah harus mengawasinya sampai
masalah tersebut selesai.

Swarming menawarkan mekanisme yang lebih baik, yaitu dengan

mengeliminasi antrean dan handoff yang ada untuk setiap insiden/masalah
dengan membawa responden ahli (misal, dari Developer atau IT Operations)
langsung ke inti masalah. Model swarming ini berfokus untuk mengurangi
waktu yang dibutuhkan untuk penyelesaian masalah sekaligus berbagi
pengetahuan di antara tim terkait mengenai insiden yang terjadi dengan
cepat.

Model ini didasarkan pada kolaborasi berjejaring di seluruh tim teknis (misal,
perpaduan dari Developer dan IT Operations) daripada pendekatan eskalasi
bertingkat pada model “three-tier support hierarchy”. Sebagian besar
perusahaan membentuk tim “swarm” dengan jumlah anggota yang sedikit
berdasarkan bidang keahlian dan reputasi individu yang berfokus pada
penyelesaian insiden/masalah yang masuk dari pengguna secara cepat.
Umumnya terdapat beberapa kategori berikut:

 Severity 1 Swarm: Terdiri dari 3 orang yang ahli pada bidang atau
topik tertentu pada aplikasi perusahaan (SME atau Subject Matter
Expert) dari berbagai tim (umumnya dari Developer dan IT Operations)
dan akan dirotasi setiap minggunya. Tujuan dari tim ini adalah untuk
menangani masalah dengan tingkat keparahan tertinggi secepat
mungkin. Sehingga, biasanya dari 100% jumlah insiden/masalah yang
masuk, tim ini hanya mengerjakan 1% yang memang benar-benar
masuk dalam kategori kritis. Sisanya, akan dikerjakan oleh Local
Dispatch

 Local Dispatch Swarm: Tim ini didedikasikan untuk menerima

sebagian besar insiden/masalah yang masuk dari pengguna (sekitar
99% masalah akan masuk ke tim ini). Mereka bertemu tiap hari setiap
60–90 menit untuk memilih insiden/masalah yang dapat mereka
selesaikan dengan cepat (biasanya sekitar 30% akan selesai di sini)
dan meneruskan insiden/masalah yang tidak dapat mereka pecahkan
 (sekitar 70% sisanya) ke Product Line support team.

 Backlog Swarm: Tim ini akan bertemu setiap hari untuk

menyelesaikan insiden/masalah yang diberikan oleh Product Line
support team. Tim ini berisi orang-orang teknis yang terampil dan
berpengalaman dari berbagai departemen (baik dari Developer
maupun IT Operations), dengan fokus pada kasus-kasus sulit yang tak
bisa diselesaikan oleh Product Line support team.

Nah, dengan cara ini, feedback (misal, berupa laporan masalah) dari
pengguna bisa langsung diterima oleh tim yang tepat dan segera diatasi
dalam waktu singkat.
Bagaimana, kini sudah paham kan dengan model swarming? Model ini
dibangun di atas banyak prinsip yang sama yang mendukung keberhasilan
DevOps, seperti:

 Kolaborasi lintas fungsi yang dinamis dengan menyatukan berbagai

keterampilan ke dalam suatu tim gabungan.
 Organisasi tim yang fleksibel, bukan struktur hierarkis yang kaku.
 Otonomi individu, bukan proses dogmatis.
 Fokus pada penghindaran penumpukan WIP.
 Antarinvididu dapat saling berbagi pengetahuan ke tim lain pada saat
proses penyelesaian masalah.

Dengan begitu, model ini sangat cocok untuk diterapkan apabila Anda ingin
menerapkan DevOps. Selain poin-poin di atas, model swarming juga mampu
mendukung alur feedback yang lebih baik dari sisi internal. Karena absennya
model hierarki dan digantikan dengan tim gabungan dari berbagai
departemen (umumnya dari Developer dan IT Operations), mereka bisa
secara langsung saling berkomunikasi, berbagi pengetahuan, dan silih
memberi feedback seraya menyelesaikan masalah bersama.

Mendorong Tanggung Jawab ke Tempat Asalnya

Saat sedang mengembangkan aplikasi, mungkin saja secara tidak sengaja

kita melanggengkan sistem kerja yang tidak efektif karena cara kita dalam
menanggapi suatu insiden/masalah, apalagi jika aplikasi yang dikembangkan
memiliki sistem yang kompleks. Sebagai contoh, dengan menambahkan lebih
banyak proses approval (persetujuan), sebenarnya malah akan
meningkatkan kemungkinan kegagalan di masa depan.

Percaya atau tidak, efektivitas dari proses approval akan menurun saat kita
menempatkan tindakan pengambilan keputusan jauh dari tempat di mana
pekerjaan dilakukan. Bahkan, tak hanya menurunkan kualitas dari keputusan
yang diambil, melainkan juga dapat memperlama waktu dalam merilis
aplikasi karena kita harus menyusuri birokrasi yang berbelit. Sehingga, ini
dapat mengurangi kemampuan kita untuk belajar dari keberhasilan dan
kegagalan. Pada akhirnya, takut berbuat salah.

Masih bingung? Oke, coba simak beberapa contoh proses yang tidak efektif
berikut ini.
  Tim A memerlukan bantuan tim lain untuk menyelesaikan tugas-tugas
yang membosankan, rawan kesalahan, dan manual. Padahal,
sebenarnya tugas-tugas tersebut dapat dengan mudah diotomatisasi
dan dijalankan sesuai kebutuhan oleh tim A.
 Tim A memerlukan approval dari orang-orang yang sebenarnya tak
memiliki pengetahuan yang memadai tentang pekerjaan yang
dilakukan oleh tim A sehingga orang-orang tersebut akhirnya hanya
sekadar memberi stempel “approve/setuju”.
 Menyerahkan sejumlah besar pekerjaan ke tim atau komite khusus
untuk meminta persetujuan dari mereka dan kemudian menunggu
respons dari mereka dalam waktu yang lama.

Sungguh, contoh-contoh di atas sangatlah tidak efektif dan memakan waktu.

Oleh karena itu, sebagai gantinya, kita seharusnya mengefektifkan berbagai
proses dengan melimpahkan wewenang hanya kepada orang-orang yang
terlibat dalam proses pengembangan aplikasi untuk menemukan dan
memperbaiki masalah sesuai dengan area keahlian mereka sebagai bagian
dari pekerjaan sehari-hari.

Dengan melakukan ini, kita mendorong tanggung jawab dan pengambilan

keputusan ke tempat asalnya (di mana pekerjaan tersebut dilakukan, yakni
lingkungan di mana aplikasi dikembangkan), alih-alih mengandalkan
persetujuan dan pengecekan dari tim lain atau eksekutif yang jauh
keberadaannya.

Ada beberapa inisiatif yang bisa kita lakukan, di antaranya:

 Kita bisa terapkan peer review (aktivitas memeriksa, meninjau, dan

mengevaluasi kode oleh sesama Developer) terhadap perubahan kode
yang dilakukan untuk menjamin bahwa kode dapat beroperasi di
lingkungan production sesuai yang diharapkan.
 Kita dapat mengotomatiskan sebanyak mungkin proses pemeriksaan
kualitas kode yang biasanya dilakukan oleh departemen QA (Quality
Assurance).
 Alih-alih Developer harus meminta ke tim lain agar pengujian bisa
dijadwalkan atau dijalankan segera, kita bisa mengeliminasi birokrasi
tersebut agar pengujian tersebut dapat dilakukan kapan saja.
Sehingga, ini memungkinkan Developer untuk menguji kode mereka
sendiri sesegera mungkin dan bahkan men-deploy perubahan kode ke
dalam lingkungan production secara mandiri.
Nah, dengan mengimplementasikan poin-poin di atas, kita menjadikan
kualitas kode, keamanan aplikasi, dan keandalan infrastruktur sebagai
tanggung jawab semua orang, bukan hanya tim atau departemen tertentu.

Memiliki Developer yang saling berbagi tanggung jawab terhadap kualitas

sistem yang mereka bangun sendiri tak hanya mampu meningkatkan hasil,
tetapi juga dapat memperbaiki alur feedback. Apa yang Developer lakukan
terhadap sistem akan langsung mereka rasakan sendiri dampaknya. Tak
perlu lagi menunggu tim lain yang memberi tahu mereka. Sebelum masalah
makin menyebar, Developer bisa langsung memperbaikinya sedini mungkin.

Mengoptimalkan Kualitas Operasional

Dalam dunia IT, ada dua tipe pelanggan yang harus kita pertimbangkan saat
mengembangkan aplikasi:

 Pelanggan eksternal, yang kemungkinan besar membayar untuk

layanan yang perusahaan berikan.
 Pelanggan internal, yang menerima dan memproses pekerjaan kita
selanjutnya.

Lantas, siapakah di antara dua ini yang harus diprioritaskan? Sebenarnya,

keduanya sama-sama penting untuk diutamakan. Dalam kasus bisnis, maka
pelanggan eksternal alias pengguna aplikasilah yang perlu diprioritaskan
karena mereka yang membuat perusahaan bisa bertahan di tengah
gempuran persaingan pasar. Kita wajib memiliki empati kepada pengguna
aplikasi dengan cara lebih tanggap dalam mengidentifikasi dan
menyelesaikan setiap masalah yang mereka hadapi.

Namun, itu bukan berarti menafikan keberadaan pelanggan internal. Bagi

Developer, pelanggan internalnya adalah tim IT Operations yang menerima
kode dan memprosesnya ke lingkungan production. Oleh karena itu, dalam
proses pengembangan aplikasi, Developer juga wajib mengoptimalkan
kualitas operasional dengan mempertimbangkan hal-hal seperti arsitektur,
kinerja, stabilitas, pengujian, konfigurasi, dan keamanan. Semua aspek-
aspek tersebut harus diprioritaskan, sama seperti fitur pengguna.

--
Semoga dengan pembahasan di atas Anda paham ya dengan The Second
Way. Intinya, menciptakan alur feedback (umpan balik) yang cepat
merupakan hal yang sangat penting untuk mencapai kualitas kode,
keamanan aplikasi, dan keandalan infrastruktur dalam proses
pengembangan aplikasi.

Nah, salah satu cara terbaik untuk mencapainya adalah dengan memiliki
praktik seperti continuous integration atau continuous deployment (akan kita
pelajari nanti) yang dipadukan bersama dengan rangkaian automated test
(pengujian otomatis) yang cepat. Dengan mempraktikkan hal-hal ini,
feedback (umpan balik) bisa segera tersampaikan dengan cepat ke
Developer (atau tim terkait) dan segera diperbaiki.
The First Way: Prinsip terkait Alur Kerja
Dalam bidang IT, terutama yang berkaitan dengan pengembangan aplikasi,
suatu “pekerjaan” umumnya mengalir dari kiri ke kanan, yakni dari
Development hingga Operations (yang mana merupakan area fungsional
antara bisnis dan pelanggan).

Maka dari itu, prinsip DevOps pertama yang akan kita bahas adalah The First
Way, yakni terkait alur kerja. Prinsip ini menjelaskan bahwa kita
membutuhkan alur kerja yang cepat dan lancar dalam proses pengembangan
aplikasi, mulai dari penulisan kode oleh Developer (Development), penyiapan
infrastruktur dan proses deploy aplikasi oleh IT Operations (Operations),
hingga akhirnya sampai di gadget pengguna/pelanggan (Customer) dan
terasa manfaat atau nilai dari aplikasi/fitur/pembaruan perangkat lunak
tersebut.

Dalam proses pengembangan aplikasi, ada beberapa cara atau metode

untuk mengoptimalkan alur kerja, yakni membuat pekerjaan kita menjadi
“tampak”, membatasi work in process (tugas yang masih tahap pengerjaan
dan/atau belum terselesaikan), mengurangi skala batch yang dikerjakan,
memangkas jumlah handoff, serta mengidentifikasi dan memperbaiki
hambatan/batasan yang ada secara kontinu.

Untuk lebih jelasnya, mari kita bahas beberapa metode di atas ini satu per
satu.

Membuat Pekerjaan Menjadi Tampak

Pada submodul sebelumnya, kita sedikit membawa topik manufaktur dan

membandingkannya dengan DevOps. Kali ini, kita akan angkat bidang
manufaktur lagi untuk bisa memahami apa perbedaannya dengan dunia IT,
dan akhirnya pada DevOps.

Perbedaan mencolok antara IT dan manufaktur ialah bahwa pekerjaan di

bidang IT sejatinya tidak tampak/terlihat secara fisik. Dalam bidang
manufaktur, pekerjaan atau aktivitas produksi dapat terlihat secara gamblang
sehingga kita bisa mengetahui semua alur yang ada dan mengidentifikasi
dengan jelas sekiranya di bagian mana atau di mesin mana alur produksi
terhambat. Meski begitu, pemindahan pekerjaan antar mesin biasanya
berjalan lambat sebab produk harus dipindahkan secara fisik.

Nah, ini berbanding terbalik dengan dunia IT. Karena hampir semua aktivitas
dikerjakan melalui komputer dan dieksekusi melalui perangkat lunak,
pekerjaan menjadi tak tampak/terlihat secara fisik. Meski begitu, ini membuat
pekerjaan bisa dipindahkan atau didelegasikan secara mudah, seperti
menugaskan seseorang hanya dengan mengirim email atau menyampaikan
pesan di aplikasi chatting. Sebagai contoh, pimpinan tim Developer bisa
langsung mengabari pimpinan tim IT Operations melalui email bahwa aplikasi
yang dikembangkan sudah siap untuk di-deploy.

Namun, di situlah letak masalahnya. Karena saking mudahnya, pekerjaan

yang kita delegasikan bisa saja tak kunjung dikerjakan, entah karena orang
yang dituju tidak paham dengan email atau pesan dari kita; informasi yang
kita berikan tak cukup lengkap; orang/tim tersebut sedang memiliki banyak
pekerjaan lain; atau mungkin memang sedang dalam tahap pengerjaan,
tetapi orang/tim tersebut sedang mengalami kesulitan; dan masih banyak lagi
masalah lainnya.

Ini bisa terjadi karena ketidakjelasan dalam pendelegasian tugas serta

ketidakbakuan proses alur kerja yang ada. Dalam proses pengembangan
aplikasi, ini problem yang tak bisa diremehkan sebab pada akhirnya
perusahaan bisa terlambat dalam memberikan fitur baru kepada pelanggan
atau bahkan aplikasi benar-benar gagal beroperasi di lingkungan production.

Nah, agar bisa mengidentifikasi mana pekerjaan/tugas yang punya proses

pengerjaan yang baik dan mana yang sedang dalam antrean atau bahkan
terhenti, kita perlu membuat alur kerja yang sejelas-jelasnya.

Salah satu metode terbaik untuk melakukan ini adalah menggunakan papan
kerja visual, seperti Kanban board atau Scrum board, di mana kita dapat
merepresentasikan suatu pekerjaan atau tugas pada semacam card (kartu)
baik fisik maupun digital.

Suatu pekerjaan akan dimulai dari sebelah kiri (seringnya diambil

dari backlog, yakni akumulasi pekerjaan yang belum selesai atau hal-hal
yang perlu ditangani), kemudian dipindahkan dari satu kolom ke kolom
lainnya ke arah kanan, dan dianggap selesai ketika mencapai sisi kanan
Kanban board (biasanya dalam kolom berlabel “Done”, “Delivered”, atau “ In
Production" bila pada IT Operations).
Gambar di atas adalah contoh Kanban board yang digunakan pada siklus
DevOps secara global atau keseluruhan. Alur kerja pada gambar di atas
dimulai dari kolom Ready (siap untuk dikerjakan)
hingga Investigate (pengumpulan informasi, pencatatan spesifikasi,
persiapan, perancangan, dll). Setelah itu, masuk tahap Development, di
mana kode mulai ditulis oleh Developer sesuai dengan spesifikasi dan
kebutuhan awal.

Bila sudah selesai, alur selanjutnya adalah masuk ke bagian Operations, di

mana IT Operations mempersiapkan infrastruktur untuk proses deployment
aplikasi. Sebelum disajikan ke publik sepenuhnya, aplikasi akan diuji terlebih
dahulu untuk proses UAT (User Acceptance Testing) guna memvalidasi
apakah aplikasi sudah memenuhi kebutuhan bisnis atau belum. Jika sudah
sesuai harapan, aplikasi lantas di-deploy ke lingkungan production sehingga
akhirnya tersaji ke seluruh pengguna (dalam hal ini berarti sudah masuk
tahap “Delivered”).

Perlu Anda ketahui, dalam menggunakan Kanban board pada DevOps, suatu
pekerjaan tidak bisa disebut selesai ketika hanya selesai di sisi Developer
saja, melainkan saat aplikasi berjalan dengan sukses di lingkungan
production, dalam kata lain telah memberikan nilai kepada pelanggan.
Semoga Anda sudah paham dengan pembahasan ini. Intinya, dengan
menempatkan semua pekerjaan kita ke dalam sebuah antrean pada papan
kerja visual dan membuatnya “tampak”, setiap orang (yang memiliki
wewenang) dapat lebih mudah memprioritaskan pekerjaan dalam konteks
tujuan umum/bersama, bukan hanya untuk masing-masing tim. Selain itu,
melakukan hal ini juga memungkinkan setiap orang/tim untuk melakukan satu
tugas/pekerjaan dengan prioritas tertinggi hingga benar-benar selesai yang
berujung peningkatan kualitas pekerjaan.

Membatasi Work In Process (WIP)

Mari kita ambil lagi contoh dalam bidang manufaktur. Pekerjaan sehari-hari di
dunia manufaktur umumnya ditentukan oleh jadwal produksi yang dibuat
secara teratur (misalnya, harian atau mingguan) dan menetapkan pekerjaan
mana yang harus dijalankan berdasarkan pesanan pelanggan, tanggal jatuh
tempo pesanan, suku cadang yang tersedia, dan sebagainya.

Sebaliknya, dalam bidang IT, justru pekerjaan itu biasanya jauh lebih dinamis
(tak menentu), terutama pada kasus shared services (layanan bersama), di
mana tim (dalam hal ini, Developer dan IT Operations) harus memenuhi
kebutuhan atau tuntutan banyak pihak yang berbeda seantero perusahaan.
Akibatnya, pekerjaan sehari-hari mereka malah didominasi oleh permintaan-
permintaan yang acapkali datang dari divisi lain dengan prioritas (seolah-
olah) mendesak yang masuk melalui berbagai mekanisme komunikasi,
termasuk ticketing system, email, telepon, chat, atau bahkan obrolan saat
berpapasan dengan atasan dari divisi lain di lorong kantin. Ini menjadi
masalah karena Developer maupun IT Operations menjadi tidak fokus
terhadap tugas utama mereka. Meskipun bisa multitasking, itu bukanlah opsi
yang bagus untuk diambil.

Sebagai manusia, multitasking adalah sesuatu yang harus Anda hindari

dalam melakukan aktivitas. Coba pikirkan, hanya sekadar menyelesaikan
tugas sederhana seperti menyortir bentuk geometris saja, waktu kita akan
tersita secara signifikan saat melakukan banyak tugas secara bersamaan.
Apalagi mengerjakan tugas di bidang IT yang pada dasarnya jauh lebih
kompleks secara kognitif daripada sekadar menyortir bentuk geometris,
imbas multitasking yang ditimbulkan pada segi waktu akan jauh lebih buruk.
Bayangkan saja, tugas sehari-hari yang seharusnya bisa dikerjakan hanya
dalam 30 menit bisa jadi memakan waktu hingga berminggu-minggu akibat
dari multitasking (saking banyaknya tugas yang datang dari luar).
Untungnya, kita bisa membatasi multitasking ketika menggunakan Kanban
board untuk mengelola pekerjaan, seperti mengodifikasi dan memberlakukan
pembatasan WIP (work in process) untuk setiap kolom dengan cara
menempatkan batas atas atau maksimal jumlah card yang dapat ditaruh
pada kolom tersebut.

Misalnya, kita bisa menetapkan batas WIP hanya sebanyak 3 card untuk
UAT. Ketika sudah ada 3 card di kolom UAT, kita tidak bisa lagi
menambahkan card baru ke kolom tersebut, kecuali jika minimal satu card
dipindahkan ke kolom lain, baik karena sudah selesai (digeser ke kolom
Delivered) ataupun ditunda (digeser kembali ke kolom Done pada bagian
Ops atau jauh hingga ke Backlog atau Ready).

Pada akhirnya, ini menyimpulkan bahwa tidak boleh ada tugas yang
dikerjakan oleh tim (baik Developer maupun IT Operations) sampai
seseorang (yang memberikan tugas atau dirinya sendiri)
merepresentasikannya terlebih dahulu ke dalam bentuk card. Sekali lagi, ini
menegaskan bahwa semua pekerjaan harus dibuat tampak/terlihat. Jadi, jika
suatu waktu seorang Developer mendapatkan permintaan dari divisi lain
melalui email, tetapi belum dimasukkan ke Kanban board, maka sang
Developer tak boleh mengerjakan tugas tersebut.
Mengurangi Skala Batch yang Dikerjakan

Komponen penting lainnya untuk menciptakan alur kerja yang lancar dan
cepat adalah melakukan pekerjaan dalam skala batch yang kecil.

Catatan: Batch atau batch production adalah metode di mana sekelompok

produk identik diproduksi secara bersamaan (bukan satu per satu),
sedangkan skala batch berarti jumlah unit/produk yang dieksekusi secara
bersamaan dalam satu waktu selama proses produksi.

Kala itu, dalam bidang manufaktur, produksi dalam skala batch yang
besar/banyak merupakan praktik yang umum, terutama untuk operasi di
mana penyetelan mesin dan changeover (proses mengubah lini atau mesin
dari menjalankan satu produk ke produk lainnya) memakan waktu dan
mahal.

Sebagai contoh, memproduksi panel bodi mobil besar tentunya memerlukan

pengaturan cetakan yang gede nan berat pada mesin stamping logam, yang
mana ini adalah sebuah proses kompleks dan bisa memakan waktu berhari-
hari. Ditambah lagi, proses changeover pun umumnya cukup mahal sehingga
sering kali panel bodi mobil akan di-stamp/dicetak sebanyak-banyaknya
dalam skala batch yang besar/banyak untuk mengurangi biaya.

Namun, ketahuilah bahwa memproduksi dalam skala batch yang besar dapat
menghasilkan tingkat WIP (work in process) yang tinggi dalam alur kerja
pabrik. Hasilnya adalah lead time (waktu yang diperlukan untuk membuat
sebuah produk hingga akhirnya dikirim ke pelanggan) akan menjadi lama dan
kualitas produk pun buruk. Jika ditemukan ada masalah atau kecacatan di
salah satu panel bodi, seluruh panel bodi pada batch tersebut harus dibuang.
Mubazir waktu dan anggaran, kan?

Salah satu hikmah utama yang bisa kita petik adalah bahwa untuk
mempersingkat lead time dan meningkatkan kualitas, kita harus berusaha
untuk terus memperkecil/mengurangi skala batch yang diproduksi. Batas
minimalnya adalah “single-piece flow”, di mana setiap operasi dilakukan satu
unit pada satu waktu.

Mari kita ambil contoh lain. Katakanlah sebuah pabrik memproduksi 10

brosur yang harus segera dikirim ke pelanggan. Setiap brosur memerlukan 4
langkah: Fold (melipat kertas), Insert (memasukkan kertas ke dalam amplop),
Seal (menyegel amplop), dan Stamp (mencap amplop).

Apabila kita menerapkan strategi skala batch yang besar (a.k.a, "mass
production"), itu artinya satu operasi akan dilakukan secara berurutan pada
masing-masing 10 brosur tersebut. Dengan kata lain, pertama-tama 10
lembar kertas akan dilipat, lalu masing-masing dimasukkan ke dalam amplop,
kemudian 10 amplop itu disegel, dan terakhir semuanya dicap.

Di sisi lain, dalam strategi skala batch yang kecil (a.k.a, "single-piece flow"),
semua langkah yang diperlukan untuk menyelesaikan setiap brosur dilakukan
secara berurutan sebelum mengeksekusi brosur berikutnya. Dengan kata
lain, satu lembar kertas pertama akan dilipat, lalu dimasukkan ke dalam
amplop, kemudian disegel, dan dicap. Setelah brosur pertama selesai,
barulah lembar kertas berikutnya dieksekusi. Begitu seterusnya hingga kertas
kesepuluh.

Perbedaan antara penggunaan skala batch yang besar dan kecil dapat
menghasilkan dampak yang dramatis. Misalnya, setiap operasi (Fold, Insert,
Seal, dan Stamp) memakan waktu 10 detik untuk masing-masing 10 amplop.
Dengan strategi skala batch yang besar maka amplop pertama baru akan
benar-benar selesai diproduksi (telah dicap) setelah 310 detik (100 detik
proses Fold + 100 detik proses Insert + 100 detik proses Seal + 10 detik
proses Stamp untuk amplop pertama). Sungguh lama ya hanya untuk
menunggu hasil amplop pertama selesai?

Lebih buruknya lagi, apabila pada saat operasi penyegelan amplop (Seal)
ternyata kita menemukan bahwa ada kesalahan pada langkah pertama
(Fold). Dalam hal ini, berarti kita baru bisa menemukan kesalahan tersebut
setelah 200 detik berlalu dan walhasil mengulang seluruh operasi kembali
dari awal (Fold dan Insert) terhadap kesepuluh brosur tersebut.

Sebaliknya, dalam strategi skala batch yang kecil (a.k.a single-piece flow),
amplop pertama bisa selesai diproduksi hanya dalam waktu 40 detik (10 detik
Fold + 10 detik Insert + 10 detik Seal + 10 detik Stamp). Luar biasa, kan? Ini
8x lebih cepat ketimbang strategi skala batch yang besar. Terutama, jika
pada saat operasi penyegelan amplop (Seal) ternyata kita menemukan
kesalahan pada langkah pertama (Fold), kita hanya perlu mengulang satu
brosur saja.

Ini membuktikan bahwa skala batch yang kecil dapat menghasilkan WIP lebih
sedikit, lead time lebih cepat, deteksi kesalahan lebih awal, dan pengerjaan
ulang lebih sedikit.

Oke, sudah cukup berkutat di bidang manufakturnya, mari kita masuk ke

dunia IT. Dampak negatif dari skala batch yang besar juga sama relevannya
dengan di bidang IT. Misalnya, suatu proyek IT menerapkan model waterfall
dan memiliki jadwal tahunan untuk merilis perangkat lunak ke publik yang
berarti kode yang telah dikerjakan oleh tim Developer selama satu tahun
penuh akhirnya di-deploy ke lingkungan production.

Proyek IT tersebut memiliki skala batch yang besar, selain karena setiap
langkah operasi (Code, Build, Test, dan Deploy di model waterfall) untuk
keseluruhan aplikasi dikerjakan secara berurutan, pun kita harus menunggu
lama dan baru bisa melihat hasilnya (rilis ke publik) hingga 1 tahun lamanya.
Itu pun jika aplikasi berjalan dengan baik. Kalau tidak? Tentu tim harus
mengerahkan seluruh pasukan dan tenaganya untuk menyelesaikan
berbagai WIP dan gangguan yang melintang. Akibatnya, ini akan
menghasilkan alur kerja yang tidak baik dan kualitas perangkat lunak yang
buruk.
Hal ini menjelaskan bahwa makin besar ukuran unit (cakupan kode) yang di-
deploy ke lingkungan production, makin sulit pula untuk mendiagnosis dan
memperbaiki kesalahan tersebut, dan makin lama pula waktu yang
dibutuhkan untuk memulihkannya (membuat aplikasi menjadi berjalan normal
kembali saat terjadi down).

Oleh karena itu, selaras seperti yang terjadi di manufaktur, di dunia IT pun
perlu diterapkan single-piece flow. Di DevOps, hal itu dapat diwujudkan
dengan praktik Continuous Deployment, di mana setiap perubahan kode
yang dilakukan pada version control system (seperti Git) diintegrasikan, diuji,
dan di-deploy ke lingkungan production secara bertahap dan dalam
unit/cakupan kode yang tidak terlalu besar. Dengan demikian, alur kerja yang
ada bisa tercipta makin baik dan kualitas perangkat lunak dapat kian
meningkat. Kita akan bahas lebih lanjut soal ini nanti.

Memangkas Jumlah Handoff

Sebagai permulaan, ketahui dulu bahwa yang dimaksud handoff di sini

adalah penyerahan/pengiriman informasi, tanggung jawab, atau pekerjaan
dari satu pihak ke pihak lain.
Dalam proses pengembangan aplikasi, contohnya adalah penyerahan kode
yang sudah matang dari Developer ke IT Operations untuk di-deploy ke
lingkungan production.

Tahukah Anda bahwa kerap kali siklus untuk melakukan deployment itu
mengharuskan kita menunggu hingga berbulan-bulan lamanya. Ini bisa
terjadi karena nyatanya ada ratusan (atau bahkan ribuan) operasi/prosedur
yang diperlukan dan butuh kontribusi banyak pihak untuk memindahkan kode
dari version control system (seperti Git) hingga akhirnya tiba di lingkungan
production (rilis ke publik), termasuk pengujian, pembuatan environment
(misal, untuk lingkungan production), administrasi server, administrasi
jaringan, hingga keamanan informasi.

Selain itu, setiap kali ingin menyerahkan pekerjaan dari satu tim ke tim
lainnya (handoff), kita memerlukan berbagai jenis cara komunikasi dan
medium, seperti mengirim email, berkoordinasi di sebuah rapat, menugaskan
di tools manajemen proyek atau ticketing system, penulisan dokumen
spesifikasi teknis, dll.

Nah, setiap langkah/operasi/prosedur ini merupakan potensi yang

memungkinkan terjadinya antrean pekerjaan, yang berarti kita harus
menunggu sampai pekerjaan tersebut benar-benar dikerjakan dan selesai.
Masalahnya, saat kita menyerahkan pekerjaan ke tim lain untuk mereka
eksekusi (misal Developer menyerahkan kode ke IT Operations untuk di-
deploy), belum tentu itu akan langsung dikerjakan. Apabila tim yang diminta
sedang sibuk sehingga tidak ada kapasitas untuk mengeksekusi pekerjaan
tersebut, bisa jadi pekerjaan yang kita kirim akan ditunda sampai mereka
siap mengerjakannya. Itulah mengapa pekerjaan yang sebenarnya hanya
membutuhkan waktu 30 menit, bisa jadi selesai dalam waktu berminggu-
minggu. Bukan lama dalam proses pengerjaannya, tetapi lantaran menunggu
pekerjaan tersebut dieksekusi.

Saking lamanya, terkadang diperlukan eskalasi konstan (contoh, mendatangi

langsung dan berdiskusi dengan orang yang bertanggung jawab untuk
memprioritaskan pekerjaan yang diminta) semata-mata agar pekerjaan
tersebut bisa dieksekusi dan selesai dalam timeline yang dibuat.

Selain itu, ini akan berdampak semakin buruk jika jumlah handoff yang terjadi
terlalu banyak. Salah satunya, beberapa atau sebagian informasi penting
yang melekat pada suatu pekerjaan atau tugas bisa jadi kehilangan konteks
selama proses handoff. Sebagai contoh, seorang Administrator Server
mendapatkan tugas baru dari atasannya (yang mana atas permintaan dari
tim bisnis) untuk membuat user accounts (akun pengguna). Namun, karena
informasi yang diterima tak begitu lengkap dan tidak tersampaikan dengan
baik, sang Administrator Server pun menjadi kesulitan dalam melakukan
tugasnya, entah itu karena dia tak tahu akun ini untuk aplikasi yang mana,
mengapa akun ini harus dibuat, apa peran atau kemampuan untuk akun ini,
dan lain sebagainya.

Maka dari itu, untuk menangani masalah ini, langkah tepat yang harus
dilakukan adalah memangkas jumlah handoff, baik dengan mengotomatiskan
sebagian besar pekerjaan atau mereorganisasi tim (misal, tim Developer dan
tim IT Operations bersatu menjadi tim DevOps) sehingga tim tersebut dapat
menyelesaikan pekerjaan (misal, menyajikan fitur baru ke pengguna) dengan
cepat dan lancar tanpa perlu terus-menerus bergantung pada orang/tim lain.

Hasilnya, kita dapat memperbaiki alur kerja, mengurangi waktu tunggu saat
proses handoff, dan meningkatkan kualitas pekerjaan.

Mengidentifikasi dan Memperbaiki Constraint

Sebagai bagian dari langkah untuk mengurangi lead time dan

meningkatkan throughput (jumlah pekerjaan yang berhasil selesai dan
sukses dikirim ke pelanggan), kita perlu secara berkala mengidentifikasi apa
saja constraint (kendala) yang terjadi pada alur kerja, terutama dalam proses
pengembangan aplikasi.

Mengidentifikasi dan memperbaiki constraint ini menjadi poin penting sebab

sebesar apa pun upaya kita untuk melakukan perbaikan terhadap alur kerja,
jika kita tidak memperbaiki constraint, itu akan sia-sia.

Mari kita ambil contoh, umpamanya ada seorang IT Operations bernama

Budi yang terlibat dalam Proyek A (proyek penting perusahaan). Sudah
menjadi kesepakatan bersama bahwa proyek ini harus diprioritaskan
ketimbang hal-hal lain karena ini adalah proyek yang akan menghasilkan
keuntungan besar bagi perusahaan dalam sejarah. Akan tetapi, si Budi ini
malah sibuk luar biasa lantaran diminta oleh tim Sales untuk mengerjakan
tugas-tugas lain, seperti membuat akun, mereset password, dan lain-lain
yang tidak berkaitan dengan Proyek A tadi.
Karena saking sibuknya, saat diminta untuk men-deploy kode (terkait Proyek
A), ia tak kunjung mengeksekusinya, bahkan hingga berhari-hari lamanya.
Padahal, normalnya tugas ini bisa ia eksekusi hanya dalam waktu beberapa
jam saja. Alhasil, Proyek A pun menjadi terlambat dan masalah ini berpotensi
untuk merugikan perusahaan.

Nah, dari contoh di atas, kita bisa identifikasi bahwa yang menjadi
“constraint” atau kendala/hambatan utama pada Proyek A adalah Budi.
Pasalnya, yang seharusnya ia fokus terhadap Proyek A, nyatanya malah
mengerjakan hal-hal lain di luar pekerjaan utamanya. Namun, bukan berarti
sepenuhnya salah Budi sebab ia pun hanya menerima tugas dari orang lain.
Oleh karena itu, kita harus bisa membatasi apa saja yang perlu dikerjakan
oleh Budi–tentu hanya fokus terhadap Proyek A–dan mendelegasikan tugas-
tugas dari tim Sales kepada orang lain yang sekiranya sedang tidak terlalu
banyak pekerjaan. Sehingga, Budi bisa lebih mengabdikan diri sepenuhnya
pada Proyek A dan memberikan manfaat yang berarti dalam kontribusi pada
proyek tersebut.

Budi hanyalah salah satu contoh constraint atau kendala yang terjadi pada
proses pengembangan aplikasi. Tak hanya “orang” (seperti Budi), constraint
pun bisa terjadi pada “proses atau praktik”. Jika Anda sering berjibaku dan
andil dalam proses pengembangan aplikasi, niscaya Anda akan menemukan
lebih banyak contoh-contoh constraint lainnya yang dapat menghambat alur
kerja.

Misalnya, seperti pembuatan environment (seperti test atau production) dan

deployment aplikasi yang bisa memakan waktu hingga berminggu-minggu.
Padahal, seharusnya proses tersebut bisa diautomasi agar lebih fleksibel dan
berlangsung cepat.

Oke, itu dia beberapa hal yang ada pada The First Way: Prinsip terkait Alur
Kerja. Tentu sebenarnya masih ada banyak hal lain yang bisa kita bahas,
tetapi cukup itu dulu yang perlu Anda pahami untuk saat ini. Semoga dengan
memahami The First Way ini, Anda bisa menerapkannya agar proses
transformasi DevOps di perusahaan pun semakin baik.

Intinya, tujuan dari The First Way ini adalah untuk memperbaiki alur kerja
sehingga proses pengembangan aplikasi bisa berlangsung cepat, tetapi tetap
menjaga keandalan infrastruktur dan meningkatkan kualitas aplikasi. Dengan
demikian, pada akhirnya pelanggan pun bisa merasakan fitur atau
pembaruan aplikasi lebih cepat.
The Third Way: Prinsip terkait Proses Belajar dan Eksperimen yang
Berkelanjutan
Setelah belajar tentang The First Way dan The Second Way, kini waktunya
kita memahami The Third Way, yakni prinsip terkait proses belajar dan
eksperimen yang berkelanjutan. Prinsip ini menjelaskan tentang cara
memupuk kultur untuk mendorong proses belajar dan eksperimen yang
berkelanjutan. Selain itu, prinsip ini juga membenamkan pemahaman bahwa
cara untuk menguasai sesuatu adalah melalui pengulangan dan berlatih
terus-menerus.
The Third Way memungkinkan penciptaan pengetahuan individu secara
konstan, yang kemudian diubah menjadi pengetahuan tim dan perusahaan.

Mari sedikit bercerita. Dalam operasi manufaktur dengan masalah kualitas

dan keselamatan yang sistemik, suatu “pekerjaan” biasanya didefinisikan dan
dikerjakan secara kaku. Sebagai contoh, para pekerja tidak bebas (atau
bahkan tidak bisa) melakukan inisiatif perubahan atau perbaikan ke dalam
pekerjaan sehari-hari mereka. Mereka harus patuh dengan apa yang sudah
dituliskan di aturan.
Di lingkungan seperti ini, para pekerja acapkali memiliki rasa takut dan punya
kepercayaan diri yang rendah. Bagaimana tidak? Pekerja yang melakukan
kesalahan akan dihukum, dan mereka yang memberi saran dipandang
sebagai pembuat onar. Dalam hal ini, pemimpin mereka menanamkan kultur
yang menekan (bahkan menghukum) siapa saja yang menyimpang dari
aturan, meski tujuannya untuk perbaikan.

Namun, ini berbanding terbalik dengan apa yang terjadi pada operasi
manufaktur yang berkualitas dan berkemajuan, di mana justru mereka
memerlukan dan secara aktif mendorong proses belajar. Suatu pekerjaan
tidak didefinisikan secara kaku, melainkan bersifat dinamis. Para pekerja
didorong untuk bereksperimen dalam pekerjaan sehari-hari mereka guna
menghasilkan peningkatan dan perbaikan, tetapi tetap mengikuti standarisasi
prosedur kerja yang ketat dan pendokumentasian hasil kerja.

Di dunia IT, kita pun mesti melakukan hal yang sama. Kita perlu menciptakan
kultur yang mampu meningkatkan rasa saling percaya, yang menegaskan
bahwa kita semua adalah sejatinya seorang “pelajar” seumur hidup yang
mau tak mau memang harus mengambil risiko dalam aktivitas dan pekerjaan
kita sehari-hari.

Tentu kita semua tahu bahwasanya eksperimen yang dilakukan terus-

menerus bukanlah hal yang mudah untuk dilestarikan sebab membutuhkan
keberanian dalam pengambilan risiko dan kelapangan hati dalam belajar
(baik jika berhasil maupun gagal).

Proses pengambilan risiko biasanya adalah sesuatu yang sebisa mungkin

dihindari oleh bisnis. Namun sebaliknya, justru eksperimen dan pengambilan
risiko adalah hal yang bagus bagi IT karena memungkinkan kita untuk
senantiasa meningkatkan sistem kerja.

Proses eksperimen ini sering kali mengharuskan tim untuk berani melakukan
hal-hal di luar kebiasaan mereka selama ini. Ini merupakan hal yang bagus.
Pasalnya, ketika terjadi kesalahan atau kegagalan, tim bisa memperbaikinya
dan belajar dari kesalahan/kegagalan tersebut.

Dengan begitu, ke depannya tim bisa lebih cekatan dalam mengembangkan

aplikasi dan terhindar dari kegagalan yang berulang. Selain itu, bila
seandainya terjadi kesalahan yang tak diinginkan, tim akan mengerti apa
yang harus dilakukan dan memitigasi agar kegagalan tersebut tidak terulang
kembali.
Jika mampu menerapkan The First Way dan The Second Way, kelak kita
akan lebih berani dalam mengambil risiko. Sebabnya, kita tahu bahwa
risikonya takkan terlalu besar (mengingat kita memiliki skala batch pekerjaan
yang kecil) dan akan mendapatkan feedback cepat mengenai pekerjaan yang
kita lakukan.

Apabila kita sudah terbiasa melakukan eksperimen dan belajar dari

kesalahan, terciptalah kultur untuk selalu ingin berinovasi dan berani dalam
mengambil risiko. Dengan menerapkan pendekatan semacam ini, kita akan
senantiasa belajar dari keberhasilan dan kegagalan, seraya mengidentifikasi
sekiranya mana ide yang gagal dan mana ide yang berhasil sehingga perlu
diperkuat.

Setiap proses belajar dan eksperimen yang dilakukan secara mandiri, pada
akhirnya dapat diadopsi ke cakupan yang lebih luas. Dengan demikian,
teknik dan praktik baru dapat diterapkan di seluruh organisasi atau
perusahaan.

Nah, agar hal tersebut bisa terwujud, ada beberapa poin penting yang wajib
kita pahami. Mari kita kupas satu per satu.

Menghidupkan Organizational Learning

Ketika kita mengerjakan sebuah sistem yang kompleks, rasanya mustahil

untuk benar-benar bisa memprediksi hasil dari setiap tindakan yang kita
ambil. Akan tetapi, justru itulah yang berpotensi untuk mengakibatkan
peristiwa atau insiden yang tak diinginkan. Percaya atau tidak, hal-hal yang
tak terduga acapkali terjadi, meskipun kita telah melakukan tindakan
pencegahan semaksimal mungkin dan bekerja dengan hati-hati.

Masalah bisa muncul kapan pun dan sering kali dianggap sebagai kesalahan
manusia. Sayangnya, pihak manajemen perusahaan terkadang merespons
dengan berlebihan, seperti menyalahkan dan mempermalukan “si pembuat
masalah”, bahkan hingga menghukumnya.
Kemudian, untuk mencegah masalah yang sama terulang kembali, mereka
membuat lebih banyak aturan dan birokrasi (misal, meminta persetujuan
manajemen) dalam bekerja.

Sistem kerja seperti ini malah meningkatkan rasa takut di benak pegawai dan
membuat perusahaan terasa sangat birokratis. Padahal, seharusnya
perusahaan menyosialisasikan dan mendorong pegawai agar lebih berhati-
hati dalam bekerja, terutama dalam pekerjaan yang bersifat kritis.

Isu-isu semacam ini terus menjadi masalah utama dalam bidang IT sebab
pekerjaannya hampir selalu dilakukan dalam sistem yang kompleks. Karena
pegawai sudah dihantui oleh rasa takut bila berbuat salah, akibatnya
masalah-masalah yang terjadi tak kunjung dilaporkan dan tetap tersembunyi
sehingga pada akhirnya masalah yang lebih besar pun terjadi.

Lantas, bagaimana solusinya? Oke, sebelum ke sana, pahamilah terlebih

dahulu bahwa menurut Dr. Ron Westrum (salah satu yang pertama
mengamati pentingnya budaya organisasi pada keselamatan dan kinerja)
ada 3 tipe kultur perusahaan, antara lain:

 Perusahaan patologis, dicirikan oleh rasa takut yang menjalar di

antara pegawai. Pegawai sering kali menahan informasi (baik kabar
baik maupun buruk), entah karena alasan persaingan ataupun takut
akan hukuman. Ini menyebabkan suatu masalah acapkali tersembunyi.
 Perusahaan birokrasi, identik penuh dengan aturan dan proses
berbelit. Jika terjadi masalah atau kegagalan, ia akan diproses melalui
sistem penilaian, yang mana pada akhirnya akan menghasilkan
hukuman atau justru pengampunan.
 Perusahaan generatif, ciri-cirinya adalah aktif dalam mencari dan
berbagi informasi agar perusahaan bisa lebih mudah dalam mencapai
misinya. Tanggung jawab suatu pekerjaan atau proyek biasanya
terbagi di seluruh perusahaan. Apabila terjadi suatu masalah atau
kegagalan, perusahaan akan melakukan refleksi dan menyelidiki akar
masalahnya, bukan orangnya.

Nah, dari uraian di atas, maka bisa ditarik kesimpulan bahwa penting untuk
membangun fondasi kultur perusahaan yang generatif dengan berupaya
menciptakan sistem kerja yang aman. Ketika masalah terjadi, alih-alih
mencari-cari kesalahan dari sisi manusianya, kita justru harus fokus ke akar
permasalahannya dan memikirkan bagaimana agar sistem dapat didesain
ulang guna mencegah hal yang sama terjadi lagi.
Sebagai contoh, kita bisa melakukan analisis dan evaluasi mendalam setiap
kali suatu insiden terjadi guna mendapatkan pemahaman tentang bagaimana
masalah bisa terjadi. Kemudian, kita berunding dan menyepakati seperti apa
tindakan penanggulangannya sebagai upaya untuk meningkatkan
kemampuan sistem, mencegah masalah terjadi lagi, dan memungkinkan
deteksi masalah dan pemulihan yang lebih cepat.

Dengan melakukan ini, itu artinya kita menciptakan dan menghidupkan

organizational learning alias pembelajaran organisasi/perusahaan. Bethany
Macri, seorang insinyur di Etsy menyatakan, “Dengan menghilangkan budaya
saling menyalahkan, Anda menghilangkan rasa takut; dengan
menghilangkan rasa takut, Anda mengaktifkan kejujuran; dan kejujuran
memungkinkan pencegahan.”

Jadi, dengan kita menghilangkan budaya saling menyalahkan dan

menggantikannya dengan organizational learning, perusahaan bisa menjadi
lebih giat dalam mendiagnosis dan memperbaiki diri sendiri, serta terampil
dalam mendeteksi masalah dan memecahkannya.

Pada akhirnya, ini akan membantu pengguna, meningkatkan kualitas

aplikasi, menciptakan keunggulan yang kompetitif, serta menghadirkan
tenaga kerja yang bersemangat dan berkomitmen dalam mengungkap
kebenaran.

Memperbaiki Pekerjaan Sehari-hari

Tim (baik Developer maupun IT Operations) sering kali tak mampu–atau

mungkin tidak mau–memperbaiki proses kerja yang selama ini mereka
lakukan sehari-hari. Ada banyak alasannya, entah karena sudah terlalu
nyaman atau memang terlalu rumit untuk mengubah proses kerja yang sudah
ada. Alhasil, bukan hanya mereka terus menghadapi masalah yang sama,
tetapi masalah tersebut juga bertambah buruk dari waktu ke waktu.

Ketika kita tak kunjung memperbaiki masalah dan malah sekadar

menghindarinya dengan mengandalkan suatu alternatif, masalah yang ada
akan kian menumpuk. Pada akhirnya, semua yang kita lakukan hanyalah
terus mencari alternatif dan menghindari masalah tanpa tersisa waktu untuk
melakukan pekerjaan yang produktif. Padahal, yang lebih penting daripada
melakukan pekerjaan sehari-hari adalah melakukan perbaikan/peningkatan
pada pekerjaan sehari-hari.
Ada banyak hal yang bisa dilakukan untuk memperbaiki/meningkatkan
pekerjaan sehari-hari, seperti menyisihkan waktu untuk menyelesaikan
pekerjaan yang belum sempat dieksekusi, membetulkan bug, serta me-
refactor dan memperbaiki kode-kode yang berpotensi menimbulkan masalah.

Dengan mengimplementasikan praktik-praktik tersebut, setiap orang bisa

secara langsung memperbaiki masalah sebagai bagian dari pekerjaan
sehari-hari mereka. Tak payah menunggu berhari-hari hanya untuk menanti
persetujuan dari atasan dalam memperbaiki kode.

Jika kita bisa mengatasi masalah yang ada pada pekerjaan sehari-hari,
niscaya ke depannya kita pun bisa memperbaiki berbagai masalah yang
muncul pada sistem aplikasi yang kompleks.

Mengubah Pengetahuan Lokal Menjadi Perbaikan Global

Ketika suatu pengetahuan ditemukan secara lokal (misal, berada di cakupan

tim), maka perlu adanya mekanisme yang memungkinkan global (misal, seisi
perusahaan) juga menggunakan dan mengambil manfaat dari pengetahuan
tersebut sebagai upaya untuk melakukan perbaikan.

Dengan kata lain, saat sebuah tim atau individu mendapatkan pengetahuan
atau keterampilan baru, kita perlu menyebarkannya ke seantero perusahaan
(misal, dengan mendokumentasikannya secara tertulis) sehingga diharapkan
bisa menjadi keahlian baru pula bagi orang lain. Praktik semacam ini berguna
untuk memastikan bahwa ketika seseorang melakukan pekerjaan serupa,
mereka bisa melakukannya persis seperti orang-orang yang sudah
berpengalaman.

Contoh luar biasa dari mengubah pengetahuan lokal menjadi perbaikan

global adalah US Navy’s Nuclear Power Propulsion Program (juga dikenal
sebagai "NR" atau "Naval Reactors"), yang memiliki banyak reaktor nuklir
tanpa satu pun korban yang berkaitan dengan reaktor seperti radiasi.

NR dikenal karena komitmennya yang kuat terhadap prosedur tertulis dan

pekerjaan yang terstandardisasi. Setiap penyimpangan prosedur yang terjadi
akan ditulis dan dikumpulkan ke dalam laporan insiden sebagai bahan
pembelajaran. Mereka akan terus memperbarui prosedur dan rancangan
sistem berdasarkan temuan dari laporan insiden tersebut supaya ke
depannya mereka bisa mendeteksi setiap potensi kegagalan.
Hasilnya, ketika kru baru (new crew) berangkat ke penempatan pertama
mereka di laut lepas, mereka akan merasa termudahkan dan mendapatkan
manfaat dari laporan insiden karena semua hal sudah terdokumentasikan
secara rapi terkait reaktor nuklir. Yang sama mengesankannya adalah bahwa
pengalaman mereka sendiri pun nantinya akan ditambahkan ke laporan
tersebut sehingga dapat membantu kru di masa depan dalam melakukan
pekerjaan mereka dengan aman.

Hal yang sama pun berlaku di dunia IT, terutama DevOps. Kita harus
membuat mekanisme serupa untuk menciptakan pengetahuan global, seperti
menyusun laporan post-mortem (laporan yang ditulis pada akhir proyek untuk
menentukan dan menganalisis unsur-unsur proyek yang berhasil atau tidak
berhasil dan menjadikannya sebagai sebagai pelajaran) dan membuatnya
lebih mudah dicari dan ditemukan oleh tim yang tengah memecahkan
masalah serupa. Contoh lainnya adalah dengan membuat repositori kode
bersama yang menjangkau seisi perusahaan agar kode, library, dan
konfigurasi dapat dengan mudah digunakan oleh semua orang.

Melakukan Eksperimen pada Pekerjaan Sehari-hari

Perusahaan manufaktur yang berperforma rendah biasanya melindungi diri

mereka dari segala macam gangguan dan distraksi dalam berbagai cara.
Misalnya, untuk mengurangi risiko adanya mesin yang menganggur (karena
persediaan datang terlambat, persediaan harus dikurangi, dll), manajer
pabrik sering kali memilih untuk menimbun lebih banyak persediaan di setiap
mesinnya. Namun, pada kenyatannya hal semacam ini justru meningkatkan
WIP (work in progress) yang berpotensi memiliki hasil yang tak diinginkan.

Demikian pula, untuk mengurangi risiko adanya mesin yang down (tumbang)
karena kegagalan mesin, manajer pabrik umumnya meningkatkan kapasitas
dengan membeli lebih banyak peralatan, mempekerjakan lebih banyak
orang, atau bahkan menambah ruangan atau lantai baru. Tentu saja semua
opsi ini malah akan menambah biaya.

Akan tetapi, ini akan berbanding terbalik dengan perusahaan manufaktur

yang berkemajuan dan berperforma tinggi. Mereka bisa mencapai hasil yang
sama (atau lebih baik) tanpa melakukan hal-hal yang telah disebutkan di
atas. Manufaktur yang berkemajuan melakukannya dengan meningkatkan
operasional sehari-hari, senantiasa menambahkan beban sedikit demi sedikit
untuk meningkatkan kinerja, serta merekayasa lebih banyak ketahanan ke
dalam sistem mereka.

Mari kita tengok kisah mengenai eksperimen khas di suatu pabrik komponen
otomotif Aisin Seiki Global, yang merupakan salah satu pemasok utama
Toyota. Anggaplah mereka memiliki dua lini produksi, masing-masing mampu
memproduksi seratus unit per hari. Pada hari-hari tertentu, mereka akan
mengirim semua produksi ke satu lini sebagai langkah untuk bereksperimen
dengan cara meningkatkan kapasitas dan mengidentifikasi kerentanan dalam
proses produksi mereka. Mereka pun mengetahui, jika lini pertama
berpotensi gagal (karena kelebihan beban), semua produksi akan
dipindahkan ke lini kedua.

Dengan eksperimen yang bekelanjutan dan konstan dalam pekerjaan sehari-

hari, hasilnya mereka dapat terus meningkatkan kapasitas produksi, bahkan
tanpa perlu menambah peralatan baru atau mempekerjakan lebih banyak
orang. Dengan pola seperti ini, bukan hanya bisa meningkatkan kinerja,
tetapi juga dapat memperkuat ketahanan mesin.

Begitu juga jika diterapkan di dunia IT. Kita bisa melakukan eksperimen yang
sama ke dalam sistem aplikasi dengan berupaya untuk selalu mempercepat
waktu deployment, meningkatkan cakupan test, mengurangi waktu eksekusi
test, dan bahkan dengan merancang ulang jika perlu untuk meningkatkan
keandalan atau mengoptimalkan produktivitas Developer dan IT Operations.

Kita juga bisa melakukan latihan Game Day, di mana sistem dilatih untuk
skenario kegagalan dalam skala besar, seperti mematikan seluruh data
center. Opsi lain, kita bisa “menyuntikkan” error dengan skala yang lebih
besar ke dalam lingkungan production guna memastikan bahwa sistem yang
kita miliki benar-benar tangguh seperti yang diharapkan.

Memperkuat Hubungan Pemimpin dan Pekerja

Secara kaidah, para pemimpin diharapkan bertanggung jawab untuk

menetapkan tujuan, mengalokasikan sumber daya untuk mencapai tujuan
tersebut, dan menetapkan kombinasi insentif yang tepat. Dengan kata lain,
pemimpin harus mengarahkan timnya dengan membuat keputusan yang
tepat.
Namun, ada bukti signifikan yang menunjukkan bahwa kehebatan tim atau
perusahaan tidak dicapai hanya karena para pemimpin yang membuat
keputusan tepat. Sebaliknya, peran pemimpin seharusnya adalah
menciptakan kondisi supaya tim dapat menemukan kehebatan dalam
pekerjaan sehari-hari mereka. Dengan kata lain, menciptakan kehebatan
membutuhkan baik pemimpin maupun pekerja, yang mana masing-masing
saling bergantung satu sama lain.
Hubungan ini diperlukan karena keduanya tidak dapat menyelesaikan
masalah sendirian. Pemimpin tidak cukup dekat dengan ranah pekerjaan
sesungguhnya (yang mana diperlukan untuk menyelesaikan masalah apa
pun), sementara pekerja tidak memiliki konteks perusahaan atau wewenang
yang lebih luas (yang mana diperlukan untuk melakukan perubahan di luar
wilayah kerja mereka).

Pemimpin sebisa mungkin harus meningkatkan nilai-nilai pembelajaran,

pemecahan masalah, dan disiplin kepada para pekerja. Contoh
implementasinya adalah dengan menciptakan tujuan jangka pendek yang
berulang dan menetapkan kondisi target. Misalnya, mempercepat waktu
deployment sebesar 10% dalam dua minggu ke depan.

Dengan menetapkan kondisi target seperti itu, artinya kita secara eksplisit
menyatakan masalah yang ingin dipecahkan, melahirkan hipotesis mengenai
tindakan untuk menyelesaikannya, mengungkap metode untuk menguji
hipotesis tersebut, memunculkan interpretasi terhadap hasil tindakan, dan
menjadikannya sebuah pembelajaran untuk iterasi berikutnya.

Pendekatan pemecahan masalah di mana para pemimpin membantu pekerja

melihat dan memecahkan masalah dalam pekerjaan sehari-hari mereka
adalah inti dari perusahaan yang sukses dalam menerapkan DevOps. Ingat
bahwa kesuksesan implementasi DevOps ditentukan oleh perilaku yang
secara rutin diajarkan kepada semua anggota perusahaan.

Pendekatan semacam ini sangat penting pada proses pengembangan

aplikasi karena dapat memandu tim (Developer dan IT Operations) dalam
melakukan eksperimen untuk memastikan bahwa aplikasi yang dibuat benar-
benar membantu pengguna.

Semoga Anda paham ya mengenai The Third Way. Intinya, prinsip ini
membahas tentang kebutuhan untuk menciptakan kultur belajar di
perusahaan, memungkinkan rasa saling percaya yang tinggi, menerima
bahwa kegagalan akan selalu terjadi kapan pun dan di mana pun, dan
menciptakan sistem kerja yang aman.

Meskipun memupuk kultur untuk belajar dan bereksperimen terus-menerus

adalah prinsip dari The Third Way, hal itu juga terjalin ke dalam The First
Way dan The Second Way. Dengan kata lain, meningkatkan alur kerja dan
umpan balik pun memerlukan pendekatan iteratif yang mencakup
pemahaman terhadap target yang ingin dicapai, identifikasi apa saja yang
akan membantu kita dalam mencapainya, merancang dan melakukan
eksperimen, serta mengevaluasi hasilnya.

Tak hanya mendatangkan kinerja yang lebih baik, tetapi juga pengoptimalan
ketahanan pada sistem, kepuasan kerja yang lebih tinggi pada pegawai, dan
peningkatan kemampuan beradaptasi pada perusahaan.
Rangkuman Prinsip-Prinsip DevOps

Pengantar The Three Ways: Prinsip-Prinsip yang Mendasari DevOps

Ketahuilah, sebelum bisa mengimplementasikan DevOps dengan baik, ada

prinsip-prinsip DevOps yang perlu diketahui supaya kelak Anda bisa
membawa perusahaan ke level yang lebih tinggi dari saat ini.

Terdapat 3 prinsip utama yang akan kita pelajari:

 Prinsip terkait alur kerja, yang mampu mengakselerasi penyelesaian

dan/atau penyerahan pekerjaan dari Developer, ke IT Operations,
hingga ke pengguna aplikasi.
 Prinsip terkait umpan balik, yang memungkinkan perusahaan untuk
menciptakan sistem kerja yang lebih aman dan lebih baik.
 Prinsip terkait proses belajar dan eksperimen yang berkelanjutan, yang
mampu menciptakan kultur yang menumbuhkan dua hal:

o pemahaman bahwa pengulangan dan latihan merupakan syarat

untuk menguasai sesuatu; serta
o kesadaran betapa pentingnya eksperimen yang terus-menerus
guna meningkatkan keterampilan dalam pengambilan risiko dan
sebagai proses belajar baik dari keberhasilan maupun
kegagalan.
Poin-poin di atas disebut dengan The Three Ways, yakni prinsip-prinsip yang
mendasari DevOps. Prinsip-prinsip ini menggambarkan nilai dan filosofi yang
dapat memandu Anda dalam mengimplementasikan dan mempraktikkan
DevOps di perusahaan Anda. Apabila prinsip-prinsip ini tidak diterapkan atau
tidak ada dalam proses pengembangan aplikasi Anda, maka sebenarnya
Anda belum sepenuhnya mengimplementasikan DevOps.

The First Way: Prinsip Terkait Alur Kerja

Dalam bidang IT, terutama yang berkaitan dengan pengembangan aplikasi,

suatu “pekerjaan” umumnya mengalir dari kiri ke kanan, yakni dari
Development hingga Operations (yang mana merupakan area fungsional
antara bisnis dan pelanggan).
Maka dari itu, prinsip DevOps pertama yang akan kita bahas adalah The First
Way, yakni terkait alur kerja. Prinsip ini menjelaskan bahwa kita
membutuhkan alur kerja yang cepat dan lancar dalam proses pengembangan
aplikasi, mulai dari penulisan kode oleh Developer (Development), ke
penyiapan infrastruktur dan proses deploy aplikasi oleh IT Operations
(Operations), hingga akhirnya sampai di gadget pengguna/pelanggan
(Customer) dan terasa manfaat atau nilai dari aplikasi/fitur/pembaruan
perangkat lunak tersebut.

Dalam proses pengembangan aplikasi, ada beberapa cara atau metode

untuk mengoptimalkan alur kerja, yakni dengan membuat pekerjaan kita
menjadi “tampak”, membatasi work in process (tugas yang masih tahap
pengerjaan dan/atau belum terselesaikan), mengurangi skala batch yang
dikerjakan, memangkas jumlah handoff, serta mengidentifikasi dan
memperbaiki constraint.

Intinya, tujuan dari The First Way ini adalah untuk memperbaiki alur kerja
sehingga proses pengembangan aplikasi bisa berlangsung cepat, tetapi tetap
menjaga keandalan infrastruktur dan meningkatkan kualitas aplikasi. Dengan
demikian, pada akhirnya pelanggan pun bisa merasakan fitur atau
pembaruan aplikasi lebih cepat.

The Second Way: Prinsip terkait Umpan Balik

Jika The First Way menjelaskan tentang prinsip yang memungkinkan alur
kerja yang lancar dan cepat dari kiri ke kanan (Development ke Operations),
The Second Way ini mendeskripsikan prinsip yang memungkinkan feedback
(umpan balik) yang cepat nan konstan dari kanan ke kiri (Operations ke
Development).

Pada prinsip ini, fokus utamanya adalah untuk meningkatkan jumlah

feedback dan mempercepat proses penyampaian feedback (dari Operations
ke Development) guna mencegah agar masalah tak terulang kembali,
memungkinkan deteksi masalah lebih dini, serta pemulihan infrastruktur lebih
cepat.

Prinsip ini sangat penting untuk kita pahami agar terciptanya sistem kerja
yang lebih aman sebab masalah dapat ditemukan sedini mungkin dan
diperbaiki lebih cepat sehingga kita terhindar dari kegagalan saat aplikasi
sudah di-deploy ke production a.k.a dirilis ke publik.
Nah, salah satu cara terbaik untuk mencapainya adalah dengan memiliki
praktik seperti continuous integration atau continuous deployment (akan kita
pelajari nanti) yang dipadukan bersama dengan rangkaian automated
test (pengujian otomatis) yang cepat. Dengan mempraktikkan hal-hal
ini, feedback (umpan balik) bisa segera tersampaikan dengan cepat ke
Developer dan segera diperbaiki.

The Third Way: Prinsip terkait Proses Belajar dan Eksperimen yang
Berkelanjutan

Pembahasan yang ketiga adalah The Third Way, yakni prinsip terkait proses
belajar dan eksperimen yang berkelanjutan. Prinsip ini menjelaskan tentang
cara memupuk kultur untuk mendorong proses belajar dan eksperimen yang
berkelanjutan. Selain itu, prinsip ini juga membenamkan pemahaman bahwa
cara untuk menguasai sesuatu adalah melalui pengulangan dan berlatih
terus-menerus.

Tentu kita semua tahu bahwasanya eksperimen yang dilakukan terus-

menerus bukanlah hal yang mudah untuk dilestarikan sebab membutuhkan
keberanian dalam pengambilan risiko dan kelapangan hati dalam belajar
(baik dari jika berhasil maupun gagal).

Proses pengambilan risiko biasanya adalah sesuatu yang sebisa mungkin

dihindari oleh bisnis. Namun sebaliknya, justru eksperimen dan pengambilan
risiko adalah hal yang bagus bagi IT karena memungkinkan kita untuk
senantiasa meningkatkan sistem kerja.

Proses eksperimen ini sering kali mengharuskan tim untuk berani melakukan
hal-hal di luar kebiasaan mereka selama ini. Ini merupakan hal yang bagus.
Pasalnya, ketika terjadi kesalahan atau kegagalan, tim bisa memperbaikinya
dan belajar dari kesalahan/kegagalan tersebut.

Dengan begitu, ke depannya tim bisa lebih cekatan dalam mengembangkan

aplikasi dan terhindar dari kegagalan yang berulang. Pun, bila seandainya
terjadi kesalahan yang tak diinginkan, tim akan mengerti apa yang harus
dilakukan dan memitigasi agar kegagalan tersebut tidak terulang kembali.

Jika kita mampu menerapkan The First Way dan The Second Way, kelak kita
akan lebih berani dalam mengambil risiko. Sebabnya, kita tahu bahwa
risikonya takkan terlalu besar (mengingat kita memiliki skala batch pekerjaan
yang kecil) dan akan mendapatkan feedback yang cepat mengenai pekerjaan
yang kita lakukan.

Apabila kita sudah terbiasa melakukan eksperimen dan belajar dari

kesalahan, maka akan tercipta kultur untuk selalu ingin berinovasi dan berani
dalam mengambil risiko.
Pengantar CALMS Framework
Setelah melahap asupan materi Pengenalan DevOps dan Prinsip-Prinsip
DevOps, kini mungkin muncul pertanyaan yang mengganjal di benak Anda,
“Lantas, bagaimana kiat-kiat atau cara untuk menerapkan DevOps?”

Oke, jangan tergesa-gesa. Semua akan dibahas secara tuntas. Pastikan

Anda menyimak dengan telaten agar tak ada yang terlewat. Bila perlu,
siapkan camilan dan segelas minuman dingin untuk menemani proses
belajar Anda.

Mari kita mulai singkap materi ini.

Untuk bisa menerapkan DevOps dengan baik di perusahaan, ihwal terkrusial

yang perlu Anda lakukan adalah memahami metodologi DevOps. Dengan
menguasainya, niscaya Anda dapat meningkatkan kolaborasi antar tim di
perusahaan melalui aktivitas yang berlangsung pada siklus hidup aplikasi,
mulai dari desain produk, proses pengembangan aplikasi, hingga operasional
produksi (a.k.a rilis ke pasar dan dinikmati pengguna).

Seperti yang kita tahu, DevOps bertujuan untuk menyatukan orang-orang

untuk bekerja sama dan menghilangkan hambatan sehingga mereka dapat
mencapai tujuan secara efisien. Nah, modul ini akan menyelami lebih dalam
mengenai metodologi yang dipakai untuk mengadopsi DevOps menggunakan
suatu framework alias kerangka kerja yang bernama CALMS sebagai acuan.

CALMS merupakan framework untuk menilai apakah suatu perusahaan atau

organisasi siap mengadopsi DevOps, serta mengukur bagaimana kemajuan
perusahaan dalam transformasi atau proses penerapan DevOps mereka [3].

Perlu Anda ketahui bahwa akronim ini diciptakan oleh Jez Humble–salah
satu penulis “The DevOps Handbook”--yang merupakan singkatan dari
Culture, Automation, Lean, Measurement, dan Sharing.
Mari kita mulai dari yang pertama, yakni Culture.
CALMS Framework: Culture
Transformasi dari pengembangan aplikasi tradisional ke DevOps tentunya
akan menciptakan kultur atau budaya yang baru, yakni transparansi dan
kolaborasi yang efektif untuk meraih tujuan bersama.

Saat ini mungkin Anda memiliki praktik dan tools yang mendukung
penerapan DevOps. Namun, jangan dulu jemawa. Agar pengadopsian
DevOps berhasil, orang-orang dalam perusahaan Anda haruslah mempunyai
pola pikir atau mindset yang baik nan tepat agar mampu memelihara kultur
DevOps. Kultur dalam DevOps selalu mengedepankan orang (people)
ketimbang praktik (practice atau process) dan alat (tools). Percayalah, semua
praktik dan tools yang Anda miliki takkan berguna kecuali jika semua orang
bersatu dan bekerja sama.

Kami mengerti, transformasi menuju DevOps bukanlah proses yang mudah

karena ia merupakan perubahan kultur, banyak hal yang akan berubah. Oleh
karena itu, Anda harus benar-benar memahami kultur DevOps secara
menyeluruh untuk bisa menerapkannya. Ingatlah bahwa yang mesti kita kejar
bukanlah kesempurnaan, melainkan progres yang bertahap. Tak perlu
menunggu untuk benar-benar mampu menerapkan DevOps secara
sempurna, kita bisa mengimplementasikannya secara perlahan dan iteratif.

Ada beberapa hal yang perlu Anda pelajari dan terapkan di perusahaan
sebelum benar-benar mengadopsi DevOps, seperti membangun lingkungan
yang kolaboratif, fokus pada kebutuhan pengguna, dan menyertakan
keamanan di setiap fase.

Mari kita bahas lebih lanjut

 Membangun lingkungan yang kolaboratif
 Kolaborasi merupakan hal terpenting yang perlu diperhatikan saat
mengimplementasikan DevOps di perusahaan. Baik Developer maupun
IT Operations, keduanya memiliki perangkat lunak, kepentingan, dan
tujuannya sendiri-sendiri. Ini bukanlah hal yang baik karena akan
menciptakan gap atau kerenggangan di antara mereka.

Oleh karenanya, DevOps perlu hadir agar mereka bisa bersatu dan
saling bekerja sama. Sebagai contoh, Developer bersama IT
Operations mesti bergandeng tangan dalam membangun aplikasi.
Untuk mewujudkannya, pertama mereka perlu saling berbagi
pengetahuan. Misalnya, Developer bercerita mengenai bagaimana
mereka menulis kode dan IT Operations merawi tentang cara mereka
menstabilkan infrastruktur.

Dengan begitu, ketika Developer menulis kode, mereka juga akan

memikirkan soal keamanan, arsitektur, dan kestabilan infrastruktur.
Demikian pula dengan IT Operations, saat mengonfigurasi server,
mereka akan mempertimbangkan banyak hal agar bisa menyesuaikan
dengan kebutuhan Developer.

Developer dan IT Operations pun bisa bersinergi dalam membangun

suatu tools yang bisa memudahkan pekerjaan keduanya, misal
membangun DevOps Pipeline (CI/CD Pipeline). Kita akan pelajari soal
itu lebih lanjut di modul berikut.

Kolaborasi ini pada akhirnya dapat mengoptimalkan produktivitas dari

sisi Developer sekaligus menjaga keandalan dari sisi IT Operations.
Keduanya pun harus belajar dari pengalaman satu sama lain,
mendengarkan concern (kekhawatiran) dari perspektif masing-masing,
dan merampingkan proses pengembangan aplikasi (dari awal hingga
akhir) untuk menggapai tujuan bersama, yakni deliver (menyajikan)
aplikasi yang komprehensif dan andal dengan cepat.

Selain itu, kolaborasi juga akan mewujudkan kultur saling percaya dan
menghargai satu sama lain, serta mentransfer pengetahuan dan best
practice (praktik terbaik) ke seluruh tim dan perusahaan.
 Fokus pada kebutuhan pengguna
Mindset yang mengutamakan pengguna adalah faktor utama dalam
mendorong pengembangan aplikasi. Sebagai contoh, dengan feedback
loop (umpan balik yang berkelanjutan), tim terkait (Developer dan IT
Operations) bisa tetap terhubung dengan pengguna untuk
 mengembangkan aplikasi sesuai kebutuhan pasar.

Hal tersebut bisa terpenuhi sebab proses yang sederhana dan

automasi sehingga dapat menyajikan pembaruan yang pengguna
butuhkan secara lebih cepat. Pada akhirnya, ini bisa menjaga
kepuasan pelanggan tetap tinggi, yang mana merupakan tujuan
bersama dari semua pihak yang terlibat dalam proses pengembangan
aplikasi.

 Menyertakan keamanan di setiap fase

Selain kedua poin di atas, keamanan juga menjadi hal yang penting
dalam penerapan DevOps. Aspek keamanan harus diimplementasikan
di setiap fase dalam siklus hidup aplikasi, baik saat masih dalam
proses coding maupun selepas rilis ke pasaran.

Karena keamanan merupakan hal yang krusial, Anda mesti sedini

mungkin mengedukasi tim Developer dan IT Operations untuk
menanamkan aspek keamanan dalam pola kerja mereka. Sebagai
contoh:

o Menyertakan security testing (pengujian keamanan) untuk

memindai access key yang tersemat langsung di source code.
o Memeriksa apakah ada port aplikasi yang terbuka tanpa sengaja.
o Membuat abuse case untuk mengetahui apa saja kerentanan
yang dimiliki oleh aplikasi.
o Membangun komunikasi API yang aman.
Nah, dengan cara ini, Anda dapat mengidentifikasi dan segera
membereskan potensi kerentanan keamanan sebelum nantinya menjadi
masalah besar.

Oke, itulah hal-hal yang perlu Anda pahami terkait poin Culture dalam
CALMS Framework. Intinya, setiap tim harus saling berkomunikasi,
berkolaborasi, dan bekerja sama sehingga kebutuhan pengguna pun dapat
tercapai.
CALMS Framework: Automation
Developer dan IT Operations kerap kali berjibaku dengan tugas-tugas yang
repetitif dan manual. Misalnya, Developer merencanakan aplikasi (plan),
menulis kode (code), mengemasnya (build), dan melakukan pengujian (test).
Sementara itu, IT Operations merilis aplikasi (release), menggelar aplikasi
(deploy), serta mengoperasikan (operate) dan memantau (monitor)
infrastruktur yang mendasari aplikasi tersebut.
Nah, dengan menerapkan DevOps, tugas-tugas repetitif dan manual tersebut
dapat diotomatiskan sehingga memungkinkan tim (baik Developer maupun IT
Operations) untuk fokus menciptakan inovasi.

Automasi akan menjadikan proses pengembangan (development), pengujian

(testing), dan penggelaran (deployment) menjadi cepat. Namun, untuk
mewujudkan hal itu, Anda perlu mengidentifikasi sekiranya di bagian mana
saja proses automasi bisa diterapkan. Beberapa contoh proses yang bisa
diautomasi, antara lain:

 integrasi kode (code integration),

 reviu kode (code review),
 pengujian (testing),
 keamanan (security),
 penggelaran (deployment), dan
 pemantauan (monitoring).

Tentunya, semua proses automasi tersebut haruslah diterapkan

menggunakan tools atau layanan yang tepat. Sebagai contoh, Infrastructure
as Code (nanti kita bahas) dapat digunakan untuk
membuat environment (sebuah sistem yang berisi hardware dan software
untuk menjalankan aplikasi) yang sudah ditentukan sebelumnya.
Environment tersebut pun bisa kita versikan sehingga konsisten dan dapat di-
deploy berulang kali.
CALMS Framework: Lean
Komponen penting lain dari CALMS Framework ialah Lean. Dalam
implementasi DevOps, tim Developer perlu menerapkan prinsip lean guna
menghilangkan inefisiensi proses dan mengoptimalkan nilai kerja, seperti
meminimalkan WIP (tugas yang masih dalam tahap pengerjaan dan/atau
belum terselesaikan), menjadikan pekerjaan kita transparan, mengeliminasi
kerumitan saat proses penyerahan kode ke IT Operations, dan mengurangi
waktu tunggu saat berpindah dari satu fase ke fase lainnya (misal dari
penulisan kode ke pengujian).

Aplikasi tidak lagi dikembangkan sebagai satu sistem berarsitektur monolitik.

Sebaliknya, arsitektur aplikasi dirancang dengan komponen dalam bentuk
kecil, terpisah satu sama lain, tetapi tetap dalam satu kesatuan; yang umum
disebut sebagai arsitektur microservice (kita bahas lebih lanjut nanti).

Dengan cara ini, tim (Developer dan IT Operations) bisa mengembangkan

kode dalam ukuran kecil (per komponen, per fitur, atau per fungsi bisnis) dan
merilisnya dengan tempo sesering mungkin. Ini mengindikasikan bahwa tim
telah mengadopsi proses pengembangan aplikasi yang lebih modern, tidak
lagi kaku. Perusahaan pun bisa menjadi lebih gesit dalam merespons
kebutuhan pengguna dan tujuan bisnis.
Nah, itu dia pembahasan kita kali ini. Jadi, inti dari poin lean adalah
mengubah semua alur kerja yang selama ini dipraktikkan agar dapat berjalan
dengan lebih efisien.
CALMS Framework: Measurement
Dalam menerapkan DevOps, perusahaan mesti mengabdikan diri mereka
untuk benar-benar mengumpulkan data tentang apa pun, mulai dari alur
kerja, proses deployment, pengguna, hingga infrastruktur. Ini diperlukan guna
memahami kemampuan perusahaan saat ini dan mengidentifikasi di bagian
mana perbaikan dapat diterapkan.
Sulit untuk membuktikan apakah upaya perbaikan yang kita lakukan selama
ini berimplikasi dalam peningkatan suatu hal atau tidak. Untungnya, ada
banyak tools dan teknologi untuk mengukur kinerja, seperti berapa banyak
waktu yang dihabiskan pengguna dengan produk kita, apakah postingan blog
yang dibuat menghasilkan penjualan, atau seberapa sering peringatan
penting muncul di sistem log infrastruktur.

Meski bisa mengukur segala hal, tidak berarti kita harus mengukur
semuanya. Berikut adalah beberapa contoh pertanyaan untuk mengukur
kinerja atau proses Anda selama ini.

 Berapa lama waktu yang dibutuhkan dari tahap penulisan kode

hingga deployment?
 Seberapa sering bug atau galat muncul?
 Berapa lama waktu yang dibutuhkan untuk pulih (recover) dari
kegagalan sistem (system failure)?
 Berapa banyak orang yang menggunakan produk Anda saat ini?
 Berapa banyak pengguna yang Anda peroleh atau justru hilang di
minggu ini?

Semua data-data ini akan menarik karena kelak membantu perusahaan Anda
untuk membuat keputusan. Salah satunya, Anda bisa menentukan kapan
waktu yang tepat untuk merilis fitur baru atau melakukan rollback (kembali ke
versi aplikasi sebelumnya).

Tentu semua hal itu bisa dicapai dengan proses yang panjang, terus belajar,
dan bereksperimen tanpa henti. Inovasi, pembelajaran, dan mentoring harus
dilibatkan ke dalam proses transformasi DevOps.

Anda pun harus mafhum (paham), persisten berinovasi akan melahirkan

kegagalan sewaktu-waktu. Akan tetapi, tim harus menerima kegagalan
dengan lapang dada dan melihat kegagalan sebagai kesempatan belajar.
CALMS Framework: Sharing
Hal yang tak kalah penting lainnya saat menerapkan DevOps di perusahaan
adalah menciptakan budaya keterbukaan (transparansi informasi dan
komunikasi) dan saling berbagi di dalam dan di antara tim. Dengan begitu,
semua orang akan bisa bekerja sama menuju satu tujuan dan meminimalisir
gesekan yang timbul ketika masalah muncul.
Seperti yang sudah kita ketahui, gesekan yang sudah berlangsung sejak
lama antara tim Developer dan IT Operations sebagian besar disebabkan
oleh kurangnya kebersamaan. Padahal, berbagi tanggung jawab (shared
responsibility) dan meraih kesuksesan bersama dapat menjembatani
kesenjangan di antara mereka.

Selain berbagi pengetahuan (seperti yang dijelaskan pada poin Culture),

Developer dan IT Operations juga mesti berbagi tanggung jawab. Ini berarti
mereka akan memiliki tanggung jawab yang sama untuk aplikasi yang
mereka bangun. Tak ada istilah salah si A atau salah si B. Bila aplikasi
mereka gagal beroperasi, itu berarti ada kesalahan pada prosesnya dan
mereka sama-sama bertanggung jawab untuk mengevaluasi, memperbaiki,
dan mencobanya kembali. Setiap orang harus memikirkan tentang
keamanan, keandalan, dan kecepatan deployment.

Ketahui pula bahwa gagasan utama dari DevOps ialah “Orang yang sama
yang membangun aplikasi, harus terlibat pula dalam proses penyajian
(delivery) ke pelanggan–yakni dengan menjalankannya di
lingkungan production” (you build it, you run it). Dengan demikian, semua
orang akan punya rasa memiliki (ownership) yang lebih, baik terkait dengan
tools maupun peran.

Tentu kita semua akan merasa lebih baik bila ada tongkat ajaib yang bisa
mentransformasi perusahaan agar mampu membumikan DevOps secara
utuh. Sayangnya, transformasi DevOps tidak bisa dilakukan hanya dalam
sekejap mata. Butuh proses yang panjang dengan memadukan filosofi kultur,
praktik, dan tools.

Namun, sekali lagi, memadukan tim Developer dan IT Operations agar

menjadi DevOps akan melahirkan banyak sekali manfaat, seperti

 meningkatkan rasa kepercayaan antara satu sama lain;

 rilis aplikasi menjadi lebih cepat;
 infrastruktur yang menjalankan aplikasi menjadi lebih andal;
 munculnya feedback loop (putaran/lingkaran umpan balik) yang lebih
baik antara tim terkait dan pelanggan.

Intinya, mengadopsi DevOps bukanlah tugas yang kecil. Akan tetapi,

dengan mindset (pola pikir), effort (upaya), dan tools (alat) yang tepat,
sebuah perusahaan dapat menjalani proses transformasi DevOps yang
menghasilkan manfaat secara signifikan.
Rangkuman CALMS Framework

Pengantar CALMS Framework

Untuk bisa menerapkan DevOps dengan baik di perusahaan, ihwal terkrusial

yang perlu Anda lakukan adalah memahami metodologi DevOps. Dengan
menguasainya, niscaya kelak dapat meningkatkan kolaborasi antartim di
perusahaan melalui aktivitas yang berlangsung pada siklus hidup aplikasi,
mulai dari desain produk, proses pengembangan aplikasi, hingga operasional
produksi (a.k.a rilis ke pasar dan dinikmati pengguna).

Seperti yang kita tahu, DevOps bertujuan untuk menyatukan orang-orang

untuk bekerja sama dan menghilangkan hambatan sehingga mereka dapat
mencapai tujuan secara efisien. Nah, modul ini akan menyelami lebih dalam
mengenai metodologi yang dipakai untuk mengadopsi DevOps, yakni seputar
kultur, praktik, dan tools.

Untuk memahami bagaimana cara menerapkan DevOps, kita akan

menggunakan suatu framework alias kerangka kerja yang bernama CALMS
sebagai acuan.

CALMS merupakan framework yang digunakan sebagai sarana untuk menilai

apakah suatu perusahaan atau organisasi siap dalam mengadopsi DevOps,
serta mengukur bagaimana kemajuan perusahaan dalam transformasi atau
proses penerapan DevOps mereka.

CALMS Framework: Culture

Beberapa hal yang perlu Anda pelajari dan terapkan di perusahaan adalah
membangun lingkungan yang kolaboratif, fokus pada kebutuhan pengguna,
dan menyertakan keamanan di setiap fase.

 Membangun lingkungan yang kolaboratif

Kolaborasi merupakan hal terpenting yang perlu diperhatikan saat
mengimplementasikan DevOps di perusahaan. Baik Developer maupun
IT Operations, keduanya memiliki perangkat lunak, kepentingan, dan
tujuannya sendiri-sendiri. Ini bukanlah hal yang baik karena akan
menciptakan gap atau kerenggangan di antara mereka.
 Oleh karenanya, DevOps perlu hadir agar mereka bisa bersatu dan
saling bekerja sama. Kolaborasi ini pada akhirnya dapat
mengoptimalkan produktivitas dari sisi Developer sekaligus menjaga
keandalan dari sisi IT Operations.

 Fokus pada kebutuhan pengguna

Mindset yang mengutamakan pengguna adalah faktor utama dalam
mendorong pengembangan aplikasi. Sebagai contoh, dengan feedback
loop (umpan balik yang berkelanjutan), tim terkait (Developer dan IT
Operations) bisa tetap terhubung dengan pengguna untuk
mengembangkan aplikasi sesuai kebutuhan pasar.

 Menyertakan keamanan di setiap fase

Aspek keamanan harus diimplementasikan di setiap fase dalam siklus
hidup aplikasi, baik saat masih dalam proses coding maupun selepas
rilis ke pasaran.

Musabab ini adalah hal yang krusial, Anda mesti sedini mungkin
mengedukasi tim Developer dan IT Operations untuk menanamkan
aspek keamanan dalam pola kerja mereka.

CALMS Framework: Automation

Dengan menerapkan DevOps, tugas-tugas repetitif dan manual dapat

diotomatiskan sehingga memungkinkan tim (baik Developer maupun IT
Operations) untuk fokus menciptakan inovasi.

Automasi akan menjadikan proses pengembangan (development), pengujian

(testing), dan penggelaran (deployment) menjadi cepat. Namun, untuk
mewujudkan hal itu, Anda perlu mengidentifikasi sekiranya di bagian mana
saja proses automasi bisa diterapkan.

CALMS Framework: Lean

Dalam implementasi DevOps, tim Developer perlu menerapkan

prinsip lean guna menghilangkan inefisiensi proses dan mengoptimalkan nilai
kerja, seperti meminimalkan WIP, menjadikan pekerjaan kita transparan,
mengeliminasi kerumitan saat proses penyerahan kode ke IT Operations,
dan mengurangi waktu tunggu saat berpindah dari satu fase ke fase lainnya
(misal dari penulisan kode ke pengujian).

CALMS Framework: Measurement

Dalam menerapkan DevOps, perusahaan mesti mengabdikan diri mereka

untuk benar-benar mengumpulkan data tentang apa pun, mulai dari alur
kerja, proses deployment, pengguna, hingga infrastruktur. Ini diperlukan guna
memahami kemampuan perusahaan saat ini dan mengidentifikasi di bagian
mana perbaikan dapat diterapkan.

Meski bisa mengukur segala hal, tidak berarti kita harus mengukur
semuanya. Berikut adalah beberapa contoh pertanyaan untuk mengukur
kinerja atau proses Anda selama ini.

 Berapa lama waktu yang dibutuhkan dari tahap penulisan kode hingga
deployment?
 Seberapa sering bug atau galat muncul?
 Berapa lama waktu yang dibutuhkan untuk pulih (recover) dari
kegagalan sistem (system failure)?
 Berapa banyak orang yang menggunakan produk Anda saat ini?
 Berapa banyak pengguna yang Anda peroleh atau justru hilang di
minggu ini?

Semua data-data ini akan menarik karena kelak membantu perusahaan Anda
untuk membuat keputusan. Salah satunya, Anda bisa menentukan kapan
waktu yang tepat untuk merilis fitur baru atau melakukan rollback (kembali ke
versi aplikasi sebelumnya).

CALMS Framework: Sharing

Hal yang tak kalah penting lainnya saat menerapkan DevOps di perusahaan
adalah dengan menciptakan budaya keterbukaan (transparansi informasi dan
komunikasi) dan saling berbagi di dalam dan di antara tim. Dengan begitu,
semua orang akan bisa bekerja sama menuju satu tujuan dan meminimalisir
gesekan yang timbul ketika masalah muncul.
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 AWS

Microsoft Teams
Slack
Amazon Ch
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 AWS C

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.

Selain itu, kita juga bisa menggunakan AWS Cloud9 untuk

 mem-push (mengunggah) perubahan atau penambahan kode
ke dalam AWS CodeCommit repository (nanti kita bahas).

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 (p
 enyesuaian 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

 Umum AWS

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!
Rangkuman Praktik DevOps

Pengantar Praktik DevOps

Kita sudah membedah secara tuntas mengenai metodologi DevOps
melalui CALMS Framework. Kini kita akan menyambangi materi lain
mengenai bagaimana sebenarnya DevOps dipraktikkan supaya
Anda mendapat gambaran dengan lebih jelas.

Anda harus paham terlebih dahulu bahwa poin-poin yang tadi kita
bahas pada modul CALMS Framework akan mengarah pada praktik
DevOps yang merampingkan dan meningkatkan siklus
pengembangan aplikasi agar bisa menyajikan update (pembaruan)
lebih sering secara andal seraya menjaga stabilitas infrastruktur
(seperti server).

Ini pada akhirnya berujung pada dua hal praktis nan penting, yakni
DevOps pipeline dan DevOps tools. Kita akan bahas ini lebih
mendalam di submodul berikutnya. Yuk, lanjut!

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.

Mari kita bedah setiap tahapan pada DevOps Pipeline 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. Selepas kode siap,
Developer pun 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. Usai semua proses build 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. Setelah semua
pengujian berhasil lolos, tahapan selanjutnya pun dimulai.
 Release
Di fase ini, artifact yang telah lolos pengujian kemudian
dikemas/dibungkus dengan nomor versi (version number)
tertentu sebelum nanti akhirnya di-deploy.
 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
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.
Jika terjadi kegagalan di salah satu tahapan, proses yang tengah
dilakukan akan dihentikan sehingga tak bisa lanjut ke fase
berikutnya.

Selain itu, saat kita belajar tentang DevOps pipeline atau CI/CD
pipeline, maka akan erat kaitannya pula dengan istilah-istilah
seperti Continuous Integration, Continuous Delivery, dan
Continuous Deployment. Apa sih perbedaan mendasar di antara
ketiganya?

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), setelah itu proses build
dan test secara otomatis pun dijalankan.
  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.

 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
ada.

Jadi, dengan continuous deployment, proses deploy aplikasi ke

lingkungan production berlangsung secara otomatis tanpa ada
persetujuan eksplisit dan intervensi manusia.

DevOps Tools

Dalam mendukung kesuksesan praktik DevOps di suatu

perusahaan, ada beberapa kategori best practice yang perlu kita
perhatikan berikut dengan tools yang sesuai untuk menerapkannya
(akan dibagi antara tools yang bersifat umum dan AWS).

Komunikasi dan Kolaborasi

Berikut adalah beberapa tools yang bisa membantu
mengimplementasikan komunikasi dan kolaborasi antartim di
perusahaan.
  Platform komunikasi dan kolaborasi terpadu
Berikut adalah beberapa contoh platform komunikasi dan
kolaborasi terpadu (dibagi berdasarkan tools umum dan tools
AWS).

Umum AWS

Microsoft Teams
Slack
Amazon Ch
Workplace
Cisco Webex Teams
 Cloud
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.
 IDE
Berikut adalah beberapa contoh IDE yang
mendukung collaboration tool(dibagi berdasarkan tools umum
dan tools AWS).

Umum

Visual Studio dengan fitur Live Share

AWS C
Intellij IDEA dengan fitur Code With Me

CI/CD
Dalam poin CI/CD ini, tools yang digunakan dibagi menjadi
beberapa kategori berdasarkan siklus DevOps pipeline.

 Code
Berikut beberapa contoh version control system yang bisa
Anda pakai (dibagi berdasarkan tools umum dan tools AWS).

Version Control System

Umum AWS
GitHub
GitLab AWS CodeCommit
BitBucket
 Build
Berikut beberapa contoh tools yang digunakan pada proses
build (dibagi berdasarkan tools umum dan tools AWS).

Build Tools

Umum AWS
Jenkins
Travis CI AWS CodeBuild
CircleCI
 Test
Tahapan test ini sebenarnya tergantung. Apabila sekadar unit
test, maka itu 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 dan mengintegrasikannya dengan AWS.

 Release
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).

Container Image Registry tools

Umum AWS
Docker Hub Amazon ECR
 Deploy
Berikut adalah beberapa contoh tools yang bisa digunakan
untuk deploy aplikasi (dibagi berdasarkan tools umum dan
tools AWS).
 Deployment Tools

Umum AWS
Heroku AWS CodeDeploy
Netlify AWS Elastic Beanstalk
GitHub Pages

 Monitor
Berikut adalah beberapa contoh tools yang bisa digunakan
untuk memantau aplikasi (dibagi berdasarkan tools umum dan
tools AWS).

Monitoring Tools

Umum AWS
Prometheus AWS X-Ray
Elastic Stack Amazon CloudWatch
Dynatrace

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 dalam
proses pengembangan aplikasi.

Infrastructure as Code
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 perlu
mengonfigurasinya secara manual.

Berikut adalah contoh tools yang bisa digunakan untuk

 kategori infrastructure automation (dibagi berdasarkan tools
umum dan tools AWS).

Infrastructure automation tools

Umum AWS
Terraform AWS CloudFormation
 Configuration management
Berikut adalah beberapa contoh tools yang bisa digunakan
pada kategori configuration management (dibagi berdasarkan
tools umum dan tools AWS).

Configuration management tools

Umum AWS
Chef
Puppet AWS OpsWorks
Ansible

Arsitektur Microservices
Ketika berbicara tentang microservice, akan ada dua topik hangat
yang perlu kita bahas, yakni container dan serverless.

 Container
Berikut adalah beberapa contoh tools yang bisa digunakan
terkait container orchestration tools (dibagi berdasarkan tools
umum dan tools AWS).

Container Orchestration tools

Umum AWS
Kubernetes Amazon EKS
OpenShift Amazon ECS
Nomad

 Serverless
Berikut adalah beberapa contoh tools yang bisa digunakan
terkait serverless function as a service (dibagi berdasarkan
tools umum dan tools AWS).

Serverless Function as a Service tools

Umum AWS
Serverless AWS Lambda
 Serverless Function as a Service tools
OpenFaaS
OpenWhisk

Monitoring dan Logging

Berikut adalah beberapa contoh tools yang bisa digunakan terkait
monitoring dan logging (dibagi berdasarkan tools umum dan tools
AWS).

Monitoring and Logging tools

Umum AWS
Prometheus AWS X-Ray
Elastic Stack Amazon CloudWatch
Dynatrace

Pengantar Kisah Implementasi DevOps

Selamat datang di modul terakhir dalam kelas ini. Sedari awal kita
sudah belajar banyak hal tentang DevOps, mulai dari Pengenalan
DevOps, Prinsip-Prinsip DevOps, hingga Metodologi DevOps.
Semuanya kita kupas secara tuntas sehingga kini Anda sudah
memahami seluk-beluk DevOps.

Mungkin Anda masih memiliki pertanyaan pemungkas yang sedari

modul pertama ingin ditanyakan, “Apakah ada contoh implementasi
DevOps di suatu perusahaan ternama yang bisa kita jadikan
contoh?”

Yap, kami mengerti. Mungkin sebagian dari Anda masih merasa

ragu untuk menerapkan DevOps di perusahaan. Tak apa, itu wajar
bagi siapa pun yang ingin mengimplementasikan DevOps. Kita
pastinya akan merasa cemas ketika menghadapi perubahan.

“Apakah akan berhasil?”

“Apakah ini bisa membuat perusahaan saya menjadi lebih baik?”

“Apakah ini akan berdampak baik ke depannya?”

Meskipun Anda sudah mengetahui manfaat-manfaat menerapkan

DevOps dan tahu bagaimana cara-cara mengimplementasikannya,
pasti pertanyaan-pertanyaan itu masih bersarang di pikiran Anda.
Nah, untuk itu, di modul ini kita akan membedah sebuah kisah
bagaimana perusahaan tersohor nan kondang seperti Amazon
mengimplementasikan DevOps di dalam perusahaannya.

Anda harus tahu bahwa mulanya Amazon pun tidak menerapkan

DevOps. Akan tetapi, lambat laun akhirnya mereka
mentransformasikan struktur perusahaannya agar bisa
mengimplementasikan DevOps.

Amazon merupakan salah satu contoh perusahaan yang awalnya

menggunakan praktik pengembangan aplikasi tradisional dan kini
bermetamorfosis menjadi lebih fleksibel dan efisien dengan
bantuan DevOps.

Penasaran seperti apa kisahnya? Yuk langsung saja kita singkap

submodul berikutnya.
Transformasi DevOps pada Perusahaan Amazon
Saat ini, Amazon mampu mengotomatiskan software
delivery (pengiriman/penyajian perangkat lunak) hingga mencapai
lebih dari 150 juta deployment (penggelaran) dalam setahun. Ini
berkat Amazon telah menerapkan kultur, praktik, dan tools DevOps
dalam perusahaan mereka. Ribuan tim secara independen bekerja
secara paralel demi menghadirkan perangkat lunak yang cepat,
aman, lagi andal. Namun, Anda harus tahu bahwa pencapaian ini
tidak datang begitu saja, terdapat perjuangan yang panjang di
baliknya.

Pada awal 2000-an, situs retail [Link] merupakan website

yang memiliki arsitektur monolitik dan dikembangkan melalui
praktik pengembangan aplikasi tradisional. Selain itu, struktur
perusahaan Amazon pun bersifat hierarkis, yakni terdiri dari tim
Development (Developer), Testing (IT Tester atau QA), dan
Operational (IT Operations) yang masing-masing terpisah dan
tertutup satu sama lain (siloed team). Ditambah, aplikasi (dalam hal
ini website [Link]) di-deploy sebagai satu unit.
Praktik pengembangan aplikasi yang dilakukan oleh Amazon
sesungguhnya banyak masalah yang dapat menyulitkan mereka
sendiri, seperti

1. antarkomponen aplikasi saling bergantung satu sama lain,

2. proses QA (Quality Assurance) dilakukan secara manual,
3. proses deployment berlangsung pelik nan rumit,
4. dan lain-lain.

Untungnya, Amazon segera menyadari bahwa proses

pengembangan aplikasi mereka terhambat oleh arsitektur aplikasi
dan struktur perusahaan. Pada akhirnya menjadi jelas bahwa ada
sesuatu yang perlu diubah dan diperbaiki guna meningkatkan
kecepatan pengembangan aplikasi dan kelancaran proses
deployment. Dengan demikian, Amazon bisa terbebas dari urusan
operasional aplikasi yang terus-menerus menghantui mereka dan
lebih fokus pada kebutuhan pengguna. Tentu saja ini tidak terjadi
dalam semalam, melainkan berproses secara bertahap.

Amazon membentuk tim kecil yang lintas fungsional dan terdiri dari
8-10 orang bernama two-pizza teams (tim dua pizza). Namanya
unik, bukan? Filosofi di balik penamaan two-pizza teams ini ialah
Amazon mencoba untuk membuat tim yang tidak lebih besar dari
yang bisa diberi makan oleh dua pizza. Pasalnya, semakin kecil tim,
semakin baik kolaborasi akan tercipta. Kolaborasi yang baik tentu
akan menghadirkan suasana yang mendukung untuk proses
pengembangan aplikasi yang lebih cepat.

Selain itu, Amazon mengubah arsitektur aplikasi menjadi service-

oriented (berorientasi layanan). Setiap service (layanan) umumnya
berisi satu fungsionalitas bisnis, misal Product Catalog service,
Shopping Cart service, atau Order service.

Two-pizza teams ini pun diselaraskan dengan beberapa service

tersebut. Mereka diberi kepemilikan sehingga dapat
mengembangkan setiap service secara mandiri.

Dengan cara ini, setiap tim secara konsisten dapat menemukan dan
mengeliminasi redundansi dalam proses mereka yang akhirnya
mampu mempercepat proses pengembangan aplikasi. Ini
merupakan suatu kemajuan.

Akan tetapi, Amazon tahu bahwa mereka bisa berbuat lebih

banyak. Mereka menyadari bahwa proses yang manual, penyerahan
kode dari satu orang ke orang lainnya, dan siklus perilisan aplikasi
yang mereka pakai masih menyebabkan delay (penundaan).

Amazon ingin menghadirkan aplikasi, penambahan fitur, dan

pembaruan dengan lebih cepat ke pengguna. Alhasil, arsitektur
monolitik yang sebagian masih mereka gunakan selama ini benar-
benar diubah menjadi service-oriented sepenuhnya dan kemudian
segera menjadi microservice.

Tak hanya itu, Amazon juga membangun dan mengadopsi tools

untuk memvisualisasikan dan mengotomatisasi proses perilisan
perangkat lunak mereka, mulai dari pengecekan kode, pengujian,
hingga deploy ke production. Yakinlah, pemantauan selama proses
pengembangan hingga setelah rilis akan memberikan dampak baik
kepada tim, salah satunya berupa kepercayaan diri. Segera, tim
akan sanggup merilis perangkat lunak secara independen, lebih
cepat, dan andal.

Nah, inilah kisah transformasi DevOps yang terjadi pada

perusahaan Amazon. Dari kisah ini, pada dasarnya Amazon
menginginkan agility (ketangkasan), dan transformasi menjadi
landasan mereka untuk mengadopsi DevOps.

Lagi dan lagi kami tekankan, transformasi DevOps tidak terjadi

hanya dalam semalam, melainkan melalui proses peningkatan kecil
yang bertahap dalam jangka waktu panjang. Anda pun harus
mempertimbangkan bahwa sejatinya transformasi DevOps akan
melahirkan dampak di seluruh perusahaan. Ia akan mengubah cara
setiap orang di perusahaan berpikir tentang pekerjaan mereka.
Akan ada perubahaan struktur perusahaan, pergantian atau
penggabungan tim, atau mungkin pengadopsian tools yang selama
ini tidak mereka temui sebelumnya.

Di Amazon, struktur tim berubah yang semula saling terpisah dan

tertutup (silo) beralih menjadi tim-tim kecil yang lintas fungsi.
Dengan begitu, setiap anggota tim akan menyadari bagaimana
upaya mereka dapat mempengaruhi tujuan tim secara
keseluruhan.

Tim yang kecil, kepemilikan, perencanaan yang menyeluruh,

komunikasi, kolaborasi, automasi, peningkatan yang berkelanjutan
melalui inovasi, serta pemantauan telah menjadi kekuatan yang
menjadi pendorong penerapan kultur DevOps di Amazon.

Ini kisah Amazon, bagaimana kisahmu? Tulis di forum diskusi yuk.

Hikmah dari Transformasi DevOps pada Perusahaan Amazon
Anda telah mengetahui bagaimana kisah transformasi DevOps pada
perusahaan Amazon. Dalam perjalanannya, ada begitu banyak
tantangan, penuh rintangan, dan waktu yang panjang hingga
akhirnya kini Amazon bisa memetik buah manis dari DevOps.
Lantas, hikmah apa yang bisa kita petik dari sana?

Amazon–dan tentu perusahaan-perusahaan lain–telah beralih dari

praktik pengembangan aplikasi tradisional yang telah mereka
bangun dan lakukan bertahun-tahun ke kultur, praktik, dan tools
DevOps. Mesti itu bukan perjalanan yang mudah dan singkat. Perlu
upaya dan perjuangan serempak agar perusahaan mampu
mengimplementasikan DevOps dan akhirnya mengenyam manfaat-
manfaat yang semula tak dirasa.

Amazon telah membuktikan bahwa dengan DevOps, perusahaan

mereka dapat berinovasi, menghadirkan produk, dan tumbuh lebih
cepat daripada perusahaan lain yang menggunakan praktik
pengembangan aplikasi tradisional. Dengan cara ini, Amazon dapat
melayani pelanggan mereka dengan lebih baik dan bersaing lebih
efektif di pasar.

Namun, terlepas dari semua itu, ada satu pertanyaan yang mungkin
masih bergelayut di kepala Anda, “Pasti akan terjadi banyak
perubahan di perusahaan saya, lantas dari mana saya harus
memulai semua ini?”

Sepakat, memang tidak mudah untuk melakukan perubahan dan

jelas tak ada proses yang instan. Maka dari itu, praktik terbaik yang
perlu Anda lakukan adalah dengan mengambil langkah kecil
terlebih dahulu. Tak perlu terburu-buru dan tak usah terlalu
berambisi ingin segera mengimplementasikan DevOps.

Sabar. Nikmati prosesnya.

Lihat dan amati kembali perusahaan Anda lebih dalam. Mungkin

Anda sebenarnya sudah siap secara kultur dan hanya perlu
menerapkan praktik dan tools DevOps saja. Atau sebaliknya, bisa
jadi Anda sama sekali belum siap secara kultur, yang artinya Anda
harus mengevaluasi dan mulai mendorong terciptanya kultur
DevOps ini.

Entah itu dengan menggabungkan tim Developer dan IT Operations

dalam satu ruangan kerja dengan harapan terjadi komunikasi yang
intens, mereorganisasi dua tim tersebut agar mereka merasa dekat,
mengatur pertemuan supaya mereka bisa saling bertukar pikiran,
atau bahkan mengadopsi sebuah tools komunikasi biar mereka bisa
tetap berkomunikasi kapan pun dan di mana pun. Semuanya
tergantung keputusan perusahaan Anda.

Akan tetapi, bila perusahaan Anda ternyata sudah siap segalanya.

Mungkin Anda bisa mulai dengan membuat CI/CD Pipeline, misalnya
menggunakan layanan dari AWS seperti AWS CodePipeline (sudah
kita bahas sebelumnya).

Intinya, apa pun tools yang Anda pakai, harus senantiasa membawa
perubahan yang efektif dan dampak baik bagi perusahaan. Sebab,
sejatinya DevOps bukanlah sekadar tools belaka, melainkan
gabungan dari kultur, praktik, dan tools secara bersamaan.

Selamat berjuang!

Rangkuman Kisah Implementasi DevOps

Pengantar Kisah Implementasi DevOps

Kita sudah belajar banyak hal soal DevOps, mulai dari Pengenalan
DevOps, Prinsip-Prinsip DevOps, hingga Metodologi DevOps.

Namun, mungkin Anda punya pertanyaan pemungkas terkait

DevOps yang sudah bergentayangan di benak Anda, “Apakah ada
contoh bagaimana implementasi DevOps di suatu perusahaan
ternama yang bisa kita jadikan contoh?”

Meskipun Anda sudah mengetahui manfaat-manfaat menerapkan

DevOps dan tahu bagaimana cara-cara mengimplementasikannya,
pasti pertanyaan itu masih bersarang di pikiran Anda. Nah, untuk
itu, di modul ini kita akan membedah sebuah kisah bagaimana
perusahaan tersohor nan kondang seperti Amazon
mengimplementasikan DevOps di dalam perusahaannya.

Anda harus tahu bahwa mulanya Amazon pun tidak menerapkan

DevOps. Akan tetapi, lambat laun akhirnya mereka
mentransformasikan struktur perusahaannya agar bisa
mengimplementasikan DevOps.

Amazon merupakan salah satu contoh perusahaan yang awalnya

menggunakan praktik pengembangan aplikasi tradisional dan kini
bermetamorfosis menjadi lebih fleksibel dan efisien dengan
bantuan DevOps.

Transformasi DevOps pada Perusahaan Amazon

Pada awal 2000-an, situs retail [Link] merupakan website

yang memiliki arsitektur monolitik dan dikembangkan melalui
praktik pengembangan aplikasi tradisional. Selain itu, struktur
perusahaan Amazon pun bersifat hierarkis, yakni terdiri dari tim
Development (Developer), Testing (IT Tester atau QA), dan
Operational (IT Operations) yang masing-masing terpisah dan
tertutup satu sama lain (siloed team). Ditambah, aplikasi (dalam hal
ini website [Link]) di-deploy sebagai satu unit.
Praktik pengembangan aplikasi yang dilakukan oleh Amazon
sesungguhnya banyak masalah yang dapat menyulitkan mereka
sendiri, seperti:

1. antarkomponen aplikasi saling bergantung satu sama lain,

2. proses QA (Quality Assurance) dilakukan secara manual,
3. proses deployment berlangsung pelik nan rumit,
4. dan lain-lain.
Untungnya, Amazon segera menyadari bahwa proses
pengembangan aplikasi mereka terhambat oleh arsitektur aplikasi
dan struktur perusahaan. Pada akhirnya menjadi jelas bahwa ada
sesuatu yang perlu diubah dan diperbaiki guna meningkatkan
kecepatan pengembangan aplikasi dan kelancaran proses
deployment. Dengan demikian, Amazon bisa terbebas dari urusan
operasional aplikasi yang terus-menerus menghantui mereka dan
lebih fokus pada kebutuhan pengguna. Tentu saja ini tidak terjadi
dalam semalam, melainkan berproses secara bertahap.

Amazon membentuk tim kecil yang lintas fungsional dan terdiri dari
8-10 orang bernama two-pizza teams (tim dua pizza). Unik ya
namanya? Filosofi di balik penamaan two-pizza teams ini ialah
Amazon mencoba untuk membuat tim yang tidak lebih besar dari
yang bisa diberi makan oleh dua pizza. Pasalnya, semakin kecil tim,
semakin baik kolaborasi akan tercipta. Kolaborasi yang baik tentu
akan menghadirkan suasana yang mendukung untuk proses
pengembangan aplikasi yang lebih cepat.

Selain itu, Amazon mengubah arsitektur aplikasi menjadi service-

oriented (berorientasi layanan). Setiap service (layanan) umumnya
berisi satu fungsionalitas bisnis, misal Product Catalog service,
Shopping Cart service, atau Order service.

Two-pizza teams ini pun diselaraskan dengan beberapa service

tersebut. Mereka diberikan kepemilikan sehingga dapat
mengembangkan setiap service secara mandiri.

Dengan cara ini, setiap tim secara konsisten dapat menemukan dan
mengeliminasi redundansi dalam proses mereka yang akhirnya
mampu mempercepat proses pengembangan aplikasi. Ini
merupakan suatu kemajuan.
Akan tetapi, Amazon tahu bahwa mereka bisa berbuat lebih
banyak. Mereka menyadari bahwa proses yang manual, penyerahan
kode dari satu orang ke orang lainnya, dan siklus perilisan aplikasi
yang mereka pakai masih menyebabkan delay (penundaan).

Amazon ingin menghadirkan aplikasi, penambahan fitur, dan

pembaruan dengan lebih cepat ke pengguna. Alhasil, arsitektur
monolitik yang sebagian masih mereka gunakan selama ini benar-
benar diubah menjadi service-oriented sepenuhnya dan kemudian
segera menjadi microservice.

Tak hanya itu, Amazon juga membangun dan mengadopsi tools

untuk memvisualisasikan dan mengotomatisasi proses perilisan
perangkat lunak mereka, mulai dari pengecekan kode, pengujian,
hingga deploy ke production. Yakinlah, pemantauan selama proses
pengembangan hingga setelah rilis akan memberikan dampak baik
kepada tim, salah satunya berupa kepercayaan diri. Segera, tim
akan sanggup merilis perangkat lunak secara independen, lebih
cepat, dan andal.

Hikmah dari Transformasi DevOps pada Perusahaan Amazon

Amazon–dan tentu perusahaan-perusahaan lain–telah beralih dari

praktik pengembangan aplikasi tradisional yang telah mereka
bangun dan lakukan bertahun-tahun ke kultur, praktik, dan tools
DevOps. Mesti itu bukan perjalanan yang mudah dan singkat. Perlu
upaya dan perjuangan serempak agar perusahaan mampu
mengimplementasikan DevOps dan akhirnya mengenyam manfaat-
manfaat yang semula tak dirasa.

Amazon telah membuktikan bahwa dengan DevOps, perusahaan

mereka dapat berinovasi, menghadirkan produk, dan tumbuh lebih
cepat daripada perusahaan lain yang menggunakan praktik
pengembangan aplikasi tradisional. Dengan cara ini, Amazon dapat
melayani pelanggan mereka dengan lebih baik dan bersaing lebih
efektif di pasar.

Namun, terlepas dari semua itu, ada satu pertanyaan yang mungkin
masih berkutat di kepala Anda, “Pasti akan terjadi banyak
perubahan di perusahaan saya, lantas dari mana saya harus
memulai semua ini?”

Praktik terbaik yang perlu Anda lakukan adalah dengan mengambil

langkah kecil terlebih dahulu.

Lihat dan amati kembali perusahaan Anda lebih dalam. Mungkin

Anda sebenarnya sudah siap secara kultur dan hanya perlu
menerapkan praktik dan tools DevOps saja. Atau sebaliknya, bisa
jadi Anda sama sekali belum siap secara kultur, yang artinya Anda
harus evaluasi dan mulai mendorong terciptanya kultur DevOps ini.

Akan tetapi, bila perusahaan Anda ternyata sudah siap segalanya.

Mungkin Anda bisa mulai dengan membuat CI/CD Pipeline, misal
dengan menggunakan layanan dari AWS seperti AWS CodePipeline
(sudah kita bahas sebelumnya).

Rangkuman Kelas

Pengenalan DevOps

Masalah pada Proses Pengembangan Aplikasi

Kita semua tahu bahwa proses pengembangan aplikasi itu ruwet,

bahkan di beberapa kasus bisa jadi melibatkan banyak sekali pihak.
Tidak hanya dari segi model, ada juga beberapa masalah lain yang
menghantui selama proses pengembangan aplikasi, seperti
arsitektur yang monolitik, proses yang manual, dan struktur tim
yang tertutup pun bisa menjadi bottleneck sehingga menyebabkan
keterlambatan dan ketidakefisienan dalam proses penyajian
aplikasi.

Oke, supaya lebih detail dalam memahami masalah-masalah ini,

mending langsung saja kita bedah satu per satu yuk.

Model Waterfall
Waterfall adalah salah satu dari sekian banyak model pada proses
pengembangan aplikasi (alias SDLC atau Software Development
Life Cycle). Model Waterfall ini merupakan metode kerja yang
menekankan fase-fase yang berurutan dan sistematis. Disebut
waterfall lantaran proses yang terjadi dalam mengembangkan
sebuah perangkat lunak atau aplikasi mengalir satu arah “ke
bawah” bak air terjun.

Pada model waterfall, setiap fase saling bergantung satu sama lain.
Kita tak bisa lanjut ke fase berikutnya sebelum fase yang sedang
dikerjakan saat ini benar-benar selesai digarap. Misalnya, kita tak
bisa melakukan pengujian jika proses coding dari keseluruhan
aplikasi belum beres. Begitu juga kita tak bisa men-deploy aplikasi
jika keseluruhan komponen aplikasi belum lolos fase pengujian.
Begitu seterusnya.

Ketahuilah bahwa proses perpindahan dari satu fase ke fase lainnya

pun memakan waktu yang lama, salah satu penyebabnya adalah
tim yang bertanggung jawab perlu menyesuaikan tools yang
mereka gunakan terlebih dahulu.

Belum lagi jika di tengah-tengah proses pengembangan aplikasi

tetiba ada perubahan kebutuhan, fitur, atau antarmuka; repotlah
jadinya karena harus kembali ke fase awal, yakni penentuan
persyaratan/kebutuhan (requirement).

Arsitektur Monolitik
Apa sih yang dimaksud dengan monolitik itu? Maksudnya, dikatakan
arsitektur monolitik apabila kita menempatkan berbagai komponen
aplikasi di satu unit. Contoh sederhananya adalah ketika kita men-
deploy authentication service (layanan autentikasi), order
service (layanan pemesanan), account service (layanan akun), dll di
satu Back-End server yang sama.
Sebenarnya, arsitektur monolitik bukan berarti buruk sama sekali.
Ia menjadi langkah awal yang bagus bagi Anda yang baru memulai
pengembangan aplikasi agar bisa memahami kompleksitas sistem
dan cakupan setiap komponen lebih baik. Namun, seiring makin
rumitnya sistem yang Anda bangun, makin sulit pula untuk dikelola
bila tetap menerapkan pendekatan monolitik.

Pasalnya, itu berarti semua komponen (seperti authentication

service, order service, account service, dll) saling terikat dan
bergantung satu sama lain. Jika salah satu komponen gagal
beroperasi, kemungkinan besar komponen yang lain akan
terkendala.

Oleh karena itu, apabila Anda memiliki aplikasi yang menggunakan

pendekatan monolitik dan dirasa sudah sangat kompleks sehingga
sulit untuk dikelola, sebaiknya modifikasilah arsitekturnya agar
menerapkan pendekatan microservice.

Proses Manual
Proses yang manual membuat pengembangan aplikasi menjadi
lambat, tidak konsisten, dan rawan kesalahan.

Sebagai contoh, pengaturan dan pengonfigurasian infrastruktur

(seperti server) secara manual merupakan proses yang sangat
memakan waktu. Bagaimana tidak, melakukan proses ini ke
beberapa server yang ada terus-menerus secara manual bisa
menguras tenaga dan menghabiskan waktu hingga berhari-hari.
Ditambah lagi, rentan sekali adanya kemungkinan bahwa satu atau
dua langkah terlewat sehingga pada akhirnya timbul kesalahan
konfigurasi.

Struktur Tim Tertutup

Proses pengembangan aplikasi melibatkan 2 tim penting, yakni
Developer dan IT Operations. Mereka adalah dua tim yang krusial
karena memiliki tujuan yang sama, yakni menyajikan aplikasi yang
komprehensif dan stabil ke pengguna; tetapi sering kali mereka
tertutup satu sama lain dan seakan-akan tercerai. Baik Developer
maupun IT Operations, mereka memiliki prioritas, peralatan, dan
pola kerjanya sendiri-sendiri sehingga acap kali menimbulkan
pergolakan saat mereka tengah bekerja sama.
Di satu sisi, Developer dituntut oleh perusahaan untuk dapat
membuat perangkat lunak, mengembangkan aplikasi, memperbaiki
bug, dan mengerjakan banyak fitur secepat mungkin. Sering kali
yang diukur hanyalah jumlah fitur yang dikerjakan sehingga justru
inilah yang mengakibatkan mereka tidak memperhatikan kualitas
kode.

Di sisi lain, IT Operations dituntut untuk membuat infrastruktur

(seperti server, database, jaringan, dan sejenisnya) yang senantiasa
stabil tanpa down. Nah, masalahnya, salah satu hal yang kerap
membuat infrastruktur tidak stabil adalah perubahan yang terjadi
pada aplikasi yang berjalan di dalamnya. Selain perubahan,
intensitas deploy yang tinggi pun akan memperbesar potensi
terjadinya masalah.

Di sinilah letak masalah antara tim Developer dan IT Operations

berpusat, kedua tim tersebut memiliki peran yang berseberangan
satu sama lain.

Lantas, bagaimana dong cara mengatasi masalah antara Developer

dan IT Operations ini? Bagaimana agar keduanya bisa berkolaborasi
dengan baik? Nah, prakarsa mengenai DevOps pun muncul untuk
menjadi solusi dari problematika ini.

Pengertian DevOps

DevOps adalah kombinasi dari filosofi kultur/budaya, sekumpulan

praktik, dan rangkaian alat (tools) yang dapat meningkatkan
kemampuan organisasi/perusahaan untuk menyajikan (deliver)
aplikasi atau perangkat lunak secara cepat.

Itu artinya, perusahaan mampu mengembangkan dan memperbaiki

produk mereka dengan lebih cepat ketimbang menggunakan model
pengembangan aplikasi dan proses manajemen infrastruktur yang
tradisional, seperti model Waterfall yang kita bahas sebelumnya.
Dengan prosedur yang cepat, memungkinkan perusahaan untuk
melayani pengguna dengan lebih baik dan mampu bersaing secara
lebih efektif di pasar.
Dengan mengimplementasikan DevOps, tim yang sebelumnya
saling tertutup dan terpisah (yakni Developer dan IT Operations)
pada akhirnya mampu bersatu, berkolaborasi, dan berkomunikasi
untuk mengoptimalkan produktivitas. Ucapkan selamat tinggal
pada kekisruhan yang terjadi pada internal perusahaan dan mari
ciptakan suasana yang lebih damai.

Manfaat Penerapan DevOps

Apa pun ukuran dari perusahaan Anda, entah itu startup, medioker,
hingga korporasi sekalipun akan memperoleh manfaat bila
mengadopsi DevOps. Berikut ini adalah beberapa manfaat utama
DevOps.

 Ketangkasan
Menerapkan DevOps dapat membuat perusahaan Anda unggul
secara kompetitif karena sanggup mengantisipasi kebutuhan
pasar, menciptakan inovasi dengan cepat, serta merengkuh
pertumbuhan bisnis yang lebih efisien.
 Proses rilis cepat
DevOps mampu meningkatkan frekuensi rilis aplikasi, fitur,
atau perangkat lunak sehingga Anda dapat berinovasi dan
meningkatkan kualitas produk dengan lebih cepat.
 Keandalan
Saat melakukan pembaruan pada aplikasi atau perubahan
terhadap infrastruktur, pastikan kualitasnya tetap terjaga agar
Anda dapat menyajikan aplikasi yang ciamik lebih cepat dan
andal sehingga pengguna tetap mendapatkan pengalaman
yang positif.
 Skalabilitas
Hadirnya DevOps memungkinkan Anda untuk mengelola dan
mengoperasikan infrastruktur beserta proses pengembangan
aplikasi dalam skala besar. Automasi dan konsistensi dapat
mempermudah Anda dalam mengelola sistem yang kompleks
secara efisien dengan risiko yang lebih rendah.
 Kolaborasi meningkat
Anda bisa membangun tim yang lebih efektif dengan
menerapkan kultur DevOps, yang menekankan nilai-nilai
seperti kepemilikan dan akuntabilitas. Developer dan IT
 Operations akan berkolaborasi dengan erat, berbagi banyak
tanggung jawab, dan memadukan alur kerja mereka. Dengan
ini pada akhirnya akan mengurangi inefisiensi sekaligus
menghemat waktu.
 Keamanan
Jika menerapkan DevOps, bisnis Anda bisa bergerak lebih
cepat sambil mempertahankan akses kontrol dan
menjaga compliance. Anda bisa mengadopsi DevOps tanpa
mengorbankan keamanan, yakni menggunakan compliance
policies (kebijakan compliance) secara otomatis, kontrol akses
yang mendetail, dan teknik manajemen konfigurasi.

Prinsip-Prinsip DevOps

Pengantar The Three Ways: Prinsip-Prinsip yang Mendasari

DevOps

Ketahuilah, sebelum bisa mengimplementasikan DevOps dengan

baik, ada prinsip-prinsip DevOps yang perlu diketahui supaya kelak
Anda bisa membawa perusahaan ke level yang lebih tinggi dari saat
ini.

Terdapat 3 prinsip utama yang akan kita pelajari:

 Prinsip terkait alur kerja, yang mampu mengakselerasi

penyelesaian dan/atau penyerahan pekerjaan dari Developer,
ke IT Operations, hingga ke pengguna aplikasi.
 Prinsip terkait umpan balik, yang memungkinkan perusahaan
untuk menciptakan sistem kerja yang lebih aman dan lebih
baik.
 Prinsip terkait proses belajar dan eksperimen yang
berkelanjutan, yang mampu menciptakan kultur yang
menumbuhkan dua hal:

o pemahaman bahwa pengulangan dan latihan merupakan

syarat untuk menguasai sesuatu; serta
o kesadaran betapa pentingnya eksperimen yang terus-
menerus guna meningkatkan keterampilan dalam
 pengambilan risiko dan sebagai proses belajar baik dari
keberhasilan maupun kegagalan.
Poin-poin di atas disebut dengan The Three Ways, yakni prinsip-
prinsip yang mendasari DevOps. Prinsip-prinsip ini menggambarkan
nilai dan filosofi yang dapat memandu Anda dalam
mengimplementasikan dan mempraktikkan DevOps di perusahaan
Anda. Apabila prinsip-prinsip ini tidak diterapkan atau tidak ada
dalam proses pengembangan aplikasi Anda, maka sebenarnya Anda
belum sepenuhnya mengimplementasikan DevOps.

The First Way: Prinsip Terkait Alur Kerja

Dalam bidang IT, terutama yang berkaitan dengan pengembangan

aplikasi, suatu “pekerjaan” umumnya mengalir dari kiri ke kanan,
yakni dari Development hingga Operations (yang mana merupakan
area fungsional antara bisnis dan pelanggan).

Maka dari itu, prinsip DevOps pertama yang akan kita bahas adalah
The First Way, yakni terkait alur kerja. Prinsip ini menjelaskan
bahwa kita membutuhkan alur kerja yang cepat dan lancar dalam
proses pengembangan aplikasi, mulai dari penulisan kode oleh
Developer (Development), ke penyiapan infrastruktur dan proses
deploy aplikasi oleh IT Operations (Operations), hingga akhirnya
sampai di gadget pengguna/pelanggan (Customer) dan terasa
manfaat atau nilai dari aplikasi/fitur/pembaruan perangkat lunak
tersebut.

Dalam proses pengembangan aplikasi, ada beberapa cara atau

metode untuk mengoptimalkan alur kerja, yakni dengan membuat
pekerjaan kita menjadi “tampak”, membatasi work in
process (tugas yang masih tahap pengerjaan dan/atau belum
terselesaikan), mengurangi skala batch yang dikerjakan,
memangkas jumlah handoff, serta mengidentifikasi dan
memperbaiki constraint.

Intinya, tujuan dari The First Way ini adalah untuk memperbaiki alur
kerja sehingga proses pengembangan aplikasi bisa berlangsung
cepat, tetapi tetap menjaga keandalan infrastruktur dan
meningkatkan kualitas aplikasi. Dengan demikian, pada akhirnya
pelanggan pun bisa merasakan fitur atau pembaruan aplikasi lebih
cepat.

The Second Way: Prinsip terkait Umpan Balik

Jika The First Way menjelaskan tentang prinsip yang

memungkinkan alur kerja yang lancar dan cepat dari kiri ke kanan
(Development ke Operations), The Second Way ini mendeskripsikan
prinsip yang memungkinkan feedback (umpan balik) yang cepat
nan konstan dari kanan ke kiri (Operations ke Development).

Pada prinsip ini, fokus utamanya adalah untuk meningkatkan

jumlah feedback dan mempercepat proses penyampaian feedback
(dari Operations ke Development) guna mencegah agar masalah
tak terulang kembali, memungkinkan deteksi masalah lebih dini,
serta pemulihan infrastruktur lebih cepat.

Prinsip ini sangat penting untuk kita pahami agar terciptanya sistem
kerja yang lebih aman sebab masalah dapat ditemukan sedini
mungkin dan diperbaiki lebih cepat sehingga kita terhindar dari
kegagalan saat aplikasi sudah di-deploy ke production a.k.a dirilis
ke publik.

Nah, salah satu cara terbaik untuk mencapainya adalah dengan

memiliki praktik seperti continuous integration atau continuous
deployment (akan kita pelajari nanti) yang dipadukan bersama
dengan rangkaian automated test (pengujian otomatis) yang cepat.
Dengan mempraktikkan hal-hal ini, feedback (umpan balik) bisa
segera tersampaikan dengan cepat ke Developer dan segera
diperbaiki.

The Third Way: Prinsip terkait Proses Belajar dan

Eksperimen yang Berkelanjutan

Pembahasan yang ketiga adalah The Third Way, yakni prinsip

terkait proses belajar dan eksperimen yang berkelanjutan. Prinsip
ini menjelaskan tentang cara memupuk kultur untuk mendorong
proses belajar dan eksperimen yang berkelanjutan. Selain itu,
prinsip ini juga membenamkan pemahaman bahwa cara untuk
menguasai sesuatu adalah melalui pengulangan dan berlatih terus-
menerus.

Tentu kita semua tahu bahwasanya eksperimen yang dilakukan

terus-menerus bukanlah hal yang mudah untuk dilestarikan sebab
membutuhkan keberanian dalam pengambilan risiko dan
kelapangan hati dalam belajar (baik dari jika berhasil maupun
gagal).

Proses pengambilan risiko biasanya adalah sesuatu yang sebisa

mungkin dihindari oleh bisnis. Namun sebaliknya, justru eksperimen
dan pengambilan risiko adalah hal yang bagus bagi IT karena
memungkinkan kita untuk senantiasa meningkatkan sistem kerja.

Proses eksperimen ini sering kali mengharuskan tim untuk berani

melakukan hal-hal di luar kebiasaan mereka selama ini. Ini
merupakan hal yang bagus. Pasalnya, ketika terjadi kesalahan atau
kegagalan, tim bisa memperbaikinya dan belajar dari
kesalahan/kegagalan tersebut.

Dengan begitu, ke depannya tim bisa lebih cekatan dalam

mengembangkan aplikasi dan terhindar dari kegagalan yang
berulang. Pun, bila seandainya terjadi kesalahan yang tak
diinginkan, tim akan mengerti apa yang harus dilakukan dan
memitigasi agar kegagalan tersebut tidak terulang kembali.

Jika kita mampu menerapkan The First Way dan The Second Way,
kelak kita akan lebih berani dalam mengambil risiko. Sebabnya, kita
tahu bahwa risikonya takkan terlalu besar (mengingat kita memiliki
skala batch pekerjaan yang kecil) dan akan mendapatkan feedback
yang cepat mengenai pekerjaan yang kita lakukan.

Apabila kita sudah terbiasa melakukan eksperimen dan belajar dari

kesalahan, maka akan tercipta kultur untuk selalu ingin berinovasi
dan berani dalam mengambil risiko.

CALMS Framework
Pengantar CALMS Framework

Untuk bisa menerapkan DevOps dengan baik di perusahaan, ihwal

terkrusial yang perlu Anda lakukan adalah memahami metodologi
DevOps. Dengan menguasainya, niscaya kelak dapat meningkatkan
kolaborasi antartim di perusahaan melalui aktivitas yang
berlangsung pada siklus hidup aplikasi, mulai dari desain produk,
proses pengembangan aplikasi, hingga operasional produksi (a.k.a
rilis ke pasar dan dinikmati pengguna).

Seperti yang kita tahu, DevOps bertujuan untuk menyatukan orang-

orang untuk bekerja sama dan menghilangkan hambatan sehingga
mereka dapat mencapai tujuan secara efisien. Nah, modul ini akan
menyelami lebih dalam mengenai metodologi yang dipakai untuk
mengadopsi DevOps, yakni seputar kultur, praktik, dan tools.

Untuk memahami bagaimana cara menerapkan DevOps, kita akan

menggunakan suatu framework alias kerangka kerja yang bernama
CALMS sebagai acuan.

CALMS merupakan framework yang digunakan sebagai sarana

untuk menilai apakah suatu perusahaan atau organisasi siap dalam
mengadopsi DevOps, serta mengukur bagaimana kemajuan
perusahaan dalam transformasi atau proses penerapan DevOps
mereka.

CALMS Framework: Culture

Beberapa hal yang perlu Anda pelajari dan terapkan di perusahaan

adalah membangun lingkungan yang kolaboratif, fokus pada
kebutuhan pengguna, dan menyertakan keamanan di setiap fase.

 Membangun lingkungan yang kolaboratif

Kolaborasi merupakan hal terpenting yang perlu diperhatikan
saat mengimplementasikan DevOps di perusahaan. Baik
Developer maupun IT Operations, keduanya memiliki
perangkat lunak, kepentingan, dan tujuannya sendiri-sendiri.
Ini bukanlah hal yang baik karena akan menciptakan gap atau
kerenggangan di antara mereka.
 Oleh karenanya, DevOps perlu hadir agar mereka bisa bersatu
dan saling bekerja sama. Kolaborasi ini pada akhirnya dapat
mengoptimalkan produktivitas dari sisi Developer sekaligus
menjaga keandalan dari sisi IT Operations.

 Fokus pada kebutuhan pengguna

Mindset yang mengutamakan pengguna adalah faktor utama
dalam mendorong pengembangan aplikasi. Sebagai contoh,
dengan feedback loop (umpan balik yang berkelanjutan), tim
terkait (Developer dan IT Operations) bisa tetap terhubung
dengan pengguna untuk mengembangkan aplikasi sesuai
kebutuhan pasar.

 Menyertakan keamanan di setiap fase

Aspek keamanan harus diimplementasikan di setiap fase
dalam siklus hidup aplikasi, baik saat masih dalam proses
coding maupun selepas rilis ke pasaran.

Musabab ini adalah hal yang krusial, Anda mesti sedini

mungkin mengedukasi tim Developer dan IT Operations untuk
menanamkan aspek keamanan dalam pola kerja mereka.

CALMS Framework: Automation

Dengan menerapkan DevOps, tugas-tugas repetitif dan manual

dapat diotomatiskan sehingga memungkinkan tim (baik Developer
maupun IT Operations) untuk fokus menciptakan inovasi.

Automasi akan menjadikan proses pengembangan (development),

pengujian (testing), dan penggelaran (deployment) menjadi cepat.
Namun, untuk mewujudkan hal itu, Anda perlu mengidentifikasi
sekiranya di bagian mana saja proses automasi bisa diterapkan.

CALMS Framework: Lean

Dalam implementasi DevOps, tim Developer perlu menerapkan

prinsip lean guna menghilangkan inefisiensi proses dan
mengoptimalkan nilai kerja, seperti meminimalkan WIP, menjadikan
pekerjaan kita transparan, mengeliminasi kerumitan saat proses
penyerahan kode ke IT Operations, dan mengurangi waktu tunggu
saat berpindah dari satu fase ke fase lainnya (misal dari penulisan
kode ke pengujian).

CALMS Framework: Measurement

Dalam menerapkan DevOps, perusahaan mesti mengabdikan diri

mereka untuk benar-benar mengumpulkan data tentang apa pun,
mulai dari alur kerja, proses deployment, pengguna, hingga
infrastruktur. Ini diperlukan guna memahami kemampuan
perusahaan saat ini dan mengidentifikasi di bagian mana perbaikan
dapat diterapkan.

Meski bisa mengukur segala hal, tidak berarti kita harus mengukur
semuanya. Berikut adalah beberapa contoh pertanyaan untuk
mengukur kinerja atau proses Anda selama ini.

 Berapa lama waktu yang dibutuhkan dari tahap penulisan

kode hingga deployment?
 Seberapa sering bug atau galat muncul?
 Berapa lama waktu yang dibutuhkan untuk pulih (recover) dari
kegagalan sistem (system failure)?
 Berapa banyak orang yang menggunakan produk Anda saat
ini?
 Berapa banyak pengguna yang Anda peroleh atau justru
hilang di minggu ini?

Semua data-data ini akan menarik karena kelak membantu

perusahaan Anda untuk membuat keputusan. Salah satunya, Anda
bisa menentukan kapan waktu yang tepat untuk merilis fitur baru
atau melakukan rollback (kembali ke versi aplikasi sebelumnya).

CALMS Framework: Sharing

Hal yang tak kalah penting lainnya saat menerapkan DevOps di

perusahaan adalah dengan menciptakan budaya keterbukaan
(transparansi informasi dan komunikasi) dan saling berbagi di
dalam dan di antara tim. Dengan begitu, semua orang akan bisa
bekerja sama menuju satu tujuan dan meminimalisir gesekan yang
timbul ketika masalah muncul.

Praktik DevOps

Pengantar Praktik DevOps

Kita suah membedah secara tuntas mengenai metodologi DevOps

melalui CALMS Framework. Kini kita akan menyambangi materi lain
mengenai bagaimana sebenarnya DevOps dipraktikkan supaya
Anda mendapat gambaran dengan lebih jelas.

Anda harus paham terlebih dahulu bahwa poin-poin yang tadi kita
bahas pada modul CALMS Framework akan mengarah pada praktik
DevOps yang merampingkan dan meningkatkan siklus
pengembangan aplikasi agar bisa menyajikan update (pembaruan)
lebih sering secara andal seraya menjaga stabilitas infrastruktur
(seperti server).

Ini pada akhirnya berujung pada dua hal praktis nan penting, yakni
DevOps pipeline dan DevOps tools. Kita akan bahas ini lebih
mendalam di submodul berikutnya. Yuk, lanjut!

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.

Mari kita bedah setiap tahapan pada DevOps Pipeline 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. Selepas kode siap,
 Developer pun 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. Usai semua proses build 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. Setelah semua
pengujian berhasil lolos, tahapan selanjutnya pun dimulai.
 Release
Di fase ini, artifact yang telah lolos pengujian kemudian
dikemas/dibungkus dengan nomor versi (version number)
tertentu sebelum nanti akhirnya di-deploy.
 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
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.
Jika terjadi kegagalan di salah satu tahapan, proses yang tengah
dilakukan akan dihentikan sehingga tak bisa lanjut ke fase
berikutnya.

Selain itu, saat kita belajar tentang DevOps pipeline atau CI/CD
pipeline, maka akan erat kaitannya pula dengan istilah-istilah
seperti Continuous Integration, Continuous Delivery, dan
Continuous Deployment. Apa sih perbedaan mendasar di antara
ketiganya?
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), setelah itu proses build
dan test secara otomatis pun dijalankan.

 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.

 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
ada.

Jadi, dengan continuous deployment, proses deploy aplikasi ke

lingkungan production berlangsung secara otomatis tanpa ada
persetujuan eksplisit dan intervensi manusia.

DevOps Tools
Dalam mendukung kesuksesan praktik DevOps di suatu
perusahaan, ada beberapa kategori best practice yang perlu kita
perhatikan berikut dengan tools yang sesuai untuk menerapkannya
(akan dibagi antara tools yang bersifat umum dan AWS).

Komunikasi dan Kolaborasi

Berikut adalah beberapa tools yang bisa membantu
mengimplementasikan komunikasi dan kolaborasi antartim di
perusahaan.

 Platform komunikasi dan kolaborasi terpadu

Berikut adalah beberapa contoh platform komunikasi dan
kolaborasi terpadu (dibagi berdasarkan tools umum dan tools
AWS).

Umum AWS

Microsoft Teams
Slack
Amazon Ch
Workplace
Cisco Webex Teams
 Cloud
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.
 IDE
Berikut adalah beberapa contoh IDE yang
mendukung collaboration tool(dibagi berdasarkan tools umum
dan tools AWS).

Umum

Visual Studio dengan fitur Live Share

AWS C
Intellij IDEA dengan fitur Code With Me

CI/CD
Dalam poin CI/CD ini, tools yang digunakan dibagi menjadi
beberapa kategori berdasarkan siklus DevOps pipeline.
 Code
Berikut beberapa contoh version control system yang bisa
Anda pakai (dibagi berdasarkan tools umum dan tools AWS).

Version Control System

Umum AWS
GitHub
GitLab AWS CodeCommit
BitBucket
 Build
Berikut beberapa contoh tools yang digunakan pada proses
build (dibagi berdasarkan tools umum dan tools AWS).

Build Tools

Umum AWS
Jenkins
Travis CI AWS CodeBuild
CircleCI
 Test
Tahapan test ini sebenarnya tergantung. Apabila sekadar unit
test, maka itu 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 dan mengintegrasikannya dengan AWS.

 Release
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).
 Container Image Registry tools
Umum AWS
Docker Hub Amazon ECR
 Deploy
Berikut adalah beberapa contoh tools yang bisa digunakan
untuk deploy aplikasi (dibagi berdasarkan tools umum dan
tools AWS).

Deployment Tools

Umum AWS
Heroku AWS CodeDeploy
Netlify AWS Elastic Beanstalk
GitHub Pages

 Monitor
Berikut adalah beberapa contoh tools yang bisa digunakan
untuk memantau aplikasi (dibagi berdasarkan tools umum dan
tools AWS).

Monitoring Tools

Umum AWS
Prometheus AWS X-Ray
Elastic Stack Amazon CloudWatch
Dynatrace

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 dalam
proses pengembangan aplikasi.

Infrastructure as Code
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 perlu
mengonfigurasinya secara manual.

Berikut adalah contoh tools yang bisa digunakan untuk

kategori infrastructure automation (dibagi berdasarkan tools
umum dan tools AWS).

Infrastructure automation tools

Umum AWS
Terraform AWS CloudFormation
 Configuration management
Berikut adalah beberapa contoh tools yang bisa digunakan
pada kategori configuration management (dibagi berdasarkan
tools umum dan tools AWS).

Configuration management tools

Umum AWS
Chef
Puppet AWS OpsWorks
Ansible

Arsitektur Microservices
Ketika berbicara tentang microservice, akan ada dua topik hangat
yang perlu kita bahas, yakni container dan serverless.

 Container
Berikut adalah beberapa contoh tools yang bisa digunakan
terkait container orchestration tools (dibagi berdasarkan tools
umum dan tools AWS).

Container Orchestration tools

Umum AWS
Kubernetes Amazon EKS
OpenShift Amazon ECS
Nomad
  Serverless
Berikut adalah beberapa contoh tools yang bisa digunakan
terkait serverless function as a service (dibagi berdasarkan
tools umum dan tools AWS).

Serverless Function as a Service tools

Umum AWS
Serverless
OpenFaaS AWS Lambda
OpenWhisk

Monitoring dan Logging

Berikut adalah beberapa contoh tools yang bisa digunakan terkait
monitoring dan logging (dibagi berdasarkan tools umum dan tools
AWS).

Monitoring and Logging tools

Umum AWS
Prometheus AWS X-Ray
Elastic Stack Amazon CloudWatch
Dynatrace

Kisah Implementasi DevOps

Pengantar Kisah Implementasi DevOps

Kita sudah belajar banyak hal soal DevOps, mulai dari Pengenalan
DevOps, Prinsip-Prinsip DevOps, hingga Metodologi DevOps.

Namun, mungkin Anda punya pertanyaan pemungkas terkait

DevOps yang sudah bergentayangan di benak Anda, “Apakah ada
contoh bagaimana implementasi DevOps di suatu perusahaan
ternama yang bisa kita jadikan contoh?”

Meskipun Anda sudah mengetahui manfaat-manfaat menerapkan

DevOps dan tahu bagaimana cara-cara mengimplementasikannya,
pasti pertanyaan itu masih bersarang di pikiran Anda. Nah, untuk
itu, di modul ini kita akan membedah sebuah kisah bagaimana
perusahaan tersohor nan kondang seperti Amazon
mengimplementasikan DevOps di dalam perusahaannya.

Anda harus tahu bahwa mulanya Amazon pun tidak menerapkan

DevOps. Akan tetapi, lambat laun akhirnya mereka
mentransformasikan struktur perusahaannya agar bisa
mengimplementasikan DevOps.

Amazon merupakan salah satu contoh perusahaan yang awalnya

menggunakan praktik pengembangan aplikasi tradisional dan kini
bermetamorfosis menjadi lebih fleksibel dan efisien dengan
bantuan DevOps.

Transformasi DevOps pada Perusahaan Amazon

Pada awal 2000-an, situs retail [Link] merupakan website

yang memiliki arsitektur monolitik dan dikembangkan melalui
praktik pengembangan aplikasi tradisional. Selain itu, struktur
perusahaan Amazon pun bersifat hierarkis, yakni terdiri dari tim
Development (Developer), Testing (IT Tester atau QA), dan
Operational (IT Operations) yang masing-masing terpisah dan
tertutup satu sama lain (siloed team). Ditambah, aplikasi (dalam hal
ini website [Link]) di-deploy sebagai satu unit.

Praktik pengembangan aplikasi yang dilakukan oleh Amazon

sesungguhnya banyak masalah yang dapat menyulitkan mereka
sendiri, seperti:

1. antarkomponen aplikasi saling bergantung satu sama lain,

2. proses QA (Quality Assurance) dilakukan secara manual,
3. proses deployment berlangsung pelik nan rumit,
4. dan lain-lain.

Untungnya, Amazon segera menyadari bahwa proses

pengembangan aplikasi mereka terhambat oleh arsitektur aplikasi
dan struktur perusahaan. Pada akhirnya menjadi jelas bahwa ada
sesuatu yang perlu diubah dan diperbaiki guna meningkatkan
kecepatan pengembangan aplikasi dan kelancaran proses
deployment. Dengan demikian, Amazon bisa terbebas dari urusan
operasional aplikasi yang terus-menerus menghantui mereka dan
lebih fokus pada kebutuhan pengguna. Tentu saja ini tidak terjadi
dalam semalam, melainkan berproses secara bertahap.

Amazon membentuk tim kecil yang lintas fungsional dan terdiri dari
8-10 orang bernama two-pizza teams (tim dua pizza). Unik ya
namanya? Filosofi di balik penamaan two-pizza teams ini ialah
Amazon mencoba untuk membuat tim yang tidak lebih besar dari
yang bisa diberi makan oleh dua pizza. Pasalnya, semakin kecil tim,
semakin baik kolaborasi akan tercipta. Kolaborasi yang baik tentu
akan menghadirkan suasana yang mendukung untuk proses
pengembangan aplikasi yang lebih cepat.

Selain itu, Amazon mengubah arsitektur aplikasi menjadi service-

oriented (berorientasi layanan). Setiap service (layanan) umumnya
berisi satu fungsionalitas bisnis, misal Product Catalog service,
Shopping Cart service, atau Order service.

Two-pizza teams ini pun diselaraskan dengan beberapa service

tersebut. Mereka diberikan kepemilikan sehingga dapat
mengembangkan setiap service secara mandiri.

Dengan cara ini, setiap tim secara konsisten dapat menemukan dan
mengeliminasi redundansi dalam proses mereka yang akhirnya
mampu mempercepat proses pengembangan aplikasi. Ini
merupakan suatu kemajuan.

Akan tetapi, Amazon tahu bahwa mereka bisa berbuat lebih

banyak. Mereka menyadari bahwa proses yang manual, penyerahan
kode dari satu orang ke orang lainnya, dan siklus perilisan aplikasi
yang mereka pakai masih menyebabkan delay (penundaan).

Amazon ingin menghadirkan aplikasi, penambahan fitur, dan

pembaruan dengan lebih cepat ke pengguna. Alhasil, arsitektur
monolitik yang sebagian masih mereka gunakan selama ini benar-
benar diubah menjadi service-oriented sepenuhnya dan kemudian
segera menjadi microservice.

Tak hanya itu, Amazon juga membangun dan mengadopsi tools

untuk memvisualisasikan dan mengotomatisasi proses perilisan
perangkat lunak mereka, mulai dari pengecekan kode, pengujian,
hingga deploy ke production. Yakinlah, pemantauan selama proses
pengembangan hingga setelah rilis akan memberikan dampak baik
kepada tim, salah satunya berupa kepercayaan diri. Segera, tim
akan sanggup merilis perangkat lunak secara independen, lebih
cepat, dan andal.

Hikmah dari Transformasi DevOps pada Perusahaan Amazon

Amazon–dan tentu perusahaan-perusahaan lain–telah beralih dari

praktik pengembangan aplikasi tradisional yang telah mereka
bangun dan lakukan bertahun-tahun ke kultur, praktik, dan tools
DevOps. Mesti itu bukan perjalanan yang mudah dan singkat. Perlu
upaya dan perjuangan serempak agar perusahaan mampu
mengimplementasikan DevOps dan akhirnya mengenyam manfaat-
manfaat yang semula tak dirasa.

Amazon telah membuktikan bahwa dengan DevOps, perusahaan

mereka dapat berinovasi, menghadirkan produk, dan tumbuh lebih
cepat daripada perusahaan lain yang menggunakan praktik
pengembangan aplikasi tradisional. Dengan cara ini, Amazon dapat
melayani pelanggan mereka dengan lebih baik dan bersaing lebih
efektif di pasar.

Namun, terlepas dari semua itu, ada satu pertanyaan yang mungkin
masih berkutat di kepala Anda, “Pasti akan terjadi banyak
perubahan di perusahaan saya, lantas dari mana saya harus
memulai semua ini?”

Praktik terbaik yang perlu Anda lakukan adalah dengan mengambil

langkah kecil terlebih dahulu.

Lihat dan amati kembali perusahaan Anda lebih dalam. Mungkin

Anda sebenarnya sudah siap secara kultur dan hanya perlu
menerapkan praktik dan tools DevOps saja. Atau sebaliknya, bisa
jadi Anda sama sekali belum siap secara kultur, yang artinya Anda
harus evaluasi dan mulai mendorong terciptanya kultur DevOps ini.

Akan tetapi, bila perusahaan Anda ternyata sudah siap segalanya.

Mungkin Anda bisa mulai dengan membuat CI/CD Pipeline, misal
dengan menggunakan layanan dari AWS seperti AWS CodePipeline
(sudah kita bahas sebelumnya).