🥇Panduan Pemula: Membangun Pipeline DevOps

Jika Anda baru mengenal DevOps, lihat panduan lima langkah untuk membuat pipeline pertama Anda.

DevOps telah menjadi solusi standar untuk memperbaiki proses pengembangan perangkat lunak yang lambat, terputus-putus, atau rusak. Masalahnya adalah jika Anda baru mengenal DevOps dan tidak tahu harus mulai dari mana, Anda mungkin kurang memahami teknik ini. Artikel ini akan membahas pendefinisian pipeline DevOps dan memberikan petunjuk lima langkah untuk membuatnya. Meskipun tutorial ini tidak lengkap, tutorial ini akan memberi Anda landasan untuk memulai perjalanan dan memperluas pengetahuan Anda di masa depan. Tapi mari kita mulai dengan sejarah.

Perjalanan DevOps Saya

Saya sebelumnya bekerja di tim cloud Citi Group yang mengembangkan aplikasi web Infrastructure-as-a-Service (IaaS) untuk mengelola infrastruktur cloud Citi, namun saya selalu tertarik pada bagaimana membuat proses pengembangan menjadi lebih efisien dan membawa perubahan budaya yang positif pada masyarakat. tim pengembangan. Saya menemukan jawabannya dalam buku yang direkomendasikan oleh Greg Lavender, CTO Arsitektur Cloud dan Infrastruktur di Citi. Buku itu berjudul Proyek Phoenix (Proyek Phoenix), dan menjelaskan prinsip-prinsip DevOps, tetapi bacaannya seperti novel.

Tabel di bagian belakang buku ini menunjukkan seberapa sering berbagai perusahaan menerapkan sistem mereka dalam lingkungan rilis:

Amazon: 23 per hari
Google: 5 per hari
Netflix: 500 per hari
Facebook: Sekali sehari
Twitter: 3 kali seminggu
Perusahaan pada umumnya: Setiap 9 bulan sekali

Bagaimana frekuensi Amazon, Google, dan Netflix dimungkinkan? Hal ini karena perusahaan-perusahaan ini telah menemukan cara untuk membuat pipeline DevOps yang hampir sempurna.

Kami masih jauh dari hal tersebut hingga kami menerapkan DevOps di Citi. Saat itu, tim saya memiliki lingkungan yang berbeda, namun penerapan di server pengembangan sepenuhnya manual. Semua pengembang hanya memiliki akses ke satu server pengembangan berdasarkan IBM WebSphere Application Server Community Edition. Masalahnya adalah server akan mati setiap kali beberapa pengguna mencoba menerapkan pada saat yang sama, sehingga para pengembang harus mengomunikasikan niat mereka satu sama lain, dan hal ini cukup menyusahkan. Selain itu, terdapat masalah dengan cakupan kode pengujian tingkat rendah, proses penerapan manual yang rumit, dan ketidakmampuan untuk melacak penerapan kode yang terkait dengan tugas atau cerita pengguna tertentu.

Saya menyadari bahwa sesuatu perlu dilakukan dan menemukan rekan kerja yang berpikiran sama. Kami memutuskan untuk berkolaborasi dalam membangun pipeline DevOps awal - dia menyiapkan mesin virtual Tomcat dan server aplikasi sementara saya mengerjakan Jenkins, mengintegrasikan Atlassian Jira dan BitBucket, dan mengerjakan cakupan kode pengujian. Proyek sampingan ini sangat sukses: kami hampir sepenuhnya mengotomatiskan banyak proses, mencapai hampir 100% uptime di server pengembangan kami, menyediakan pelacakan dan meningkatkan cakupan pengujian kode, dan menambahkan kemampuan untuk menghubungkan cabang Git ke masalah atau penerapan Jira. Sebagian besar alat yang kami gunakan untuk membangun saluran DevOps adalah sumber terbuka.

Sekarang saya memahami betapa sederhananya saluran DevOps kami: kami tidak menggunakan ekstensi seperti file Jenkins atau Ansible. Namun, jalur pipa sederhana ini bekerja dengan baik, mungkin karena prinsip Pareto (juga dikenal sebagai aturan 80/20).

Pengantar Singkat tentang DevOps dan Pipeline CI/CD

