Untuk versi berbasis cabang, kita perlu berbicara tentang diagram berikut, yang dengan sempurna menggambarkan panorama proses manajemen konfigurasi. Pertama-tama, diagram ini ditulis berdasarkan model Git, tetapi pada kenyataannya, Git dan Subversion telah menemukan konsep manajemen kontrol versi, tetapi Git memang membuat lompatan kualitatif ke depan daripada Subversion dalam manajemen cabang dan kinerja terdistribusi (tetapi ini bukan fokus artikel ini).
Sebelum memperkenalkan prinsip grafik ini, mari kita bicara tentang dua strategi berbeda untuk kontrol versi umum, satu adalah "tulang punggung perintis, cabang stabil", dan yang lainnya adalah "tulang punggung stabil, cabang perintis". Seperti namanya, ini adalah versi stabil (versi produksi), di batang atau di cabang. Dalam kasus tim proyek tradisional yang menggunakan VSS, sulit untuk mengatakan mode mana yang dimilikinya, terutama karena VSS sendiri tidak memiliki strategi manajemen cabang, sehingga banyak tim proyek membuat dua pustaka versi (atau tiga) masing-masing, sesuai dengan lingkungan produksi dan lingkungan pengembangan, tentu saja, ini juga merupakan semacam manajemen cabang yang terselubung. Namun, jika Anda beralih ke Subversion atau Git sebagai alat kontrol versi, sebagian besar tim menggunakan mode trunk stabil, yaitu, trunk (truk atau master) sesuai dengan lingkungan produksi yang stabil, dan menandai rilis yang berbeda untuk menunjukkan versi produksi. Secara pribadi, saya pikir pola kode tulang punggung yang stabil harus menjadi solusi manajemen kontrol versi kode arus utama mutlak saat ini. Gambar di atas adalah model manajemen "tulang punggung stabil" standar.
master: Subversion yang sesuai adalah truk。 Sesuai dengan versi produksi, itu ditandai sekali setiap rilis.
Cabang rilis (juga dikenal sebagai cabang integrasi): Selama produksi diperbarui, itu perlu digabungkan ke cabang rilis (cabang integrasi) terlebih dahulu. Ini agak mirip dengan apa yang saat ini disebut tim proyek sebagai konsep "pra-produksi" dan "lingkungan simulasi".
mengembangkan cabang (cabang pengembang atau cabang pengembang): Lingkungan yang dihadapi oleh lingkungan pembangunan.
cabang fitur (cabang fitur): Beberapa fungsi independen dapat dipisahkan dari cabang pengembangan terpisah. Ini terutama untuk menangani fakta bahwa beberapa fitur mungkin membutuhkan waktu yang relatif lama untuk diperbarui, agar tidak menyeret rilis dan cabang terpisah.
cabang hotfixes (cabang perbaikan bug): Bug di sini terutama adalah bug produksi.
Setelah memperkenalkan batang dan cabang, saya perlu memperkenalkan arah generasi dan penggabungan cabang-cabang ini.
master adalah versi produksi, dan trunk hanya menerima dua cabang untuk penggabungan, satu adalah cabang rilis (cabang integrasi) dan yang lainnya adalah cabang hotfixes. Tidak ada cabang lain yang dapat digabungkan ke dalam cabang produksi.
Cabang rilis awalnya dibuat bersamaan dengan produksi, yang persis sama dengan produksi. Dia hanya menerima cabang dev untuk bergabung dengannya. Dengan kata lain, dia tidak menerima penggabungan langsung dari cabang fitur atau cabang perbaikan bug.
Cabang dev, cabang pengembangan, seperti cabang integrasi, sama dengan lingkungan produksi pada titik waktu tertentu. Namun, seiring berjalannya pengembangan, fitur baru akan terus dibuat di cabang pengembang. Dev Theory hanya menerima penggabungan dua cabang, satu adalah hotfix dan yang lainnya adalah cabang fitur.
cabang fitur, dimulai pada titik tertentu (versi) dengan cabang dev, cabang fitur pada akhirnya akan bergabung dengan cabang dev.
Mari kita perkenalkan secara singkat metode kontrol versi dalam bentuk skenario
Misalkan versi produksi dibagi menjadi beberapa cabang (dev, hotfixes, release), dan saat ini, dev mulai mengembangkan total sepuluh fungsi. Ketika 8 dari 10 fitur dikembangkan, tim pengujian mulai melakukan intervensi untuk pengujian internal, dan administrator konfigurasi menyebarkan cabang pengembang ke lingkungan pengembang untuk pengujian melalui alat integrasi berkelanjutan (topik terpisah di sini). Ketika verifikasi pengujian menemukan bahwa dua fungsi sama sekali tidak dapat diterima dan perlu dilakukan ulang, seperti asuransi asuransi sederhana dan pengembalian klaim, dua cabang fitur dipisahkan dari dev, sesuai dengan asuransi asuransi sederhana dan pengembalian dana klaim, dan pada cabang dev, kode yang sesuai juga perlu diputar kembali (operasi manual di sini). Ketika tim pengujian menemukan bahwa tidak ada masalah dengan pengujian cabang pengembang, pengujian tersebut memenuhi persyaratan UAT, sehingga administrator konfigurasi menggabungkan cabang pengembang ke cabang rilis, lalu menggunakan alat integrasi berkelanjutan untuk menerbitkan cabang ini ke lingkungan pra-produksi dan menyerahkannya kepada pengguna untuk pengujian. Ketika verifikasi pengguna menemukan masalah, pengembang memodifikasi cabang pengembang, lalu menggabungkannya ke cabang rilis (di sini, pada gambar aslinya, langsung dimodifikasi di cabang rilis, menurut saya ini tidak baik, saya sarankan agar pengembang hanya menghadapi cabang pengembang), ketika proses verifikasi rilis verifikasi tiba-tiba menemukan bahwa ada bug serius di lingkungan build yang perlu segera diperbaiki, maka segera dimodifikasi di cabang hotfixes, dan segera diluncurkan setelah memverifikasi bahwa itu benar. Pada saat yang sama, cabang hotfixes digabungkan dengan dev (di sini sebagian besar manual, karena saat ini versi produksi sudah sangat berbeda dari versi dev, dan seringkali tidak mungkin untuk menyelesaikan penggabungan otomatis), dan kemudian dev digabungkan ke dalam rilis. Setelah jangka waktu tertentu, fungsi pengembalian klaim mungkin tidak lagi diperlukan dan perlu dibatalkan, sehingga cabang fitur pengembalian klaim akan dihapus. Fitur lain mudah diasuransikan dan telah dikembangkan dan digabungkan ke cabang dev lagi untuk ditayangkan dengan versi online berikutnya.
Skenario di atas pada dasarnya mencakup pengembangan rutin, pembongkaran, pembaruan darurat, dan skenario lainnya dalam proses pengembangan harian.
|
Diposting pada 08/04/2018 10.25.39
|
|
|
|
