Pola untuk Integrasi Berkelanjutan dan DVCS

12

Saat ini kami menggunakan Subversion dan TeamCity, kami akan beralih menggunakan Mercurial (khusus Kiln karena kami pengguna FogBugz).

Jelas ini akan menghasilkan perubahan - semoga perbaikan - dalam pola pengembangan kami (kami berdua!) Tapi satu masalah yang saya hadapi adalah bagaimana menyusun hal-hal sehingga kami masih menikmati manfaat integrasi berkelanjutan / server CI kami ( bahwa ada dan akan tetap bermanfaat, diberikan, diskusi yang berada di luar ruang lingkup pertanyaan ini ).

Dengan SVN kami berkomitmen untuk sejumlah repositori sentral - efektif satu per proyek (kurang lebih satu Visual Studio Solution) sehingga mudah untuk memicu pembangunan dan untuk mendapatkan kepastian bahwa semua file telah dikomit dan tidak ada dependensi menyimpang dll, dll. Tetapi jika kita akan mengambil keuntungan yang tepat dari mercurial kita akan ingin memiliki lebih banyak contoh repositori - di mana saya berharap perubahan pada umumnya mengalir menuju repo "live" yang definitif. Masalah yang saya perjuangkan adalah bahwa repo langsung bagi saya terlalu "terlambat" untuk memicu pembangunan CI saya OTOH satu pembangunan CI per proyek per pengembang mungkin berlebihan (dan menyebabkan masalah lain).

Saya memancing sedikit tapi itu karena salah satu hal yang repo pusat memberikan satu (saya, dengan setup kami!) Banyak kejelasan tentang apa yang harus dibangun kapan.

nb Saya tidak bertanya tentang mekanisme penggunaan lincah dengan integrasi terus menerus - Saya memiliki pekerjaan yang memperlakukan untuk proyek pribadi, pola dan strukturnya dan praktik kerja / alur kerja yang saya coba untuk menyelesaikannya.

continuous-integration dvcs

— Murph
sumber

Menurut Anda mengapa sudah terlambat untuk memicu bangunan dari repo pusat / "langsung"?

— c_maker

Jika Anda belum pernah ke sana, saya sarankan Anda pergi ke situs pertukaran tumpukan Kiln ( kiln.stackexchange.com ). Mereka memiliki sedikit konten tentang cara mengatur ini (ini satu: kiln.stackexchange.com/questions/29/… . Secara pribadi, kami menggunakan cabang per fitur, dan arahkan server build di cabang "master" kami. )

— Chris Phillips

@ Chris - Saya punya, sebenarnya tidak ada, tidak menangani masalah CI ...

— Murph

2

Pertama, memiliki beberapa build per proyek di TeamCity benar-benar cara untuk pergi. Sifat platform membuatnya sangat mudah - tombol salin ada karena suatu alasan.

Bagaimanapun, ketika kami berada di SVN, kami biasanya menjalankan 2 build untuk setiap proyek - satu menunjuk ke jalur pengembangan utama (dalam kasus kami bagasi) dan satu menunjuk ke cabang rilis kami. Kami membawa pengaturan build ini ke HG sambil mengikuti model percabangan yang serupa dengan yang ini . Hanya tantangan nyata yang menemukan schwea funk baru tentang nomor bangunan sekarang karena kami tidak bisa lagi menggunakan nomor revisi SVN saat ini.

Kami mencoba dan mendorong orang untuk mendorong secara relatif sering, terutama ketika ada banyak pekerjaan yang terjadi sekaligus dan kami ingin siklus umpan balik yang lebih cepat. Hanya karena DCVS tidak berarti Anda hanya perlu mendorong sekali sehari atau sesuatu.

— Wyatt Barnett
sumber

Wyatt, menurut saya, dorongan harus terjadi ketika Anda memiliki unit kerja yang lengkap (ish) - salah satu manfaat dari DVCS adalah bahwa kita dapat melakukan, secara lokal, kode yang rusak. Saya benar- benar tidak menyukai gagasan melakukan sesuatu sesuai jadwal karena ini adalah akhir dari hari itu. Ada masalah terpisah "cadangan", yang - bagi saya - adalah tentang menyiapkan aturan untuk mendorong ke samping - saat berkomitmen - ke klon lain yang ada hanya untuk menjadi cadangan.

