Lebih cepat dengan pengiriman berkelanjutan

Lebih dari 10 tahun lalu, kami menggarap proyek di Amazon untuk memahami seberapa cepat tim kami mengubah ide menjadi sistem produksi kualitas tinggi. Ini mengarahkan kami untuk mengukur throughput perangkat lunak sehingga kami dapat meningkatkan kecepatan eksekusi. Ternyata butuh rata-rata 16 hari sejak check-in kode hingga produksi. Tim memulai dengan sebuah ide, kemudian biasanya perlu satu setengah hari menulis kode untuk mewujudkan ide itu. Kami berkutat kurang dari satu jam untuk membangun dan menerapkan kode baru. Selebihnya, hampir 14 hari, kami menunggu anggota tim untuk mulai membangun, untuk melakukan penerapan, dan menjalankan tes. Di akhir proyek, kami merekomendasikan otomatisasi proses pasca check-in untuk meningkatkan kecepatan eksekusi. Tujuannya adalah meniadakan penundaan sambil menjaga atau bahkan meningkatkan kualitas.

Inti dari rekomendasi ini adalah program perbaikan berkelanjutan untuk meningkatkan kecepatan eksekusi. Keputusan untuk meningkatkan kecepatan eksekusi didasarkan pada prinsip kepemimpinan yaitu Teguh pada Standar Tertinggi. Prinsip ini adalah tentang memiliki standar tinggi tanpa henti, terus meningkatkan standar, dan menghadirkan produk, layanan, dan proses berkualitas tinggi. Prinsip Kepemimpinan kami menggambarkan bagaimana Amazon menjalankan bisnis, bagaimana pemimpin memimpin, dan bagaimana kami menempatkan pelanggan sebagai pusat keputusan kami.

Amazon telah membangun alat pengembangan perangkat lunak agar pakar perangkat lunak kami lebih produktif. Kami ciptakan sendiri sistem bangunan terpusat dan ter-hosting, Brazil, yang mengeksekusi serangkaian perintah di server dengan tujuan menghasilkan artefak yang dapat diterapkan. Di titik ini Brazil tidak menghiraukan perubahan kode sumber. Seseorang harus memulai sebuah bangunan. Kami juga punya sistem penerapan sendiri, Apollo, yang membutuhkan artefak bangunan untuk diunggah sebagai bagian dari inisiasi penerapan. Terinspirasi keinginan pengiriman berkelanjutan yang ada di industri, kami membangun sistem kami sendiri, Pipelines, untuk otomatisasi proses pengiriman perangkat lunak antara Brazil dan Apollo.

Proses rilis kami, termasuk pipeline dan sistem penerapan, harus dirancang untuk mengidentifikasi kerusakan secepat mungkin dan mencegahnya menimbulkan dampak pada pelanggan. Kami perlu memastikan bahwa proses rilis kami telah dikonfigurasi dengan benar dan memastikan bahwa artefak bangunan kami berfungsi sesuai tujuannya.

Kebersihan penerapan: Bentuk paling mendasar dari pengujian penerapan memastikan bahwa artefak yang baru diterapkan dapat dimulai dan dapat merespons pekerjaan. Sebagai bagian dari alur kerja pasca-penerapan, kami menjalankan pemeriksaan cepat yang memastikan artefak yang baru diterapkan telah dimulai dan melayani trafik. Misalnya, kami menggunakan kait peristiwa siklus hidup di file AWS CodeDeploy AppSpec untuk memicu skrip sederhana untuk menghentikan, memulai, dan memvalidasi penerapan. Kami juga memeriksa bahwa kami memiliki cukup kapasitas untuk melayani trafik pelanggan. Kami telah membangun teknik seperti host sehat minimum di CodeDeploy untuk memvalidasi bahwa kami selalu memiliki cukup kapasitas untuk melayani pelanggan. Akhirnya, jika mesin penerapan dapat mendeteksi kegagalan, maka perubahan harus dikembalikan untuk meminimalkan waktu pelanggan melihat kecacatan.

