Cara Microsoft berkembang dengan Azure DevOps
Microsoft berupaya menggunakan One Engineering System untuk membangun dan menyebarkan semua produk Microsoft dengan proses DevOps solid yang berpusat pada alur percabangan dan rilis Git. Artikel ini menyoroti implementasi praktis, bagaimana sistem menskalakan dari layanan kecil ke kebutuhan pengembangan platform besar-besaran, dan pelajaran yang dipelajari dari menggunakan sistem di berbagai tim Microsoft.
Mengadopsi proses pengembangan standar adalah usaha yang ambisius. Persyaratan organisasi Microsoft yang berbeda sangat bervariasi, dan persyaratan tim yang berbeda dalam organisasi menskalakan dengan ukuran dan kompleksitas. Untuk mengatasi berbagai kebutuhan ini, Microsoft menggunakan strategi percabangan berbasis batang untuk membantu mengembangkan produk dengan cepat, menyebarkannya secara teratur, dan memberikan perubahan dengan aman pada produksi.
Microsoft juga menggunakan prinsip-prinsip rekayasa platform sebagai bagian dari Sistem Rekayasa Satu.
Alur rilis Microsoft
Setiap organisasi harus menyelesaikan proses rilis kode standar untuk memastikan konsistensi di seluruh tim. Alur rilis Microsoft menggabungkan proses DevOps dari pengembangan hingga rilis. Langkah-langkah dasar alur rilis terdiri dari cabang, pendorongan, permintaan pull, dan penggabungan.
Cabang
Untuk memperbaiki bug atau menerapkan fitur, pengembang membuat cabang baru dari cabang integrasi utama. Model percabangan ringan Git menciptakan cabang topik berumur pendek ini untuk setiap kontribusi kode. Pengembang berkomitmen lebih awal dan menghindari cabang fitur yang berjalan lama dengan menggunakan bendera fitur.
Push
Ketika pengembang siap untuk mengintegrasikan dan mengirimkan perubahan ke tim lainnya, mereka mendorong cabang lokal mereka ke cabang di server, dan membuka permintaan pull. Repositori dengan beberapa ratus pengembang yang bekerja di banyak cabang menggunakan konvensi penamaan untuk cabang server untuk mengurangi kebingungan dan proliferasi cabang. Pengembang biasanya membuat cabang bernama users/<username>/feature, di mana <username> adalah nama akun mereka.
Permintaan pull
Cabang topik kontrol permintaan pull bergabung ke cabang utama dan memastikan bahwa kebijakan cabang terpenuhi. Proses permintaan pull membangun perubahan yang diusulkan dan menjalankan lulus pengujian cepat. Suite pengujian tingkat pertama dan kedua menjalankan sekitar 60.000 pengujian dalam waktu kurang dari lima menit. Ini bukan matriks pengujian Microsoft lengkap, tetapi cukup untuk dengan cepat memberikan keyakinan dalam permintaan pull.
Selanjutnya, anggota tim lain meninjau kode dan menyetujui perubahan. Tinjauan kode mengambil tempat pengujian otomatis ditinggalkan, dan sangat berguna untuk melihat masalah arsitektur. Tinjauan kode manual memastikan bahwa teknisi lain di tim memiliki visibilitas ke dalam perubahan dan kualitas kode tersebut tetap tinggi.
Penggabungan
Setelah permintaan pull memenuhi semua kebijakan build dan peninjau telah berhenti, cabang topik bergabung ke cabang integrasi utama, dan permintaan pull selesai.
Setelah penggabungan, pengujian penerimaan lainnya berjalan yang membutuhkan lebih banyak waktu untuk diselesaikan. Tes pasca-pemeriksaan tradisional ini melakukan validasi yang lebih menyeluruh. Proses pengujian ini memberikan keseimbangan yang baik antara memiliki tes cepat selama peninjauan permintaan pull dan memiliki cakupan pengujian lengkap sebelum rilis.
Perbedaan dari GitHub Flow
GitHub Flow adalah alur rilis pengembangan berbasis batang populer bagi organisasi untuk menerapkan pendekatan yang dapat diskalakan ke Git. Namun, beberapa organisasi menemukan bahwa seiring bertambahnya kebutuhan mereka, mereka harus berbeda dari bagian-bagian GitHub Flow.
Misalnya, bagian yang sering diabaikan dari GitHub Flow adalah bahwa permintaan pull harus disebarkan ke produksi untuk pengujian sebelum mereka dapat bergabung ke cabang utama. Proses ini berarti bahwa semua permintaan pull menunggu dalam antrean penyebaran untuk digabungkan.
Beberapa tim memiliki beberapa ratus pengembang yang bekerja terus-menerus dalam satu repositori, yang dapat menyelesaikan lebih dari 200 permintaan pull ke cabang utama per hari. Jika setiap permintaan pull memerlukan penyebaran ke beberapa pusat data Azure di seluruh dunia untuk pengujian, pengembang menghabiskan waktu menunggu cabang untuk digabungkan, alih-alih menulis perangkat lunak.
Sebagai gantinya, tim Microsoft terus mengembangkan di cabang utama dan meningkatkan penyebaran ke dalam rilis berwaktu, biasanya selaras dengan irama sprint tiga minggu.
Detail implementasi
Berikut adalah beberapa detail implementasi utama alur rilis Microsoft:
Strategi repositori Git
Tim yang berbeda memiliki strategi yang berbeda untuk mengelola repositori Git mereka. Beberapa tim menyimpan sebagian besar kode mereka dalam satu repositori Git. Kode dipecah menjadi komponen, masing-masing di folder tingkat akarnya sendiri. Komponen besar, terutama komponen yang lebih lama, mungkin memiliki beberapa subkomponen yang memiliki subfolder terpisah dalam komponen induk.
Repositori ajunct
Beberapa tim juga mengelola repositori ajunct. Misalnya, agen dan tugas build dan rilis, ekstensi Visual Studio Code, dan proyek sumber terbuka dikembangkan di GitHub. Perubahan konfigurasi cek masuk ke repositori terpisah. Paket lain yang bergantung pada tim berasal dari tempat lain dan dikonsumsi melalui NuGet.
Repositori mono atau multi-repositori
Sementara beberapa tim memilih untuk memiliki satu repositori monolitik, mono-repo, produk Microsoft lainnya menggunakan pendekatan multi-repositori . Skype, misalnya, memiliki ratusan repositori kecil yang dijahit bersama-sama dalam berbagai kombinasi untuk membuat banyak klien, layanan, dan alat yang berbeda. Terutama untuk tim yang merangkul layanan mikro, multi-repo dapat menjadi pendekatan yang tepat. Biasanya, produk lama yang dimulai sebagai monolit menemukan pendekatan mono-repo menjadi transisi termampu ke Git, dan organisasi kode mereka mencerminkan itu.
Cabang rilis
Alur rilis Microsoft menjaga cabang utama tetap dapat dibangun setiap saat. Pengembang bekerja di cabang topik berumur pendek yang bergabung ke main. Ketika tim siap untuk dikirim, baik di akhir sprint atau untuk pembaruan besar, mereka memulai cabang rilis baru dari cabang utama. Cabang rilis tidak pernah bergabung kembali ke cabang utama, sehingga mereka mungkin memerlukan perubahan penting pemilihan ceri.
Diagram berikut menunjukkan cabang berumur pendek di cabang biru dan rilis berwarna hitam. Satu cabang dengan komit yang membutuhkan pemilihan ceri muncul dengan warna merah.
Kebijakan dan izin cabang
Kebijakan cabang Git membantu menegakkan struktur cabang rilis dan menjaga cabang utama tetap bersih. Misalnya, kebijakan cabang dapat mencegah dorongan langsung ke cabang utama.
Untuk menjaga hierarki cabang tetap rapi, tim menggunakan izin untuk memblokir pembuatan cabang di tingkat akar hierarki. Dalam contoh berikut, semua orang dapat membuat cabang di folder seperti pengguna/, fitur/, dan tim/. Hanya manajer rilis yang memiliki izin untuk membuat cabang di bawah rilis/, dan beberapa alat otomatisasi memiliki izin ke integrasi/ folder.
Alur kerja repositori Git
Dalam repositori dan struktur cabang, pengembang melakukan pekerjaan sehari-hari mereka. Lingkungan kerja sangat bervariasi menurut tim dan oleh individu. Beberapa pengembang lebih suka baris perintah, yang lain seperti Visual Studio, dan yang lain bekerja pada platform yang berbeda. Struktur dan kebijakan yang diberlakukan pada repositori Microsoft memastikan fondasi yang solid dan konsisten.
Alur kerja umum melibatkan tugas umum berikut:
Membangun fitur baru
Membangun fitur baru adalah inti dari pekerjaan pengembang perangkat lunak. Bagian non-Git dari proses termasuk melihat data telemetri, datang dengan desain dan spesifikasi, dan menulis kode aktual. Kemudian, pengembang mulai bekerja dengan repositori dengan menyinkronkan ke penerapan terbaru pada main. Cabang utama selalu dapat dibangun, sehingga dijamin menjadi titik awal yang baik. Pengembang memeriksa cabang fitur baru, membuat perubahan kode, menerapkan, mendorong ke server, dan memulai permintaan pull baru.
Menggunakan kebijakan dan pemeriksaan cabang
Setelah membuat permintaan pull, sistem otomatis memeriksa bahwa kode baru dibuat, tidak merusak apa pun, dan tidak melanggar kebijakan keamanan atau kepatuhan apa pun. Proses ini tidak memblokir pekerjaan lain agar tidak terjadi secara paralel.
Kebijakan dan pemeriksaan cabang dapat memerlukan build yang berhasil termasuk pengujian yang lulus, masuk oleh pemilik kode apa pun yang disentuh, dan beberapa pemeriksaan eksternal untuk memverifikasi kebijakan perusahaan sebelum permintaan pull dapat diselesaikan.
Mengintegrasikan dengan Microsoft Teams
Banyak tim mengonfigurasi integrasi dengan Microsoft Teams, yang mengumumkan permintaan pull baru kepada rekan tim pengembang. Pemilik kode apa pun yang disentuh secara otomatis ditambahkan sebagai peninjau. Tim Microsoft sering menggunakan peninjau opsional untuk kode yang disentuh banyak orang, seperti pembuatan klien REST dan kontrol bersama, untuk mendapatkan pandangan ahli tentang perubahan tersebut.
Menyebarkan dengan bendera fitur
Setelah peninjau, pemilik kode, dan otomatisasi terpenuhi, pengembang dapat menyelesaikan permintaan pull. Jika ada konflik penggabungan, pengembang mendapatkan instruksi tentang cara menyinkronkan ke konflik, memperbaikinya, dan mendorong kembali perubahan. Otomatisasi berjalan lagi pada kode tetap, tetapi manusia tidak perlu keluar lagi.
Cabang bergabung ke dalam main, dan kode baru disebarkan dalam sprint berikutnya atau rilis utama. Itu tidak berarti fitur baru akan segera muncul. Microsoft memisahkan penyebaran dan paparan fitur baru dengan menggunakan bendera fitur.
Bahkan jika fitur ini membutuhkan sedikit lebih banyak pekerjaan sebelum siap untuk ditunjukkan, aman untuk pergi ke main jika produk dibangun dan disebarkan. Setelah masuk , kode menjadi bagian dari build resmi, di mana kode tersebut kembali diuji main, dikonfirmasi untuk memenuhi kebijakan, dan ditandatangani secara digital.
Geser ke kiri untuk mendeteksi masalah lebih awal
Alur kerja Git ini memberikan beberapa manfaat. Pertama, bekerja di satu cabang utama secara virtual menghilangkan utang penggabungan. Kedua, alur permintaan pull menyediakan titik umum untuk memberlakukan pengujian, peninjauan kode, dan deteksi kesalahan di awal alur. Strategi shift kiri ini membantu mempersingkat siklus umpan balik kepada pengembang karena dapat mendeteksi kesalahan dalam hitungan menit, bukan jam atau hari. Strategi ini juga memberikan keyakinan untuk pemfaktoran ulang, karena semua perubahan diuji terus-menerus.
Saat ini, produk dengan 200+ permintaan pull dapat menghasilkan 300+ build integrasi berkelanjutan per hari, berjumlah 500+ pengujian berjalan setiap 24 jam. Tingkat pengujian ini tidak mungkin dilakukan tanpa alur kerja percabangan dan rilis berbasis batang.
Rilis pada tonggak pencapaian sprint
Di akhir setiap sprint, tim membuat cabang rilis dari cabang utama. Misalnya, di akhir sprint 129, tim membuat cabang releases/M129rilis baru . Tim kemudian menempatkan cabang sprint 129 ke dalam produksi.
Setelah cabang cabang rilis, cabang utama tetap terbuka bagi pengembang untuk menggabungkan perubahan. Perubahan ini akan menyebarkan tiga minggu kemudian dalam penyebaran sprint berikutnya.
Rilis perbaikan
Terkadang perubahan perlu pergi ke produksi dengan cepat. Microsoft biasanya tidak akan menambahkan fitur baru di tengah sprint, tetapi terkadang ingin membawa perbaikan bug dengan cepat untuk membuka blokir pengguna. Masalah mungkin kecil, seperti kesalahan ketik, atau cukup besar untuk menyebabkan masalah ketersediaan atau insiden situs langsung.
Memperbaiki masalah ini dimulai dengan alur kerja normal. Pengembang membuat cabang dari main, membuatnya ditinjau kode, dan menyelesaikan permintaan pull untuk menggabungkannya. Proses selalu dimulai dengan membuat perubahan terlebih main dahulu. Ini memungkinkan pembuatan perbaikan dengan cepat dan memvalidasinya secara lokal tanpa harus beralih ke cabang rilis.
Mengikuti proses ini juga menjamin bahwa perubahan masuk ke main, yang sangat penting. Memperbaiki bug di cabang rilis tanpa mengembalikan perubahan main berarti bug akan berulang selama penyebaran berikutnya, ketika sprint 130 merilis cabang dari main. Mudah untuk lupa memperbarui main selama kebingungan dan stres yang dapat muncul selama pemadaman. Membawa perubahan ke main yang pertama berarti selalu memiliki perubahan di cabang utama dan cabang rilis.
Fungsionalitas Git memungkinkan alur kerja ini. Untuk membawa perubahan segera ke dalam produksi, setelah pengembang menggabungkan permintaan pull ke , mainmereka dapat menggunakan halaman permintaan pull untuk memilih ceri perubahan ke cabang rilis. Proses ini membuat permintaan pull baru yang menargetkan cabang rilis, mendukung konten yang baru saja digabungkan ke dalam main.
Menggunakan fungsionalitas cherry-pick membuka permintaan pull dengan cepat, memberikan keterlacakan dan keandalan kebijakan cabang. Cherry-picking dapat terjadi di server, tanpa harus mengunduh cabang rilis ke komputer lokal. Membuat perubahan, memperbaiki konflik penggabungan, atau membuat perubahan kecil karena perbedaan antara kedua cabang semuanya dapat terjadi di server. Teams dapat mengedit perubahan langsung dari editor teks berbasis browser atau melalui Ekstensi Konflik Penggabungan Permintaan Pull untuk pengalaman yang lebih canggih.
Setelah permintaan pull menargetkan cabang rilis, kode tim meninjaunya lagi, mengevaluasi kebijakan cabang, menguji permintaan pull, dan menggabungkannya. Setelah penggabungan, perbaikan disebarkan ke cincin pertama server dalam hitungan menit. Dari sana, tim secara progresif menyebarkan perbaikan ke lebih banyak akun dengan menggunakan cincin penyebaran. Saat perubahan diterapkan ke lebih banyak pengguna, tim memantau keberhasilan dan memverifikasi bahwa perubahan memperbaiki bug sambil tidak memperkenalkan kekurangan atau perlambatan. Perbaikan akhirnya disebarkan ke semua pusat data Azure.
Lanjutkan ke sprint berikutnya
Selama tiga minggu ke depan, tim selesai menambahkan fitur ke sprint 130 dan bersiap untuk menyebarkan perubahan tersebut. Mereka membuat cabang rilis baru, releases/M130 dari main, dan menyebarkan cabang tersebut.
Pada titik ini, sebenarnya ada dua cabang dalam produksi. Dengan penyebaran berbasis cincin untuk membawa perubahan pada produksi dengan aman, cincin cepat mendapatkan perubahan sprint 130, dan server cincin lambat tetap pada sprint 129 sementara perubahan baru divalidasi dalam produksi.
Perbaikan perubahan di tengah penyebaran mungkin memerlukan perbaikan dua rilis yang berbeda, rilis sprint 129 dan rilis sprint 130. Tim mem-port dan menyebarkan perbaikan ke kedua cabang rilis. 130 cabang menyebar ulang dengan perbaikan ke cincin yang telah ditingkatkan. 129 cabang menyebarkan ulang dengan perbaikan ke cincin luar yang belum ditingkatkan ke versi sprint berikutnya.
Setelah semua cincin disebarkan, cabang sprint 129 lama ditinggalkan, karena setiap perubahan yang dibawa ke cabang sprint 129 sebagai perbaikan juga telah dibuat di main. Jadi, perubahan tersebut juga akan ada di releases/M130 cabang.
Ringkasan
Model alur rilis adalah inti dari bagaimana Microsoft berkembang dengan DevOps untuk memberikan layanan online. Model ini menggunakan strategi percabangan berbasis batang sederhana. Tetapi alih-alih menjaga pengembang tetap terjebak dalam antrean penyebaran, menunggu untuk menggabungkan perubahan mereka, alur rilis Microsoft memungkinkan pengembang terus bekerja.
Model rilis ini juga memungkinkan penyebaran fitur baru di seluruh pusat data Azure secara teratur, meskipun ukuran basis kode Microsoft dan jumlah pengembang yang bekerja di dalamnya. Model ini juga memungkinkan membawa perbaikan ke dalam produksi dengan cepat dan efisien.