Bagikan melalui

Memilih strategi percabangan dengan pola pikir DevOps

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Apakah Anda berencana untuk merangkul DevOps menggunakan Team Foundation Version Control (TFVC) dengan Azure DevOps? Anda mungkin memiliki beberapa pertanyaan, seperti:

  • Bagaimana cara memutuskan strategi percabangan yang tepat?
  • Apakah ada strategi yang efektif untuk DevOps?
  • Bagaimana cara mendukung aplikasi dengan satu atau beberapa versi?

TFVC adalah sistem kontrol versi terpusat untuk mempertahankan kode dan membuat tim lebih efektif. Ini menyediakan fitur kolaborasi dan berbagi kode yang konsisten, penerbitan, dan peninjauan.

Tetap sederhana!

Dengan mengadopsi strategi percabangan yang efektif, Anda akan:

  • Menumbuhkan budaya DevOps
  • Mempromosikan alur kolaborasi dan meningkatkan produktivitas
  • Memungkinkan tim untuk menghabiskan lebih banyak waktu untuk mengembangkan dan lebih sedikit waktu mengelola kode

Untuk merangkul DevOps, penting untuk menjaga strategi cabang Anda tetap sederhana dan berusaha untuk kualitas tinggi. Beberapa saran:

  • Mulailah dengan strategi sederhana dan berevolusi sesuai kebutuhan
  • Menggunakan konvensi penamaan yang konsisten untuk cabang
    • fitur/nama pengguna/deskripsi untuk pekerjaan yang dilakukan oleh individu - contoh, fitur/sandra/sdk-java
    • bugfix/username/bugid untuk pekerjaan yang dilakukan khusus untuk bug rekayasa - misalnya, bugfix/takashi/707
    • rilis/versi untuk rilis yang direncanakan - contoh, rilis/V1.00
  • Sering berintegrasi terbalik (RI) dan bergabung ke cabang utama Anda
  • Mendorong tinjauan kode yang konsisten - sampah masuk, sampah habis
  • Terapkan alur CI/CD, menggunakan:

Mulailah dengan strategi percabangan sederhana

Buat struktur kontrol sumber yang mengidentifikasi unit rilis yang dapat dikirim. Konsep unit yang dapat dilepaskan adalah bagian dasar dari strategi ini, yang digambarkan Steve St Jean sebagai berikut:

  • Unit fisik penerapan versi dan pengiriman.
  • Unit utama untuk mendukung model percabangan dan rilis.
  • Dapat berada di tingkat Suite, Aplikasi, atau Komponen.
  • Untuk Suite, semua aplikasi harus versi dan patch bersama-sama. Misalnya, Microsoft Word dan Excel adalah bagian dari Microsoft Office Suite. Visio tidak, karena mungkin merilis atau menambal independen dari Microsoft Office Suite lainnya.
  • Di TFVC, ini akan menjadi simpul akar di bawah simpul proyek tim.
  • Dapat disamakan dengan repositori di Git

Anda biasanya mulai dengan hanya harus mendukung satu versi produksi, dengan koreksi cacat paralel dan pengembangan fitur baru. Contoh umumnya termasuk situs web, aplikasi lini bisnis perusahaan, dan alat sementara.

Mulailah dengan strategi percabangan utama yang sederhana.

diagram cabang awal

Otomatiskan build Anda untuk memicu setiap pemeriksaan ke cabang utama, jalankan pengujian otomatis, dan jika berhasil, sebarkan rilis ke lingkungan pengembangan (dev).

Cabang Build Lingkungan Catatan
Utama CI_Bld Dev Dipicu dengan setiap cek ke utama

Saat Anda menyelesaikan siklus rilis, buat cabang rilis . Gunakan cabang rilis untuk menstabilkan rilis, dan melanjutkan pengembangan untuk versi berikutnya di utama. Integrasi terbalik (RI) dan gabungkan perbaikan bug yang divalidasi dengan cabang utama Anda secara sering, untuk meminimalkan utang teknis Anda secara keseluruhan.

Versi 1.0 dirilis

Otomatiskan build dan rilis Anda ke:

  • Pemicu dengan setiap cek masuk ke cabang rilis
  • Jalankan pengujian otomatis
  • Menyebarkan ke pengembangan Anda dan lingkungan lainnya
Cabang Build Pipelines Catatan
Utama CI_Bld Dev Dipicu dengan setiap cek ke utama
V1.00 RC_Bld Dev -> QA -> UAT -> Penahapan -> Prod Dipicu dengan setiap cek untuk dirilis

Ketika versi 2 menjadi Kandidat Rilis, Anda dapat memperbarui alur build RC yang ada untuk menunjuk ke cabang V2.00. Sekarang akan membangun dan merilis seperti yang dilakukan V1.00 ketika itu adalah versi saat ini.

Cabang Build Pipelines Catatan
Utama CI_Bld Dev Dipicu dengan setiap cek ke utama
V2.00 RC_Bld Dev -> QA -> UAT -> Penahapan -> Prod Dipicu dengan setiap cek untuk dirilis
V1.00 Hotfix_Bld Perbaikan -> Penahapan -> Prod Dipicu dengan setiap cek ke perbaikan

Perluas strategi pencabangan sesuai kebutuhan

Ketika kebutuhan muncul untuk mendukung lebih dari satu versi produksi, misalnya solusi komersial seperti Word, Anda dapat memperluas strategi percabangan Anda.

Untuk setiap siklus rilis yang selesai yang perlu Anda dukung, buat cabang rilis baru dan lanjutkan pengembangan versi berikutnya di utama, menggunakan isolasi fitur. Perhatikan integrasi terbalik (RI) bergabung dari v1.0 dan v2.0 ke utama. Mereka mewakili perbaikan bug yang dirilis ke produksi.

Versi 2.0 dirilis

Dengan menggunakan strategi percabangan sederhana dan mengadopsi konvensi penamaan yang konsisten, Anda akan dapat mendukung:

  • Aplikasi yang memiliki satu atau beberapa rilis yang didukung
  • Pengembangan berkelanjutan fitur baru
  • Pengiriman nilai berkelanjutan kepada pengguna Anda

Daftar periksa dan pelajaran dari bidang

Daftar periksa

  • Pertahankan sederhana dan perluas kompleksitas percabangan sesuai kebutuhan
  • Atur kode Anda ke dalam unit yang dapat dikirim
  • Gunakan strategi penamaan yang konsisten untuk cabang Anda
  • Bangun dengan setiap check-in
  • Membuat alur CI/CD menggunakan cek masuk terjaga dan pengujian otomatis

Pelajaran dari lapangan - hal-hal yang harus dihindari

  • Hindari memiliki terlalu banyak cabang!
    • penggabungan perubahan dilengkapi dengan kompleksitas dan biaya
    • tidak perlu memiliki cabang terpisah per lingkungan
  • Hindari menggunakan pemilihan ceri untuk mendapatkan kode Anda ke produksi
  • Jangan mencoba memecahkan masalah orang atau memproses dengan alat