Jika Anda bertanya kepada beberapa orang, “Apa itu DevOps?”, Anda mungkin akan mendapatkan beberapa jawaban berbeda. DevOps, seperti Agile, telah berevolusi untuk mencakup banyak disiplin ilmu yang berbeda, namun kebanyakan orang akan menyetujui beberapa hal: DevOps adalah praktik pengembangan perangkat lunak atau siklus hidup pengembangan perangkat lunak (SDLC) yang prinsip utamanya adalah mengubah budaya di mana pengembang dan non- pengembang ada di lingkungan di mana:

Operasi yang sebelumnya dilakukan secara manual telah diotomatisasi;
Setiap orang melakukan yang terbaik;
Jumlah implementasi dalam jangka waktu tertentu meningkat; Throughput meningkat;
Peningkatan fleksibilitas pengembangan.

Meskipun memiliki perangkat lunak yang tepat bukan satu-satunya hal yang Anda perlukan untuk menciptakan lingkungan DevOps, beberapa alat sangatlah penting. Alat utamanya adalah integrasi berkelanjutan dan penerapan berkelanjutan (CI/CD). Dalam pipeline ini, lingkungan memiliki tahapan yang berbeda (misalnya DEV, INT, TST, QA, UAT, STG, PROD), banyak operasi yang diotomatisasi, dan pengembang dapat menulis kode berkualitas tinggi, mencapai ketangkasan pengembangan, dan tingkat penerapan yang tinggi.

Artikel ini menjelaskan pendekatan lima langkah untuk membuat alur DevOps seperti yang ditunjukkan dalam diagram berikut menggunakan alat sumber terbuka.

Langkah 1: Metode CI/CD

Hal pertama yang Anda perlukan adalah alat CI/CD. Jenkins, alat sumber terbuka berbasis Java dan dilisensikan di bawah lisensi MIT, adalah alat yang mempopulerkan DevOps dan telah menjadi standar de facto.

Jadi apa itu Jenkins? Anggap saja sebagai semacam remote control universal ajaib yang dapat berbicara dan mengatur berbagai layanan dan alat. Alat CI/CD seperti Jenkins sendiri tidak ada gunanya, tetapi alat ini menjadi lebih kuat jika terhubung ke alat dan layanan yang berbeda.

Jenkins hanyalah salah satu dari banyak alat CI/CD sumber terbuka yang dapat Anda gunakan untuk membangun pipeline DevOps Anda.

Jenkins: Creative Commons dan MIT
Travis CI: MIT
Kontrol Pelayaran:BSD
Bot Pembangun: GPL
Apache Gump: Apache 2.0
Sopir taksi: GNU

Berikut tampilan proses DevOps dengan alat CI/CD:

Anda memiliki alat CI/CD yang berjalan di localhost Anda, namun tidak banyak yang dapat Anda lakukan saat ini. Mari beralih ke tahap berikutnya dalam perjalanan DevOps.

Langkah 2: Kelola Sistem Kontrol Sumber

Cara terbaik (dan mungkin termudah) untuk memverifikasi bahwa alat CI/CD Anda dapat melakukan keajaibannya adalah dengan berintegrasi dengan alat kontrol kode sumber (SCM). Mengapa Anda memerlukan kontrol sumber? Katakanlah Anda sedang mengembangkan sebuah aplikasi. Setiap kali Anda membuat aplikasi, Anda sedang memprogram, dan tidak masalah apakah Anda menggunakan Java, Python, C++, Go, Ruby, JavaScript, atau jutaan bahasa pemrograman lainnya. Kode yang Anda tulis disebut kode sumber. Pada awalnya, terutama saat Anda bekerja sendiri, mungkin boleh saja meletakkan semuanya di direktori lokal. Namun seiring dengan semakin besarnya proyek dan Anda mengundang orang lain untuk berkolaborasi, Anda memerlukan cara untuk mencegah konflik sekaligus berbagi modifikasi secara efektif. Anda juga memerlukan cara untuk memulihkan versi sebelumnya, karena membuat cadangan dan menyalin/menempelkannya sudah ketinggalan zaman. Anda (dan rekan tim Anda) membutuhkan sesuatu yang lebih baik.

Di sinilah kontrol kode sumber menjadi suatu keharusan. Alat ini menyimpan kode Anda di repositori, melacak versi, dan mengoordinasikan pekerjaan peserta proyek.

