Menerapkan strategi percabangan GitHub Flow untuk lingkungan multi-akun DevOps - AWS Prescriptive Guidance
RingkasanPrasyarat dan batasanArsitekturAlatPraktik terbaikEpikPemecahan MasalahSumber daya terkait

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menerapkan strategi percabangan GitHub Flow untuk lingkungan multi-akun DevOps

Mike Stephens dan Abhilash Vinod, Amazon Web Services

Ringkasan

Saat mengelola repositori kode sumber, strategi percabangan yang berbeda memengaruhi pengembangan perangkat lunak dan proses rilis yang digunakan tim pengembangan. Contoh strategi percabangan umum termasuk Trunk, GitHub Flow, dan Gitflow. Strategi-strategi ini menggunakan cabang yang berbeda, dan kegiatan yang dilakukan di setiap lingkungan berbeda. Organizations yang menerapkan DevOps proses akan mendapat manfaat dari panduan visual untuk membantu mereka memahami perbedaan antara strategi percabangan ini. Menggunakan visual ini di organisasi Anda membantu tim pengembangan menyelaraskan pekerjaan mereka dan mengikuti standar organisasi. Pola ini memberikan visual ini dan menjelaskan proses penerapan strategi percabangan GitHub Flow di organisasi Anda.

Pola ini merupakan bagian dari rangkaian dokumentasi tentang memilih dan menerapkan strategi DevOps percabangan untuk organisasi dengan banyak Akun AWS. Seri ini dirancang untuk membantu Anda menerapkan strategi dan praktik terbaik yang benar sejak awal, untuk merampingkan pengalaman Anda di cloud. GitHub Flow hanyalah salah satu strategi percabangan yang mungkin dapat digunakan organisasi Anda. Seri dokumentasi ini juga mencakup model percabangan Trunk dan Gitflow. Jika Anda belum melakukannya, kami sarankan Anda meninjau Memilih strategi percabangan Git untuk DevOps lingkungan multi-akun sebelum menerapkan panduan dalam pola ini. Harap gunakan uji tuntas untuk memilih strategi percabangan yang tepat untuk organisasi Anda.

Panduan ini menyediakan diagram yang menunjukkan bagaimana organisasi dapat menerapkan strategi GitHub Flow. Disarankan agar Anda meninjau Panduan AWS DevOps Well-Architected untuk meninjau praktik terbaik. Pola ini mencakup tugas, langkah, dan batasan yang direkomendasikan untuk setiap langkah dalam DevOps proses.

Prasyarat dan batasan

Prasyarat

  • Git, diinstal. Ini digunakan sebagai alat repositori kode sumber.

  • Draw.io, diinstal. Aplikasi ini digunakan untuk melihat dan mengedit diagram.

Arsitektur

Arsitektur target

Diagram berikut dapat digunakan seperti kotak Punnett (Wikipedia). Anda menyusun cabang pada sumbu vertikal dengan AWS lingkungan pada sumbu horizontal untuk menentukan tindakan apa yang harus dilakukan dalam setiap skenario. Angka-angka menunjukkan urutan tindakan dalam alur kerja. Contoh ini membawa Anda dari feature cabang melalui penerapan dalam produksi.

Punnett square dari aktivitas GitHub Flow di setiap cabang dan lingkungan.

Untuk informasi selengkapnya tentang Akun AWS, lingkungan, dan cabang dalam pendekatan GitHub Flow, lihat Memilih strategi percabangan Git untuk lingkungan multi-akun DevOps .

Otomatisasi dan skala

Integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) is the process of automating the software release lifecycle. It automates much or all of the manual processes traditionally required to get new code from an initial commit into production. A CI/CD pipeline encompasses the sandbox, development, testing, staging, and production environments. In each environment, the CI/CD pipeline provisions any infrastructure that is needed to deploy or test the code. By using CI/CD, development teams can make changes to code that are then automatically tested and deployed. CI/CDjaringan pipa juga menyediakan tata kelola dan pagar pembatas untuk tim pengembangan dengan menegakkan konsistensi, standar, praktik terbaik, dan tingkat penerimaan minimal untuk penerimaan dan penerapan fitur. Untuk informasi selengkapnya, lihat Mempraktikkan Integrasi Berkelanjutan dan Pengiriman Berkelanjutan di AWS.

