Kita mulai mengalami masalah saat kita semakin besar, di mana fitur membuatnya menjadi staging untuk pengujian, tetapi pada saat semuanya diuji dan fitur baru yang disetujui sedang staging untuk pengujian.

Ini menciptakan lingkungan di mana kita hampir tidak pernah dapat mendorong produksi karena kita memiliki kombinasi fitur yang telah diuji dan belum teruji. Saya yakin ini adalah masalah umum, tetapi saya belum menemukan sumber daya yang baik untuk kami.

Beberapa spesifik:

• GIT di BitBucket
• Jenkins untuk penerapan skrip ke Azure

Apa yang saya harapkan adalah cara untuk mengisolasi fitur saat mereka bergerak melalui lingkungan dan hanya mendorong apa yang siap untuk dipaksakan.

Sepertinya Anda memiliki beberapa masalah di sini:

1. Mengidentifikasi fitur untuk rilis tertentu

Ini adalah masalah manajemen proyek, dan masalah koordinasi. Apakah fitur ini akan dirilis sebelum, bersamaan dengan, atau setelah fitur lainnya ini? Jika rilis ingin terjadi satu fitur pada suatu waktu, maka identifikasi itu. Jika fitur akan dikelompokkan menjadi rilis, maka cari tahu apa pengelompokan itu, dan menegakkannya dengan para dev dan pembuat keputusan. Gunakan sistem pelacakan atau tiket Anda untuk menandai rilis. Jelaskan bahwa jika satu fitur dari rilis spesifik adalah no-go, maka semuanya adalah.

2. Strategi percabangan

Git-flow adalah jawaban yang mudah untuk masalah seperti ini, dan sering orang menggunakan varian git-flow bahkan jika mereka tidak tahu apa itu. Saya tidak akan mengatakan bahwa itu adalah masalah untuk semua masalah, tetapi itu sangat membantu.

Sepertinya Anda mengalami masalah dengan strategi rilis non-deterministik, di mana fitur disetujui scattershot dan sesuatu yang memulai pengembangan sejak lama mungkin akan dirilis setelah sesuatu yang dimulai baru-baru ini - fitur lompatan-katak.

Cabang fitur yang berumur panjang atau cabang rilis simultan mungkin merupakan jawaban terbaik untuk masalah seperti ini. Gabungkan (atau rebase, jika Anda nyaman dengan itu) yang terbaru dari master ke cabang Anda yang sudah berjalan lama. Berhati-hatilah untuk hanya menggabungkan fitur yang sudah hidup, jika tidak Anda akan mengalami masalah yang Anda alami sekarang (terlalu banyak fitur yang tercampur pada satu cabang).

Cabang "Perbaikan terbaru" atau "perbaikan bug" adalah bagian penting dari proses ini; menggunakannya untuk perbaikan kecil satu kali yang memiliki siklus QA pendek.

Dari uraian Anda, mungkin bahkan lebih baik untuk tidak mempertahankan cabang 'pengembangan' resmi. Sebaliknya, cabut semua fitur dari master, dan buat cabang rilis gabungan setelah rilis diidentifikasi.

3. Lingkungan

Jangan mencocokkan cabang git dengan lingkungan Anda, kecuali untuk master produksi ==. Cabang 'pengembangan' harus dianggap rusak. Cabang pelepas didorong untuk menguji lingkungan, apakah itu lingkungan QA atau pementasan envirement. Jika perlu, dorong cabang fitur tertentu ke lingkungan.

Jika Anda memiliki lebih dari satu cabang fitur yang perlu dirilis secara terpisah tetapi sedang diuji pada saat yang sama ..... ¯ \ _ (ツ) _ / ¯ .... putar server lain? Mungkin menggabungkan mereka menjadi cabang yang dibuang ... melakukan perbaikan / perubahan ke cabang yang asli dan menggabungkan kembali ke cabang yang dibuang; lakukan persetujuan akhir dan UAT pada cabang rilis individu.

4. Menghapus fitur yang tidak disetujui dari cabang

Inilah yang coba dihindari oleh pikiran-pikiran di atas, karena ini tanpa ragu adalah hal yang paling menyakitkan untuk dicoba dan dilakukan. Jika Anda beruntung, fitur telah digabungkan ke dalam pengembangan Anda atau menguji cabang secara atomik menggunakan gabungan komitmen. Jika Anda kurang beruntung, para pengembang telah berkomitmen langsung ke cabang pengembangan / pengujian.

Either way, jika Anda mempersiapkan untuk rilis dan memiliki perubahan yang tidak disetujui, Anda harus menggunakan Git untuk mendukung komitmen yang tidak disetujui dari cabang rilis; ide terbaik adalah melakukannya sebelum menguji rilis.

Semoga berhasil.

Inilah sebuah ide, Berhenti menggunakan cabang rilis. Alih-alih, mulai membuat fitur beralih dan mengelolanya melalui konfigurasi. Dengan begitu, Anda selalu menggabungkan cabang fitur menjadi master dan seharusnya tidak pernah ada pertanyaan tentang versi apa yang sedang diuji atau dipaksakan. Jika Anda memiliki pertanyaan tentang fitur / implementasi apa yang aktif di lingkungan, cukup periksa file konfigurasi.

Ini harus menjadi masalah koordinasi sederhana antara pengujian dan produksi. Jika Anda menggunakan cabang fitur di Git, cukup berhenti mendorong cabang fitur yang telah selesai untuk Menguji selama siklus pengujian, dan melanjutkan kembali ketika pengujian selesai.

Jika Anda memerlukan kontrol yang lebih baik daripada ini, pisahkan Tes ke server Pengembangan dan server Pengujian Penerimaan, dan koordinasikan cabang-cabang yang akan didorong ke server Pengujian Penerimaan dengan tim pengujian. Seseorang kemudian dapat bertanggung jawab untuk memulai penyebaran terakhir dari Tes Penerimaan ke Produksi.

Pekerjaan menumpuk

Ini adalah masalah universal dalam pengalaman saya. Saya mengatasinya dengan:

• Manajemen rilis fitur yang kuat oleh pemilik produk
• Pastikan cabang dihapus ketika digabungkan
• Batasi pekerjaan yang sedang berjalan (dengan batas kolom di Jira)
• Ulasan triwulanan tiket lama yang mendekam, baik bug dan fitur
• Retrospektif untuk membahas komponen masalah ini
• Dorongan konstan untuk ulasan kode oleh semua
• Kesempatan berpasangan untuk menangani tiket dan masalah lama
• Pertemuan triwulanan untuk meninjau dan membersihkan tiket lama
• Pendekatan tim untuk membuat dev, produk, dan QA / QE bekerja sama dengan erat
• Pelaporan dan alat yang baik untuk membuat fitur produk baru dan jaminan simpanan jelas
• Tinjau sesi untuk menelusuri cabang lama dan menghapusnya

Ranting

Anda memerlukan beberapa cabang untuk mengontrol proses itu:

• Fitur : cabang ini lahir dari master. Gunakan beberapa aplikasi manajemen proyek untuk mengidentifikasi setiap cabang fitur dengan beberapa tugas. Per contoh, jika Anda menggunakan TRAC, Anda akan berakhir jika cabang seperti: 1234-user-crud,1235-bug-delete-catalog dll. Identifikasi komit Anda dengan nomor tugas juga, ini akan banyak membantu Anda ketika Anda memiliki masalah dalam penggabungan (Anda akan).
• tes : semua cabang fitur yang dilakukan akan digabungkan ke cabang uji. Anda tidak pernah menggabungkan cabang uji ke beberapa cabang fitur , karena Anda tidak ingin kode dari fitur lain yang tidak ada dalam produksi (master). Hal yang sama berlaku untukrelease cabang.
• melepaskan : ketika Anda memutuskan fitur apa yang dapat diuji dalam produksi, Anda menggabungkan cabang ini (lagi ...) di cabang ini. Anda perlu menguji semua fitur lagi, karena penggabungan ini dapat membawa masalah baru. Saat rilis diuji dan dilakukan, Anda menggabungkan cabang ini untuk menguasai dan membuat tag pada master untuk versi tersebut.
• master : hanya berisi kode produksi.

Lihat aliran git:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

Lingkungan

Sangat sederhana:

• Tes : lingkungan ini menggunakan cabang tes.
• rilis : lingkungan ini menggunakan cabang rilis yang sebenarnya.

Pengembang bekerja di mesinnya, masing-masing menggunakan basis datanya sendiri. Jika tidak memungkinkan, setiap pengembang memiliki basis data tersendiri (karena lisensi, ukuran basis data, dll.), Anda akan banyak mengalami masalah berbagi basis data antara pengembang: ketika seseorang menghapus kolom atau tabel di cabangnya, yang lain cabang masih diperhitungkan dengan kolom / tabel ini dalam database.

Masalah

Masalah terbesar dalam proses ini adalah penggabungan.

Anda perlu membuat kembali gabungan yang sama di testdan release. Ini akan menyakitkan jika beberapa refactor yang baik dibuat dalam kode, seperti menghapus kelas, memindahkan / mengganti nama metode, dll. Karena Anda tidak bisa mendapatkan kode dari test(atau release) cabang ke cabang fitur, komit gabungan dapat diselesaikan hanya dalam yang test(atau release). Jadi, Anda akhirnya menyelesaikan konflik yang sama di dua cabang yang berbeda, mungkin menghasilkan kode yang berbeda di setiap penggabungan dan, di masa depan, Anda akan menemukan bahwa tim pengujian perlu menguji fitur dua kali: di testdan releasecabang, karena masing-masing menggabungkan dapat menghasilkan bug yang berbeda.

Masalah lainnya adalah testcabang. Anda perlu "mendaur ulang" cabang ini (hapus dan buat yang baru master) dari waktu ke waktu, karena beberapa cabang lama (atau gabungan lama, cabang gabungan yang telah dihapus) di sana dapat membawa banyak masalah untuk kode baru, menyimpang banyak dari apa yang ada di master. Pada saat ini, Anda perlu mengontrol cabang apa yang ingin Anda gabungkan lagi di test.