Meskipun ada banyak alat kontrol sumber di luar sana, Git adalah standarnya, dan memang demikian. Saya sangat merekomendasikan menggunakan Git, meskipun ada opsi sumber terbuka lainnya jika Anda mau.

Git: GPLv2 dan LGPL v2.1
Subversi: Apache 2.0
Sistem Versi Bersamaan (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Ini adalah tampilan pipeline DevOps dengan penambahan kontrol kode sumber.

Alat CI/CD dapat mengotomatiskan proses peninjauan, perolehan kode sumber, dan kolaborasi antar anggota. Tidak buruk? Namun bagaimana Anda mengubahnya menjadi aplikasi yang berfungsi sehingga miliaran orang dapat menggunakan dan menghargainya?

Langkah 3: Buat Alat Otomasi Pembuatan

Besar! Anda dapat meninjau kode dan membuat perubahan pada kontrol sumber, dan mengundang teman Anda untuk berkolaborasi dalam pengembangan. Tapi Anda belum membuat aplikasi. Untuk membuat aplikasi web, aplikasi tersebut harus dikompilasi dan dikemas dalam format batch yang dapat diterapkan atau dijalankan sebagai file yang dapat dieksekusi. (Perhatikan bahwa bahasa pemrograman yang ditafsirkan seperti JavaScript atau PHP tidak perlu dikompilasi).

Gunakan alat otomatisasi pembangunan. Apa pun alat otomatisasi build yang Anda putuskan untuk digunakan, semuanya memiliki tujuan yang sama: membuat kode sumber ke dalam format yang diinginkan dan mengotomatiskan tugas pembersihan, kompilasi, pengujian, dan penerapan ke lingkungan tertentu. Alat pembuatan akan bervariasi tergantung pada bahasa pemrograman Anda, namun berikut adalah beberapa opsi sumber terbuka yang umum.

Nama
Lisensi
Bahasa pemrograman

Maven
Apache 2.0
Jawa

Semut
Apache 2.0
Jawa

Gradle
Apache 2.0
Jawa

Bazel
Apache 2.0
Jawa

Membuat
GNU
N / A

Mengorok
MIT
JavaScript

Meneguk
MIT
JavaScript

pembangun
Apache
Rubi

Menyapu
MIT
Rubi

AP
GNU
Ular sanca

SCon
MIT
Ular sanca

BitBake
GPLv2
Ular sanca

Kue
MIT
C#

ASDF
Ekspatriat (MIT)
PELAT

Komplotan rahasia
BSD
Haskell

Besar! Anda dapat memasukkan file konfigurasi alat otomasi build ke dalam sistem kontrol sumber dan membiarkan alat CI/CD Anda menyatukan semuanya.

Semuanya baik-baik saja, bukan? Namun di mana harus menyebarkan aplikasi Anda?

Langkah 4: Server Aplikasi Web

Untuk saat ini, Anda memiliki file paket yang dapat dieksekusi atau diinstal. Agar aplikasi apa pun benar-benar berguna, aplikasi tersebut harus menyediakan semacam layanan atau antarmuka, namun Anda memerlukan wadah untuk menghosting aplikasi Anda.

Server aplikasi web hanyalah sebuah wadah. Server menyediakan lingkungan di mana logika paket yang disebarkan dapat ditentukan. Server juga menyediakan antarmuka dan menawarkan layanan web dengan mengekspos soket ke dunia luar. Anda memerlukan server HTTP, serta beberapa lingkungan (seperti mesin virtual) untuk menginstalnya. Untuk saat ini, anggaplah Anda akan mempelajari lebih lanjut tentang hal ini (walaupun saya akan membahas wadahnya di bawah).

Ada beberapa server aplikasi web sumber terbuka.

Nama
Lisensi
Bahasa pemrograman

Kucing jantan
Apache 2.0
Jawa

dermaga
Apache 2.0
Jawa

WildFly
GNU Publik Kecil
Jawa

Ikan kaca
CDDL & GNU Kurang Publik
Jawa

Django
3-Klausul BSD
Ular sanca

Angin topan
Apache 2.0
Ular sanca

gunicorn
MIT
Ular sanca

Ular sanca
MIT
Ular sanca

Rails
MIT
Rubi

Node.js
MIT
Javascript

Alur DevOps Anda hampir siap digunakan. Kerja bagus!

Meskipun Anda dapat berhenti di situ dan menangani sendiri integrasinya, kualitas kode adalah hal penting yang perlu dikhawatirkan oleh pengembang aplikasi.

Langkah 5: Cakupan Pengujian Kode

Menerapkan pengujian dapat menjadi persyaratan rumit lainnya, namun pengembang harus mengetahui bug apa pun dalam aplikasi sejak dini dan meningkatkan kualitas kode untuk memastikan kepuasan pengguna akhir. Untungnya, ada banyak alat sumber terbuka yang tersedia untuk menguji kode Anda dan memberikan rekomendasi untuk meningkatkan kualitasnya. Yang lebih baik lagi adalah sebagian besar alat CI/CD dapat terhubung ke alat ini dan mengotomatiskan prosesnya.

Pengujian kode terdiri dari dua bagian: kerangka pengujian kode yang membantu Anda menulis dan menjalankan pengujian, dan alat saran yang membantu Anda meningkatkan kualitas kode Anda.

Sistem pengujian kode

Nama
Lisensi
Bahasa pemrograman

JUnit
Lisensi Publik Eclipse
Jawa

EasyMock
Apache
Jawa

mockito
MIT
Jawa

KekuatanMock
Apache 2.0
Jawa

uji coba
MIT
Ular sanca

Hipotesa
Mozilla
Ular sanca

Racun
MIT
Ular sanca

Sistem rekomendasi untuk perbaikan kode

Nama
Lisensi
Bahasa pemrograman

Liputan
GNU
Jawa

Sampul Kode
Gerhana Publik (EPL)
Jawa

Cakupan.py
Apache 2.0
Ular sanca

Emma
Lisensi Publik Umum
Jawa

JaCoCo
Lisensi Publik Eclipse
Jawa

Hipotesa
Mozilla
Ular sanca

Racun
MIT
Ular sanca

Melati
MIT
JavaScript

Karma
MIT
JavaScript

Moka
MIT
JavaScript

ada
MIT
JavaScript

Perhatikan bahwa sebagian besar alat dan kerangka kerja yang disebutkan di atas ditulis untuk Java, Python, dan JavaScript, karena C++ dan C# adalah bahasa pemrograman berpemilik (walaupun GCC adalah sumber terbuka).

Sekarang setelah Anda mengimplementasikan alat cakupan pengujian, pipeline DevOps Anda akan terlihat seperti diagram yang ditunjukkan di awal tutorial ini.

Langkah tambahan

Wadah

Seperti yang saya katakan, Anda dapat menghosting server Anda di mesin virtual atau server, tetapi container adalah solusi yang populer.

Apa itu kontainer? Penjelasan singkatnya adalah mesin virtual memerlukan memori sistem operasi dalam jumlah besar, melebihi ukuran aplikasi, sedangkan container hanya memerlukan beberapa pustaka dan konfigurasi untuk menjalankan aplikasi. Jelas, masih ada kegunaan penting dari mesin virtual, namun container adalah solusi ringan untuk menghosting aplikasi, termasuk server aplikasi.

Meskipun ada opsi container lain, yang paling populer adalah Docker dan Kubernetes.

buruh pelabuhan: Apache 2.0
Kubernet: Apache 2.0

Alat otomatisasi perantara

Saluran DevOps kami terutama berfokus pada pembuatan dan penerapan aplikasi secara kolaboratif, namun ada banyak hal lain yang dapat Anda lakukan dengan alat DevOps. Salah satunya adalah penggunaan alat Infrastruktur sebagai Kode (IaC), yang juga dikenal sebagai alat otomatisasi middleware. Alat-alat ini membantu mengotomatiskan instalasi, manajemen, dan tugas-tugas lain untuk middleware. Jadi, misalnya, alat otomatisasi dapat mengekstrak aplikasi seperti server aplikasi web, database, dan alat pemantauan dengan konfigurasi yang benar dan menyebarkannya ke server aplikasi.

Berikut adalah beberapa alat otomatisasi middleware sumber terbuka:

Kemungkinan: GNU Publik
SaltStack: Apache 2.0
Koki: Apache 2.0
Boneka: Apache atau GPL

Cari tahu detail cara mendapatkan profesi yang dicari dari awal atau Naik Level dalam hal keterampilan dan gaji dengan mengikuti kursus online berbayar dari SkillFactory: