Ringkasan Prasyarat dan batasan Arsitektur Alat Praktik terbaik Epik Pemecahan Masalah Sumber daya terkait

Menerapkan strategi percabangan Gitflow untuk lingkungan multi-akun DevOps

Mike Stephens, Stephen, Abhilash Vinod DiCato, dan Tim Wondergem, 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, Gitflow, dan GitHub Flow. 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 Gitflow 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. Gitflow hanyalah salah satu kemungkinan strategi percabangan yang dapat digunakan organisasi Anda. Seri dokumentasi ini juga mencakup model percabangan Trunk dan GitHub Flow. 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 Gitflow. 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.
(Opsional) Plugin Gitflow, diinstal.

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 cabang fitur melalui penerapan dalam produksi.

Kotak Punnett dari aktivitas Gitflow di setiap cabang dan lingkungan.

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

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 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.
(Opsional) Plugin Gitflow adalah kumpulan ekstensi Git yang menyediakan operasi repositori tingkat tinggi untuk model percabangan Gitflow.

Repositori kode

File sumber untuk diagram dalam pola ini tersedia dalam Strategi Percabangan GitHub Git untuk GitFlow repositori. 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 berbasis GitFlow secara efektif, mendorong kolaborasi, meningkatkan kualitas kode, dan merampingkan proses pengembangan.

Epik

Tugas	Deskripsi	Keterampilan yang dibutuhkan
Tinjau proses Gitflow standar.	Di lingkungan kotak pasir, pengembang membuat `feature` cabang dari `develop` cabang dan menggunakan pola `feature/<ticket>_<initials>_<short description>` penamaan. Pengembang mengembangkan kode dan menyebarkan kode ke lingkungan kotak pasir secara iteratif untuk menyelesaikan tiket. catatan Pengembang secara opsional dapat membuat `sandbox` cabang untuk menjalankan build otomatis atau deploy pipeline di lingkungan kotak pasir. Pengembang membuat permintaan gabungan dari `feature` cabang ke `develop` cabang dengan menggunakan gabungan squash. Pipa integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) secara otomatis membangun dan menyebarkan `develop` cabang ke lingkungan pengembangan. (Opsional) Pengembang mengintegrasikan `feature` cabang tambahan ke dalam cabang pengembangan sebelum melanjutkan aktivitas rilis. Ketika Anda siap untuk merilis fitur di `develop` cabang, pengembang membuat `release` cabang bernama `release/v<number>` dari `develop` cabang. Pengembang membangun cabang rilis, yang menerbitkan artefak untuk digunakan kembali di lingkungan lain. Penyetuju secara manual menyetujui penerapan artefak rilis ke lingkungan pengujian. Penyetuju secara manual menyetujui penerapan artefak rilis ke lingkungan pementasan. Penyetuju secara manual menyetujui penyebaran artefak rilis ke lingkungan produksi. Pengembang menggabungkan `release` cabang ke `main` cabang. Idealnya, pengembang menggunakan skrip otomatis untuk melakukan penggabungan maju cepat. Jangan gunakan gabungan squash. Pengembang menggabungkan `release` cabang ke `develop` cabang. Idealnya, pengembang menggunakan skrip otomatis untuk melakukan penggabungan maju cepat. Jangan gunakan gabungan squash.	DevOps insinyur
Tinjau proses Gitflow hotfix.	Pengembang membuat `hotfix` cabang dari `main` cabang dan menggunakan pola penamaan`hotfix/<ticket>_<initials>_<short description>`. Pengembang membuat `release` cabang dari `main` cabang dan menamainya`release/v<number>`. Pengembang memperbaiki masalah, melakukan perbaikan, dan membangun cabang. `hotfix` Pengembang membuat permintaan gabungan dari `hotfix` cabang ke `release/v<number>` cabang dengan menggunakan gabungan squash. Pengembang membangun `release` cabang, yang menerbitkan artefak untuk digunakan kembali di lingkungan lain. Penyetuju secara manual menyetujui penerapan artefak rilis ke lingkungan pengujian. Penyetuju secara manual menyetujui penerapan artefak rilis ke lingkungan pementasan. Penyetuju secara manual menyetujui penyebaran artefak rilis ke lingkungan produksi. Pengembang menggabungkan `release` cabang ke `main` cabang. Idealnya, pengembang menggunakan skrip otomatis untuk melakukan penggabungan maju cepat. Jangan gunakan gabungan squash. Pengembang menggabungkan `release` cabang ke `develop` cabang. Idealnya, pengembang menggunakan skrip otomatis untuk melakukan penggabungan maju cepat. Jangan gunakan gabungan squash. Jika konflik terdeteksi, pengembang menerima peringatan dan menyelesaikan konflik dengan permintaan gabungan.	DevOps insinyur
Tinjau proses Gitflow perbaikan bug.	Pengembang membuat `bugfix` cabang dari `release/v<number>` cabang saat ini dan menggunakan pola penamaan`bugfix/<ticket number>_<developer initials>_<descriptor>`. Pengembang memperbaiki masalah, melakukan perbaikan, dan membangun cabang. `bugfix` Pengembang membuat permintaan gabungan dari `bugfix` cabang ke `release/v<number>` cabang dengan menggunakan gabungan squash. Pengembang membangun `release` cabang, yang menerbitkan artefak untuk digunakan kembali di lingkungan lain. Penyetuju secara manual menyetujui penerapan artefak rilis ke lingkungan Pengujian. Pemberi persetujuan secara manual menyetujui penerapan artefak rilis ke lingkungan Stage. Pemberi persetujuan secara manual menyetujui penerapan artefak rilis ke lingkungan Produksi. Pengembang menggabungkan `release` cabang ke `main` cabang. Idealnya, pengembang menggunakan skrip otomatis untuk melakukan penggabungan maju cepat. Jangan gunakan gabungan squash. Pengembang menggabungkan `release` cabang ke `develop` cabang. Idealnya, pengembang menggunakan skrip otomatis untuk melakukan penggabungan maju cepat. Jangan gunakan gabungan squash. Jika konflik terdeteksi, pengembang menerima peringatan dan menyelesaikan konflik dengan permintaan gabungan.	DevOps insinyur

Pemecahan Masalah

Isu	Solusi
Konflik cabang	Masalah umum yang dapat terjadi dengan model Gitflow adalah di mana perbaikan terbaru perlu terjadi dalam produksi tetapi perubahan yang sesuai perlu terjadi di lingkungan yang lebih rendah, di mana cabang lain memodifikasi sumber daya yang sama. Kami menyarankan Anda hanya memiliki satu cabang rilis yang aktif pada satu waktu. Jika Anda memiliki lebih dari satu aktif pada satu waktu, perubahan lingkungan mungkin bertabrakan, dan Anda mungkin tidak dapat memindahkan cabang ke produksi.
Penggabungan	Rilis harus digabungkan kembali ke main dan dikembangkan sesegera mungkin untuk mengkonsolidasikan pekerjaan kembali ke cabang utama.
Penggabungan squash	Hanya gunakan gabungan squash saat Anda menggabungkan dari `feature` cabang ke cabang. `develop` Menggunakan penggabungan squash di cabang yang lebih tinggi menyebabkan kesulitan saat menggabungkan perubahan kembali ke cabang yang lebih rendah.

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 Gitflow Anda di. AWS Cloud

AWS DevOps bimbingan

Panduan Gitflow