Menggunakan cabang pengujian di Git

Kami memiliki seseorang (sebut saja Ted) yang bertanggung jawab untuk menguji fitur baru dan perbaikan bug.

Kami menggunakan Git dan GitHub . masterharus / selalu dapat digunakan dan developmentmerupakan tempat kita melakukan / menggabungkan fitur baru atau perbaikan bug, tetapi hanya setelah mereka diuji oleh Ted.

Proyek ini dalam PHP.

Saya ingin proses pengujian berjalan seperti ini:

1. Pengembang ingin mengerjakan fitur baru (misalkan fitur / bug # 123 seperti yang didokumentasikan Ted di pelacak masalah), jadi ia menarik origin/developmentke developmentrepositori lokalnya dan membuat cabang baru (katakanlah issue-123) dari sana.
2. Begitu dia senang dengan pekerjaannya, dia berkomitmen dan mendorong cabang barunya origin.
3. Ted terhubung ke test.ourproject.com/choose-branchdan melihat daftar cabang origindan memilih untuk mengaktifkan issue-123(itu harus dapat dilakukan melalui halaman web). Dia kemudian melanjutkan test.ourproject.com, menguji aplikasi web (dia benar-benar kejam) dan setelah beberapa bolak-balik dengan pengembang, dia senang dengan fitur tersebut.
4. Ted mengatakan pengembang bahwa ia dapat menggabungkan issue-123ke developmentatas origin.
5. Bilas dan ulangi.

Untuk langkah ketiga, saya bisa meretas sesuatu yang berfungsi (menunjukkan dan mengganti cabang dari halaman tertentu), tetapi saya merasa bahwa apa yang saya jelaskan adalah pola yang sangat umum.

Jadi pertanyaan saya adalah: Apakah ini alur kerja yang baik / berkelanjutan / dikelola untuk percabangan? Bisakah Anda mencadangkan jawaban Anda dengan mengutip beberapa contoh proyek lain mengikuti alur kerja ini?

Alur kerja cabang terdengar sangat mirip gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow dan ada alat pendukung di sekitarnya. Sangat direkomendasikan.

Jika hanya ada satu tester, alur kerja pengujian Anda terdengar baik, tetapi jika ada beberapa orang maka pengembangan mungkin bergerak antara awal dan selesai, dan tentu saja pengujian idealnya harus sepenuhnya dilakukan setelah penggabungan. Di sinilah pengujian otomatis benar-benar dapat membantu atau penguji lambat (menyeluruh) mungkin tidak pernah selesai!

Masalah lain adalah bahwa dengan banyak fitur dan cabang itu menjadi tergoda untuk mencampur dan mencocokkan fitur ke dalam rilis (atau memilih untuk mengusir setelah penerimaan dan penggabungan) atau mungkin jika fitur saling tergantung. Masalahnya adalah jika Anda mulai tergoda untuk menulis ulang riwayat (rebase / hapus komit atau penggabungan) pada cabang-makna PUBLISHED yang telah didorong ke repo multidev. Ini menulis ulang sejarah publik. Ini dapat dilakukan untuk kebaikan atau kejahatan dan bahkan jika dilakukan untuk kebaikan dapat menyebabkan masalah bagi yang tidak waspada, dan praktik terbaik adalah menghindarinya sehingga pertanyaan tidak akan pernah muncul. Namun, beberapa alur kerja cabang integrasi membuat ini sangat menggoda, jadi jika Anda memiliki perlindungan yang kuat pada cabang-cabang tersebut (mis. Gitolite per pembatasan cabang pengguna) dan orang-orang mengharapkan kegiatan seperti itu jadi selalu rebase kode mereka pada cabang seperti itu, lanjutkan - dengan hati-hati!

Saya juga ingin merekomendasikan membaca http://sethrobertson.github.com/GitBestPractices/ yang membahas semua masalah ini dan memiliki banyak referensi bagus.

Saya tidak yakin halaman switching itu sendiri adalah pola umum. Sebagian besar proyek mungkin hanya memiliki tester untuk memeriksanya dengan perintah git.

Pendekatan umum jelas terdengar masuk akal.

Google bahkan menulis Gerrit untuk mendukung gaya serupa; ini lebih tentang meninjau kode, tetapi menyetujui integrasi biasanya melibatkan tinjauan dan pengujian. Biasanya itu juga saling berhubungan dengan server integrasi berkelanjutan yang membangun semua pengiriman pertama (saya tidak yakin apakah mereka menggunakan Jenkins di Google, tapi saya percaya saya telah melihat konektor yang sesuai di suatu tempat).

Git sendiri menggunakan sedikit variasi pada tema. Pengelolanya memiliki skrip yang menggabungkan semua pengiriman yang tertunda ke cabang yang disebut pu(untuk "pembaruan yang diusulkan" mungkin; cabang dihapus dan dibuat kembali setiap kali karena pengiriman yang tertunda sering diubah kembali). Ini daripada diuji oleh berbagai orang. Jika tidak apa-apa, maka pengiriman yang dianggap selesai digabung menjadi next(sama dengan Anda development). Jika tidak, maka seseorang akan menguji pengiriman individu untuk melihat mana yang rusak. Ini membuatnya lebih mudah bagi penguji karena mereka tidak harus berganti cabang sebagian besar waktu; mereka hanya melaporkan apakah integrasi tes berfungsi.

Jika pengujian Anda dilakukan secara otomatis daripada secara manual, saya pikir Travis (sistem CI untuk GitHub) akan cukup banyak melakukan apa yang Anda inginkan - secara otomatis menjalankan tes pada semua permintaan tarik. ( Informasi lebih lanjut tentang proses ini, termasuk tangkapan layar. )

Perhatikan bahwa tes dijalankan bukan pada cabang, tetapi cabang setelah digabung menjadi master. (yaitu, apa yang akan Anda dapatkan setelah menggabungkan cabang menjadi master - Anda dijamin bahwa tes akan tetap berhasil setelah penggabungan.)

Jika komit ditambahkan ke cabang, tes dijalankan kembali. (Meskipun karena alasan tertentu menambahkan komitmen pada master tampaknya tidak menjalankan kembali tes.)