— Murph

2

Trik ada apa definisi unit kerja? Apakah itu "fitur ini selesai" atau apakah "bata ini berhasil diletakkan". Kita cenderung ke arah yang terakhir, terutama dengan model percabangan di mana ada cabang pembangunan yang jelas-jelas terdeliniasi. Memecah barang sebaiknya diserahkan ke cabang fitur. Yang sudah berjalan lama dari mereka bisa mendapatkan CI juga jika memungkinkan. Terutama jika ada banyak koki di dapur.

— Wyatt Barnett

Saya setuju dengan definisi Anda tentang "unit kerja" yang mengapa saya sedikit berjuang dengan model keseluruhan saya (yang sudah memiliki beberapa build per proyek untuk mengakomodasi kedua build "CI" dan build "deployment"). Anda benar, jawabannya adalah untuk memasang banyak bangunan sehingga pada akhirnya masalah saya yang sebenarnya akan mendapatkan cek ditandatangani! Model percabangan yang direferensikan terlihat benar juga. Masih mempertimbangkan pola keseluruhan (dan memungkinkan yang akan disesuaikan lebih lanjut untuk memungkinkan spesifik kilnhg)

— Murph

2

Kami telah menggunakan Kiln selama sekitar satu tahun sekarang dan telah mencoba beberapa hal berbeda. Di mana kami telah berakhir adalah menggunakan cabang bernama (sebagai lawan klon cabang) dengan strategi percabangan berikut:

trek standar pengembangan "selesai"
cabang fitur melacak pekerjaan yang saat ini sedang berlangsung
melepaskan titik jejak cabang tempat kami merilis dari default

Jadi, pekerjaan dimulai dengan membuat cabang fitur dari ujung default saat ini . Ketika cabang fitur selesai *, cabang ditutup dan digabungkan kembali ke default .

Pada titik tertentu, kami memutuskan bahwa kami siap untuk merilis, jadi kami membuat cabang rilis baru dari tip saat ini secara default . Ini memungkinkan kami untuk membuat perubahan pada kode yang saat ini dalam produksi dengan melakukan ke cabang rilis sambil tetap memungkinkan pengembangan aktif pada cabang fitur dan default .

Adapun integrasi berkelanjutan, kami melakukan dua hal:

Integrasi "selalu aktif" yang memonitor status default
Integrasi baru untuk setiap cabang rilis

The standar pekerjaan cabang memungkinkan kita tahu bahwa pohon sumber utama kami adalah selalu stabil - yang rilis cabang pekerjaan membiarkan kita tahu bahwa cabang-cabang yang stabil dan memberikan kami dengan output membangun kita perlu mendorong sebuah rilis ke dalam produksi.

_{* Definisi kami tentang "selesai" adalah bahwa fitur tersebut mutakhir dengan penggabungan dari standar dan telah disetujui dalam tinjauan kode.}

— Chris Phillips
sumber

1

Jika Anda pindah ke DVCS, seperti Hg, Anda tidak hanya mendapatkan "bagian yang didistribusikan", Anda juga mendapatkan kekuatan penuh dari percabangan dan penggabungan yang baik.

Menimbang bahwa sekarang Anda akan memiliki pelacak isu yang bagus dan SCM yang baik ... mengapa tidak membuat cabang untuk setiap tugas?

Pola "cabang per tugas" bukanlah hal baru (lihat buku Berczuk) tetapi jelas merupakan sesuatu yang harus dicoba.

Saya menjelaskannya secara rinci di sini , dan pro dan kontra CI vs "dikontrol" di sini .

— psantosl
sumber

Saya akan mengatakan "lebih baik" daripada "baik" karena saya dengan senang hati, antusias dan berhasil melakukan percabangan dan pemeliharaan fitur dan penggabungan dengan subversi (-:

— Murph