AWS menawarkan serangkaian layanan pengembang yang dirancang untuk membantu Anda membangun CI/CD jaringan pipa. Misalnya, AWS CodePipelineadalah layanan pengiriman berkelanjutan yang dikelola sepenuhnya yang membantu Anda mengotomatiskan saluran pipa rilis untuk pembaruan aplikasi dan infrastruktur yang cepat dan andal. AWS CodeBuildmengkompilasi kode sumber, menjalankan tes, dan menghasilkan paket ready-to-deploy perangkat lunak. Untuk informasi selengkapnya, lihat Alat Pengembang di AWS.

Alat

AWS layanan dan alat

AWS menyediakan serangkaian layanan pengembang yang dapat Anda gunakan untuk menerapkan pola ini:

  • AWS CodeArtifactadalah layanan repositori artefak terkelola yang sangat skalabel yang membantu Anda menyimpan dan berbagi paket perangkat lunak untuk pengembangan aplikasi.

  • AWS CodeBuildadalah layanan build terkelola penuh yang membantu Anda mengkompilasi kode sumber, menjalankan pengujian unit, dan menghasilkan artefak yang siap digunakan.

  • AWS CodeDeploymengotomatiskan penerapan ke Amazon Elastic Compute Cloud (Amazon EC2) atau instans, fungsi AWS Lambda , atau layanan Amazon Elastic Container Service (Amazon ECS) atau lokal.

  • AWS CodePipelinemembantu Anda dengan cepat memodelkan dan mengkonfigurasi berbagai tahapan rilis perangkat lunak dan mengotomatiskan langkah-langkah yang diperlukan untuk merilis perubahan perangkat lunak secara terus menerus.

Alat-alat lainnya

  • Draw.io Desktop adalah aplikasi untuk membuat diagram alur dan diagram. Repositori kode berisi template dalam format.drawio untuk Draw.io.

  • Figma adalah alat desain online yang dirancang untuk kolaborasi. Repositori kode berisi template dalam format.fig untuk Figma.

Repositori kode

File sumber untuk diagram dalam pola ini tersedia di GitHub Git Branching Strategy for GitHub Flow repository. Ini termasuk file dalam format PNG, draw.io, dan Figma. Anda dapat memodifikasi diagram ini untuk mendukung proses organisasi Anda.

Praktik terbaik

Ikuti praktik dan rekomendasi terbaik dalam Panduan AWS DevOps Well-Architected dan Memilih strategi percabangan Git untuk lingkungan multi-akun. DevOps Ini membantu Anda menerapkan pengembangan GitHub berbasis Flow secara efektif, mendorong kolaborasi, meningkatkan kualitas kode, dan merampingkan proses pengembangan.

Epik

TugasDeskripsiKeterampilan yang dibutuhkan

Tinjau proses GitHub Flow standar.

  1. Di lingkungan kotak pasir, pengembang membuat feature cabang dari main cabang dan menggunakan pola feature/<ticket>_<initials>_<short description> penamaan.

  2. Pengembang menambahkan satu atau lebih komit ke feature cabang, masing-masing mewakili perubahan atau peningkatan diskrit.

  3. Pengembang membuka permintaan gabungan (MR) untuk menggabungkan perubahan ke cabang. main Ini memulai proses peninjauan.

  4. Selama proses peninjauan, pengembang mendiskusikan perubahan kode dan memberikan umpan balik. Tujuannya adalah untuk memastikan bahwa perubahannya berkualitas tinggi dan memenuhi standar proyek.

  5. Setelah pengembang membuat permintaan gabungan, proses pembuatan otomatis dimulai dan menerapkan perubahan di feature cabang ke lingkungan pengembangan.

  6. Pengujian otomatis memverifikasi integritas dan kualitas perubahan yang dienkapsulasi dalam permintaan gabungan. Pembuatan yang berhasil, penerapan yang berhasil, dan pengujian yang berhasil diperlukan untuk menyelesaikan permintaan penggabungan.

  7. Ketika proses peninjauan selesai, perubahan digabungkan ke dalam main cabang.

  8. Penyetuju secara manual menyetujui penerapan artefak rilis ke lingkungan pengujian.

  9. Penyetuju secara manual menyetujui penerapan artefak rilis ke lingkungan pementasan.

  10. Penyetuju secara manual menyetujui penyebaran artefak rilis ke lingkungan produksi.