Solusi terbaik adalah tim bisnis tahu apa yang perlu disampaikan dalam versi berikutnya dan semua orang bekerja di cabang yang unik (mengembangkan cabang). Baik bagi mereka kemungkinan untuk memilih fitur "selesai" yang mereka inginkan dalam versi berikutnya kapan saja mereka mau (saya pikir ini skenario Anda), tetapi ini adalah mimpi buruk bagi pengembang dan (saya percaya) untuk tim uji.

Kedengarannya Anda menggabungkan perubahan dari cabang integrasi Anda ke cabang produksi Anda, yang IMHO bukan praktik yang baik, persis karena alasan yang Anda sebutkan. Segera setelah cabang produksi untuk rilis tertentu ditarik dari cabang integrasi utama, cabang integrasi dapat, setiap saat, menyimpang (setelah semua itu seharusnya berkembang menjadi rilis berikutnya). Penggabungan dari cabang integrasi ke cabang rilis saat ini dapat membawa perubahan yang tidak sesuai dengan rilis itu.

IMHO proses yang tepat adalah:

• tarik cabang produksi dari cabang integrasi hanya ketika dianggap cukup dekat dengan tingkat kualitas yang diinginkan, sehingga hanya segelintir perubahan yang selanjutnya diharapkan untuk menyelesaikan rilis. Dengan kata lain penyelesaian fitur harus dievaluasi (terus menerus) pada cabang integrasi, sebelum menarik cabang produksi.
• setelah cabang produksi ditarik hanya perubahan cherry-pick dibawa ke sana, diperlakukan sebagai perubahan standalone / perbaikan titik - yaitu diverifikasi bahwa mereka benar-benar bekerja seperti yang diharapkan (hanya karena perubahan bekerja di satu cabang tidak selalu berarti itu juga berfungsi di cabang lain).

Secara pribadi, ini terdengar seperti itu bisa menjadi masalah proses lebih dari masalah perkakas. Beberapa hal yang saya sarankan di sini:

• Saya tidak yakin apakah Anda memiliki grup Dev dan QA yang terpisah. Jika ya, pastikan Dev dan QA duduk dalam perencanaan sprint dan rapat estimasi. Di salah satu perusahaan saya sebelumnya, kami memastikan bahwa jumlah poin cerita yang kami berikan pada sebuah cerita bertanggung jawab atas upaya pengembangan dan pengujian. (Anda juga bisa secara teoritis memiliki dua perkiraan terpisah untuk upaya dev dan QA, tetapi cara apa pun yang Anda perlukan untuk perkiraan Anda untuk memasukkan keduanya; waktu yang diperlukan untuk sebuah cerita adalah waktu yang diperlukan untuk benar-benar mengirimkannya). Bahkan jika Anda tidak memiliki grup QA yang terpisah, tetap pastikan Anda menyertakan upaya pengujian dalam perkiraan Anda.
• Dengan nada yang sama seperti di atas, setujui terlebih dahulu berapa banyak cerita yang akan Anda sertakan dalam sprint tertentu. Jumlah poin cerita yang Anda terima didasarkan pada jumlah yang dapat diselesaikan pengembang Anda dalam sprint mereka dan jumlah item yang dapat diuji QA dalam sprint mereka. (Saya berasumsi, tentu saja, bahwa sprint QA berada di belakang sprint Dev, tetapi Anda dapat menyesuaikan ini dengan proses Anda). Jika pengembang Anda bisa menyelesaikan 200 poin cerita tetapi QA Anda hanya bisa menyelesaikan 150 poin cerita, jelas Anda hanya bisa melakukan 150 poin cerita sebelum pekerjaan mulai "menumpuk" dan Anda berakhir dengan kasus seperti apa yang Anda gambarkan. (Dalam kasus seperti ini, Anda mungkin ingin menyelidiki penyebab penghalang jalan untuk mencoba menguranginya).
• Tidak ada yang mendorong apa pun ke QA sampai semua yang ada di QA diuji dan dikirim .
• Fitur yang lengkap adalah yang telah diuji dan dikirim. Jika tidak terkirim, itu belum selesai.
• Jelas, Anda ingin mencoba melakukan ini pada semacam jadwal tetap. Salah satu dari seluruh ide di balik Integrasi dan Agile Berkelanjutan adalah iterasi. Menurut definisi, iterasi memerlukan pengiriman yang sering. Integrasi dan pengiriman yang sering meminimalkan risiko masing-masing.

Sejujurnya, saya pikir hal terbesar akan menjadi disiplin ketika Anda memberikan dan berapa banyak tugas yang Anda dapat benar-benar selesai dalam jangka waktu tertentu.

Untuk meringkas: hanya mengirim ke QA ketika Anda selesai menguji dan memberikan fitur-fitur lama.

Ketika "semuanya diuji dan disetujui", gunakan apa yang diuji dan disetujui untuk produksi. Itu bisa berupa komit tertentu, atau bisa juga artefak build tertentu yang dihasilkan oleh Jenkins.

Tidak masalah bahwa kemudian melakukan pada cabang yang sama belum diuji.