Pengujian sebelum produksi: Salah satu praktik terbaik Amazon adalah mengotomatisasi pengujian unit, integrasi, dan pra-produksi, dan menyertakan pengujian ini pada pipeline kami. Kami terus berupaya melakukan pengujian beban dan keamanan, dengan bias menyertakan pengujian ini pada pipeline kami. Yang kami maksud dengan pengujian unit adalah semua pengujian yang sebaiknya dilakukan pada mesin bangunan Anda, termasuk pemeriksaan gaya, cakupan kode, kompleksitas kode, dan banyak lagi. Menurut kami pengujian integrasi akan termasuk semua pengujian off-box seperti injeksi gagal, pengujian peramban otomatis, dan sejenisnya. Ada banyak artikel bagus tentang pengujian unit dan integrasi, jadi saya tidak akan membahas lebih jauh di sini.

Pengujian unit dan integrasi kami bertujuan sebagai verifikasi bahwa perilaku artefak bangunan kami secara fungsional benar. Semakin banyak validasi yang kami lakukan, semakin rendah risiko cacat terekspos kepada pelanggan kami. Untuk mengurangi waktu yang dibutuhkan untuk menyampaikan produk ke tangan pelanggan, kami mencoba mendeteksi cacat sedini mungkin dalam proses rilis. Secara umum, ini berarti bahwa jika pengujian Anda lebih kecil dan lebih cepat, Anda akan menerima umpan balik lebih cepat tentang masalah pada perubahan Anda.

Di Amazon, kami juga menggunakan teknik yang kami sebut pengujian pra-produksi. Lingkungan pra-produksi adalah tempat terakhir di mana pengujian dilakukan sebelum kami menerapkan perubahan pada produksi. Pengujian lingkungan pra-produksi menggunakan konfigurasi produksi sistem sehingga berfungsi persis seperti sistem produksi. Pendekatan ini memiliki dua keuntungan. Pertama, lingkungan pra-produksi menguji konfigurasi produksi untuk memastikan bahwa layanan dapat terhubung dengan benar ke semua sumber daya produksi, termasuk penyimpanan data produksi. Kedua, memastikan bahwa sistem berinteraksi dengan benar dengan API layanan produksi pada mana sistem bergantung. Lingkungan pra-produksi hanya digunakan oleh tim yang memiliki layanan itu, dan tidak pernah mengirimkan trafik dari pelanggan. Menjalankan pengujian pra-produksi meningkatkan keyakinan kami bahwa kode dan konfigurasi yang sama akan bekerja dalam produksi.

Memvalidasi dalam produksi: Ketika kami merilis kode ke pelanggan, kami tidak melakukannya sekaligus. Dampak merilis cacat ke semua pelanggan sekaligus terlalu besar lingkupnya. Alih-alih, kami menerapkan ke sel—instans layanan yang sepenuhnya independen. Ketika menerapkan perubahan ke beberapa pelanggan pertama di sel pertama kami, kami sangat berhati-hati. Kami hanya akan membiarkan sejumlah kecil pelanggan melihat perubahan baru, dan kami mengumpulkan umpan balik tentang apakah kode baru itu berfungsi. Kami memantau jumlah kesalahan yang dikeluarkan layanan kami setelah penerapan canary. Jika tingkat kesalahan naik, kami akan secara otomatis membalikkan perubahan. Misalnya, kami mungkin menunggu 3.000 poin data positif, tanpa poin data negatif, sebelum melanjutkan penerapan.

