Pertanyaan Strategi bercabang dengan maven, teamcity dan TFS


Saya telah ditugaskan untuk memperbarui proses pembangunan kami sekarang untuk menjadi lebih efisien dan saya telah menghabiskan seminggu membaca praktik terbaik dan strategi tetapi saya masih belum menemukan solusi untuk masalah kami saat ini.

Latar Belakang

Saat ini kami memiliki satu aplikasi / aplikasi monolitik yang benar-benar perlu dipisah menjadi setidaknya 4 aplikasi dengan beberapa pustaka bersama. Kami saat ini tidak bercabang kecuali kami benar-benar harus. Kami memiliki build teamcity yang dibangun di setiap check-in ke TFS. Ketika kami siap untuk rilis, kami memiliki pembekuan kode dan hanya perbaikan check-in untuk bug yang ditemukan di QA. Tentunya ini adalah praktik yang mengerikan dan akhirnya kita mendapat persetujuan untuk mengubahnya.

Usulan Solusi

Solusi yang diusulkan adalah membagi aplikasi dan memiliki siklus rilis yang berbeda untuk setiap aplikasi, berpindah dari semut ke maven dan cabang per rilis.

Bercabang - Saat ini kami hanya memiliki batang utama di kontrol sumber. Saya pikir kita ingin bercabang dari batang ketika kita siap untuk rilis, dan memperbarui cabang untuk bug yang ditemukan di QA. Ketika build siap dilepaskan, gabungkan ranting kembali ke bagasi.

Berikut adalah bagaimana saya berencana menyiapkan TFS.

+Apps
    +App1
        +Components
            +Core
            +Web
        +Branches
    +App2
        +Components
            +Core
            +Web
        +Branches
    +Libraries
        +Lib1
        +Lib2
        +Branches

Berpikir tentang mengelola semua POM dan versi di POM sepertinya terlalu sulit saat ini. Saya sudah membaca tentang plugin rilis maven, tapi saya tidak yakin apakah itu bisa bercabang menurut cara saya berpikir kita mau.

Masalah selanjutnya adalah mendapatkan kerja tim. Saya berpikir untuk memiliki 3 proyek timcity untuk setiap aplikasi. Sebuah proyek dev yang selalu menunjuk pada koper, proyek QA untuk menguji QA build dan proyek produksi untuk membuat perubahan untuk hotfix. Setiap kali rilis baru datang ke QA, saya harus memperbarui proyek timkualitas QA untuk menunjuk pada cabang rilis baru dan memperbarui nomor rilis rilis dalam tim. Ketika rilis itu melewati QA saya harus memperbarui proyek teamcity produksi untuk menunjukkan bahwa cabang yang baru saja lulus QA dan memperbarui nomor build ke nomor build yang baru saja lulus QA.

Tentunya ada strategi yang lebih baik dari ini.

Pertanyaan

Di mana saya harus meletakkan folder cabang ini?

Haruskah QA dibangun menjadi snapshot hingga build berjalan ke pra-produksi?

Bagaimana Anda mengkonfigurasi tim untuk mengambil cabang-cabang ini tanpa mengubah jalur sumber untuk setiap rilis?

Haruskah ada induk POM untuk setiap aplikasi yang digunakan pengembang untuk memastikan semua dependensi mereka dikompilasi dan diperbarui?


5
2017-12-08 15:34


asal


Jawaban:


Saya hanya ingin mempertanyakan pemikiran Anda bahwa aplikasi Anda harus berada pada siklus rilis yang berbeda. Modularisasi adalah hal yang baik untuk kualitas kode tetapi jika modul Anda berada pada siklus rilis terpisah Anda memperkenalkan banyak overhead. Secara khusus, manajemen versi menjadi cukup membebani dan jika Anda salah, Anda dapat memperkenalkan bug runtime.

Bagaimana aplikasi terpisah ini berhubungan satu sama lain? Apakah ada ketergantungan di antara mereka (mungkin melalui perpustakaan bersama)? Apakah mereka berkomunikasi satu sama lain? Apakah mereka dikerahkan bersama?

Jika tidak perlu bahwa mereka berada di siklus rilis terpisah maka Anda mungkin lebih baik menjaga mereka bersama.


0
2018-01-17 17:28