DevOps insinyur

Tinjau proses GitHub Alur perbaikan bug.

  1. Pengembang membuat bugfix cabang dari main cabang dan menggunakan pola penamaanbugfix/<ticket number>_<developer initials>_<descriptor>.

  2. Pengembang memperbaiki masalah, melakukan perbaikan, dan membangun cabang. bugfix

  3. Pengembang membuka permintaan gabungan untuk menggabungkan bugfix cabang ke cabang. main Ini memulai proses peninjauan.

  4. Selama proses peninjauan, pengembang mendiskusikan perubahan kode dan memberikan umpan balik.

  5. Setelah peninjauan selesai dan disetujui, pengembang menyelesaikan permintaan penggabungan bugfix cabang ke cabang. main

  6. Penyetuju secara manual menyetujui penerapan artefak rilis ke lingkungan yang lebih tinggi.

DevOps insinyur

Tinjau proses GitHub Flow hotfix.

GitHub Flow dirancang untuk memungkinkan pengiriman berkelanjutan, di mana perubahan kode sering dan andal digunakan ke lingkungan yang lebih tinggi. Kuncinya adalah bahwa setiap feature cabang dapat diterapkan kapan saja.

Hotfixcabang, yang mirip dengan feature atau bugfix cabang, dapat mengikuti proses yang sama seperti salah satu cabang lainnya. Namun, mengingat urgensinya, hotfix biasanya memiliki prioritas yang lebih tinggi. Bergantung pada kebijakan tim dan kedekatan situasi, langkah-langkah tertentu dalam proses dapat dipercepat. Misalnya, ulasan kode untuk perbaikan terbaru mungkin dilacak dengan cepat. Oleh karena itu, sementara proses perbaikan terbaru sejajar dengan fitur atau proses perbaikan bug, urgensi seputar perbaikan terbaru dapat memerlukan modifikasi dalam kepatuhan prosedural. Sangat penting untuk menetapkan pedoman tentang mengelola perbaikan terbaru untuk memastikan bahwa mereka ditangani secara efisien dan aman.

DevOps insinyur

Pemecahan Masalah

IsuSolusi

Konflik cabang

Masalah umum yang dapat terjadi dengan model GitHub Flow adalah di mana perbaikan terbaru perlu terjadi dalam produksi tetapi perubahan yang sesuai perlu terjadi difeature,bugfix, atau hotfix cabang di mana sumber daya yang sama sedang dimodifikasi. Kami menyarankan agar Anda sering menggabungkan perubahan dari main cabang yang lebih rendah untuk menghindari konflik yang signifikan saat Anda bergabung. main

Kedewasaan tim

GitHub Flow mendorong penyebaran harian ke lingkungan yang lebih tinggi, merangkul integrasi berkelanjutan sejati dan pengiriman berkelanjutan (CI/CD). Sangat penting bahwa tim memiliki kematangan teknik untuk membangun fitur dan membuat tes otomatisasi untuk mereka. Tim harus melakukan peninjauan permintaan gabungan lengkap sebelum perubahan disetujui. Ini menumbuhkan budaya teknik yang kuat yang mempromosikan kualitas, akuntabilitas, dan efisiensi dalam proses pengembangan.

Sumber daya terkait

Panduan ini tidak termasuk pelatihan untuk Git; namun, ada banyak sumber daya berkualitas tinggi yang tersedia di internet jika Anda memerlukan pelatihan ini. Kami menyarankan Anda memulai dengan situs dokumentasi Git.

Sumber daya berikut dapat membantu Anda dengan perjalanan percabangan GitHub Flow Anda di. AWS Cloud

AWS DevOps bimbingan

GitHub Panduan aliran

Sumber daya lainnya