Komplikasi dapat muncul jika uji otomatis Anda melewatkan suatu kasus penggunaan. Kami berusaha untuk menangkap semua kesalahan dengan uji terstruktur dan berulang, baik otomatis ataupun manual. Namun, meskipun berusaha sekuat tenaga, sebuah cacat bisa saja lolos. Untuk menguji pengujian kami, kami biarkan perubahan baru produksi selama beberapa waktu tertentu untuk melihat apakah non-anggota tim menemukan masalah. Cukup lama kami membahas apakah harus membiarkan perubahan begitu saja di produksi atau berapa lama harus menunggu setelah penerapan canary sebelum diterapkan ke seluruh kelompok penerapan. Banyak tim kami yang memutuskan untuk menunggu selama jangka waktu tertentu sambil mengumpulkan poin data positif sebelum melanjutkan melalui penerapan rutin kami. Lama waktu di mana pipeline menunggu sangat tergantung pada tim. Beberapa tim menunggu berjam-jam dan yang lain hanya beberapa menit. Semakin tinggi dampak dan semakin lama waktu perbaikan masalah, semakin lambat proses rilis.

Setelah yakin pada sel pertama, kami kemudian akan mengekspos perubahan kode baru ke lebih banyak dan lebih banyak pelanggan sampai benar-benar dirilis. Sama seperti yang kami lakukan dengan penerapann canary, kami menunggu hingga merasa yakin dalam penerapan ke sel baru pertama sebelum melangkah ke sel berikutnya. Seiring semakin yakin pada artefak bangunan, kami mengurangi waktu yang digunakan untuk memverifikasi perubahan kode. Ini menghasilkan pola yang ingin kami dapatkan dari check-in hingga pelanggan produksi pertama kami secepat mungkin. Namun, setelah dalam produksi, kami perlahan merilis kode baru kepada pelanggan, berusaha untuk lebih yakin lagi karena kami secara bertahap mempercepat sisa penerapan.

Untuk memastikan bahwa sistem produksi terus melayani permintaan pelanggan, kami menciptakan trafik sintetik di sistem kami. Kami ingin umpan balik cepat jika layanan tidak berfungsi dengan benar, jadi kami menjalankan uji sintetik setidaknya setiap menit. Kami merancang uji sintetik untuk memastikan bahwa proses kami berjalan baik dan bahwa semua dependensi diuji, yang umumnya melibatkan pengujian semua API yang dihadapi publik.

Mengontrol ketika perangkat lunak dirilis: Untuk mengontrol keamanan rilis perangkat lunak kami, sejumlah mekanisme dibangun agar kecepatan perubahan yang terjadi dapat dikontrol melalui pipeline kami. Metrik, jendela waktu, dan pemeriksaan keamanan digunakan untuk mengontrol kapan perangkat lunak kami dirilis.

Pipelines dapat dikonfigurasikan untuk mencegah penerapan saat alarm terpicu karena perubahan metrik. Kami menggunakan metrik secara luas, dan kami memiliki alarm kesehatan sistem kami, kesehatan sel kami, Availability Zone dan Wilayah, dan hampir semua hal lain yang terlintas di benak Anda. Pipelines kami dikonfigurasi untuk menghentikan penerapan kode bila metrik penting memicu alarm. Namun, terkadang tim perlu menerapkan perbaikan untuk menangani alarm sistem. Untuk skenario ini, kami membiarkan tim membatalkan alarm agar perubahan tidak bergerak melalui pipeline.

Pipelines kami dapat menentukan jendela waktu di mana perubahan dibiarkan berkembang melalui pipeline. Tim dapat menemukan jendela waktunya sendiri untuk dibatasi ketika perubahan mencapai pelanggan. Tim AWS lebih memilih merilis perangkat lunak ketika ada banyak orang yang dapat dengan cepat merespons dan mengatasi masalah yang disebabkan oleh penerapan. Untuk mewujudkan ini, tim umumnya mengatur waktu sehingga penerapan dilakukan hanya selama jam kerja saja. Tim lain di Amazon lebih memilih merilis perangkat lunak ketika trafik pelanggan rendah. Jendela waktu ini dapat dibatalkan jika diperlukan.

Kami juga memiliki kemampuan untuk menghentikan pipeline berdasarkan isi artefak bangunan. Misalnya, kami bisa memblokir artefak bangunan yang berisi paket buruk yang dikenal atau referensi Git tertentu. Fitur ini pernah digunakan ketika kami menemukan bahwa perubahan pada paket mengandung regresi kinerja. Jika hanya menghapus paket dari repositori paket kami, maka pipeline yang sudah mengandung paket yang rusak masih akan menerapkan perubahan buruk itu pada pelanggan.

Kami mendapati bahwa tim sangat ingin meyakini otomatisasi. Kami semua sangat termotivasi untuk membangun dan merilis fitur yang meningkatkan kehidupan pelanggan, dan ini dapat didukung dengan pengiriman berkelanjutan. Kami lihat bahwa otomatisasi mengembalikan waktu kepada para teknisi dengan menghilangkan pekerjaan manual yang membuat frustrasi, rawan kesalahan, dan sulit. Kami telah menunjukkan bahwa penerapan berkelanjutan berdampak positif pada kualitas. Kami lihat bahwa otomatisasi memungkinkan tim sering merilis, perubahan demi perubahan, sehingga memudahkan untuk mengidentifikasi regresi.

Saat sistem masih baru, area permukaan yang akan diuji biasanya dapat dimengerti oleh sebagian besar anggota tim, sehingga beberapa pengujian manual mudah dilakukan. Namun, ketika sistem menjadi lebih kompleks, dan anggota tim berubah, maka nilai otomatisasi meningkat. Kami suka mengotomatisasi sistem kami sehingga kami dapat fokus pada menambah nilai pelanggan daripada mengelola proses menghasilkan perubahan tersebut kepada pelanggan.

Selama bertahun-tahun, Amazon telah menjalankan program peningkatan berkelanjutan yang berfokus pada kecepatan merilis perangkat lunak kepada pelanggan dan keamanan rilis tersebut. Kami memulai bukan dengan semua pemeriksaan risiko dan pengujian yang saya tulis di artikel ini. Seiring waktu, kami menemukan cara untuk mengidentifikasi dan mengurangi risiko.

Program peningkatan berkelanjutan dijalankan oleh pemimpin bisnis di berbagai tingkat organisasi. Ini memungkinkan setiap pemimpin bisnis menyesuaikan proses rilis perangkat lunaknya agar sesuai dengan risiko dan dampaknya pada bisnis. Beberapa program peningkatan berkelanjutan kami dijalankan di sebagian besar Amazon, dan terkadang pemimpin organisasi lebih kecil menjalankan programnya sendiri. Kami tahu selalu ada pengecualian untuk aturan tersebut. Sistem kami memiliki mekanisme opt-out sehingga kami tidak memperlambat tim yang membutuhkan pengecualian permanen atau sementara. Pada akhirnya, tim kami bertanggung jawab atas perilaku perangkat lunaknya, dan mereka bertanggung jawab untuk berinvestasi dengan tepat dalam proses rilis perangkat lunaknya.

Kami memulai dengan mengukur di mana kelemahan kami, mengatasinya, dan iterasi. Agar pekerjaan ini berkelanjutan, kami harus melakukannya secara bertahap, dan mengadakan perbaikan seiring waktu. Ketika Amazon pertama kali mulai menggunakan pipelines, banyak tim tidak yakin bahwa penerapan berkelanjutan akan berhasil. Agar mulai bekerja, kami mendorong tim untuk menyandikan proses rilisnya saat ini, langkah-langkah manual dan semuanya, dalam suat pipeline. Bagi banyak tim, pipeline bertindak sebagai antarmuka visual untuk proses rilisnya tanpa secara otomatis mempromosikan artefak bangunan melalui proses rilis. Seiring kepercayaan diri tumbuh, tim secara bertahap mengaktifkan otomatisasi di berbagai tahap pipeline sampai mereka tidak lagi perlu secara manual memicu setiap langkah pipeline-nya.

Percepat ke hari ini. Amazon sekarang berada di titik di mana tim bertujuan untuk otomatisasi penuh seiring mereka menulis kode baru. Bagi kami, otomatisasi adalah satu-satunya cara kami dapat terus mengembangkan bisnis.