Apakah scrum dan pembangunan yang stabil membangun kontradiksi?

11

Saya bagian dari grup pengembangan dengan 5 tim, total sekitar 40 pengembang. Kami mengikuti metodologi Scrum, dengan sprint 3 minggu. Kami memiliki pengaturan integrasi berkelanjutan (Jenkins), dengan pipeline build memakan waktu beberapa jam (karena tes otomatis yang ekstensif). Pada dasarnya, proses pengembangan berjalan dengan baik.

Namun, kami mengamati bahwa setelah beberapa hari memasuki sprint baru, build kami sering menjadi tidak stabil, dan tetap goyah hingga ujung sprint "komit berhenti". Efek buruknya adalah langkah-langkah membangun jauh di bawah pipa, terutama UI- / Webtests tidak dieksekusi selama beberapa hari (karena hanya dipicu pada bangunan 'hijau'). Akibatnya, bug yang baru diperkenalkan seringkali hanya terdeteksi sangat lambat dalam sprint.

Setiap komit diverifikasi terhadap serangkaian tes dasar. Setelah diverifikasi, perubahan didorong untuk dikuasai setelah ulasan kode (Gerrit)
Tes unit dasar dijalankan setiap 30 menit, durasinya kurang dari 10 menit
Tes integrasi dijalankan setiap 2 jam, durasi 1 jam
UI- / Webtests berjalan pada tes integrasi yang berhasil, durasi beberapa jam

Bergantung pada siapa yang bertanggung jawab untuk membangun stabilitas selama sprint (tanggung jawab itu diberikan per sprint), mungkin ada "penghenti" sementara yang ad-hoc untuk membuat bangunan kembali ke stabil.

Jadi, kami ingin:

Tim pengembang kami mengembangkan dan melakukan perubahan selama sprint tanpa hambatan
Proses build kami untuk ditinggalkan jika langkah build gagal, karena hasil build selanjutnya hanya memiliki sedikit makna
Proses pembangunan kami untuk memberikan umpan balik yang berkualitas kepada pengembang tepat waktu

Mengingat (2), poin (1) dan (3) tampaknya saling bertentangan. Adakah yang punya praktik yang baik bagaimana menghadapi ini?

( Kami saat ini sedang melonggarkan poin (2), dan memungkinkan pembangunan berkelanjutan bahkan pada langkah-langkah pembangunan yang gagal. Saya belum memiliki umpan balik bagaimana hal itu mempengaruhi kualitas kami )

Terima kasih, Simon

— Simon
sumber

3

Saya akan mengatakan bahwa jika membangun mengambil several hoursmaka itu adalah masalah sebenarnya. itu menandakan bahwa solusi gabungan terlalu besar dan terlalu luas. Anda harus mencari untuk memomponisasi solusi dan kemudian memiliki potongan kecil kode sebagai paket (tersedia dalam satu atau lain cara dalam semua bahasa utama di semua platform). Dengan demikian setiap perubahan akan masuk ke komponen saja dan akan terdeteksi lebih cepat. Build penuh pada dasarnya hanya akan menggabungkan komponen yang sudah digabungkan, dan juga akan lebih cepat. Anda kemudian hanya akan menjalankan beberapa tes untuk memastikan komponen yang tepat terselesaikan.

— zaitsman

Apakah lingkungan build Anda berdasarkan lokasi atau berbasis cloud?

— Lauri Laanti

@LauriLaanti, lingkungan build kami ada di lokasi, 1 contoh Jenkins dengan 3 budak.

— Simon

7

Beberapa prinsip dasar yang pertama: - Perubahan besar harus selalu pada cabang fitur di VCS Anda - Cabang fitur harus lulus semua tes sebelum bergabung ke dalam bagasi. Ditambahkan - Komit harus selalu dibangun - Bangunan rusak membutuhkan tindakan segera dari pengendara & / atau anggota tim lainnya. - Tes yang gagal seharusnya hanya membatalkan tes yang tersisa jika itu adalah tes kritis .

Jika Anda, sebagai sebuah tim, ikuti praktik-praktik ini dan menegakkannya, misalnya: "nama & rasa malu" ketika build rusak maka Anda harus bersikap baik karena setiap komit yang mungkin merusak build akan ada di cabang fitur. Komitmen lain yang melanggar pembangunan harus segera ditangani dan kemudian Anda akan mendapatkan hasil tes hilir.

Anda juga dapat menambahkan tes otomatis build "berhasil" terbaru, (tidak harus yang lulus tes integrasi), untuk tes UI / Web sebagai pelaporan pertama yang dijalankan semalam di pagi hari.

— Steve Barnes
sumber

3

Praktik yang baik untuk ditambahkan di sini adalah bahwa cabang fitur harus lulus semua tes sebelum digabungkan ke arus utama

— Bart van Ingen Schenau

@ BartartIngenSchenau - poin bagus ditambahkan!

— Steve Barnes

@SteveBarnes, terima kasih atas masukannya. Komitmen ke Gerrit selalu di cabang, dan hanya digabungkan pada kesuksesan (poin pertama saya dalam proses membangun). Itu setelah itu di mana masalah dimulai. Dengan 30 devs yang melakukan perubahan beberapa kali per hari, kita perlu bergabung lebih awal, dan kemudian memverifikasi. Ada adalah tindakan segera setelah membangun rusak, tetapi sebagai waktu antara melakukan dan membangun umpan balik adalah 2 jam, akan ada beberapa komit lain untuk sementara. Mungkin melanggar bangunan berikutnya.

— Simon

@Simon titik "nama & malu" adalah untuk membuat pengembang Anda berhenti melakukan kode yang rusak! Pada kebanyakan sistem adalah mungkin untuk melakukan uji coba membangun dalam waktu singkat menggunakan alat-alat seperti semut, membuat, scon, dll. Jika proyek Anda terstruktur dengan baik, sebagian besar bahasa memungkinkan pengujian ulang sebagian untuk menguji apakah ada sesuatu yang membangun, (penuh / bersih membangun masih perlu dilakukan tentunya).

— Steve Barnes

8

Tidak ada hubungannya dengan Scrum. Bangunan Anda harus terus stabil, terlepas dari apa pun.

Tidak ada yang harus memeriksa apa pun kecuali mereka telah melakukan pembangunan lokal dan menjalankan tes unit secara lokal (dan keduanya lulus, tentu saja) Proses pembuatan dan pengujian lokal Anda harus peka terhadap modifikasi, dan dapat melewati tes untuk kode yang tidak berubah.

Siapa pun yang memperkenalkan sesuatu yang menyebabkan pembangunan gagal atau pengujian unit gagal harus dipermalukan di depan umum . Jika bangunan rusak itu harus segera diperbaiki.

— John Wu
sumber

2

Di satu sisi, harus ditekankan bahwa membangun stabilitas adalah tanggung jawab semua orang. Di sisi lain, saya akan menyarankan agar tidak dipermalukan di depan umum, karena (1) anggota tim yang lebih berpengalaman memiliki tanggung jawab lebih besar dalam membantu anggota junior mencapai stabilitas pembangunan (dengan meninjau kode, memprogram pasangan, atau hanya bekerja sama secara erat sebelum sebuah komitmen, atau dengan memperbaiki bangunan yang rusak bersama), (2) mempermalukan menghilangkan keamanan psikologis tim .

— rwong

1

Jika orang tidak mau dipermalukan maka mereka seharusnya tidak merusak gedung. Ini tidak seperti itu adalah standar yang terlalu tinggi. Jika Anda memiliki dev yang tidak bisa meretasnya, biarkan mereka memiliki cabang sendiri untuk dimainkan sampai mereka mengetahui bagaimana tidak menghancurkan Commons kritis tim. (Yang dikatakan, rasa malu yang sebenarnya harus dalam selera yang baik).

— John Wu

Dalam proses kami, komit apa pun bercabang (dalam Gerrit), dan harus melewati serangkaian tes dasar sebelum bergabung menjadi master. Tes dasar itu tidak dapat berjalan selama satu jam, karena kami ingin meninjau kode dan menggabungkan dengan cepat. Ini setelah penggabungan di mana masalah dimulai, lihat komentar saya ke @SteveBarnes

— Simon

6

Masalah Anda tampaknya karena tes terlalu lama untuk dijalankan. Untungnya, hukum Moore telah memberi kami solusi untuk masalah itu. Saat ini, CPU server kelas atas dapat dengan mudah memiliki lebih dari 10 core (dan lebih dari 10 HyperThreads). Mungkin ada beberapa CPU dalam satu komputer.

Jika saya memiliki tes yang memakan waktu selama ini, saya akan menyelesaikan masalah dengan lebih banyak perangkat keras. Saya akan membeli server high-end dan kemudian memparalelkan tes sehingga tes sepenuhnya memanfaatkan semua core CPU. Jika tes Anda hari ini adalah single-threaded, manfaatkan 10 core dan 10 HyperThreds mungkin membuat tes berjalan 15 kali lebih cepat. Tentu saja, ini berarti mereka juga menggunakan 15 kali memori, sehingga komputer harus memiliki RAM yang cukup.

Jadi, beberapa jam akan berubah menjadi 10-30 menit.

Anda tidak mengatakan berapa lama waktu yang dibutuhkan untuk membangun, tetapi alat-alat standar seperti membuat memungkinkan untuk memaralelkan juga bangunan. Jika Anda memparalelkan tes unit Anda dan komputer pengembang biasanya memiliki 4 core dan 4 HyperThreads, tes unit kurang dari 10 menit akan berubah menjadi kurang dari 2 menit. Jadi, mungkin Anda bisa menerapkan kebijakan bahwa setiap orang harus menjalankan tes unit sebelum melakukan?

Tentang kegagalan pengujian, menghentikan pengujian lebih lanjut: jangan lakukan itu di server build! Anda ingin informasi sebanyak mungkin tentang kegagalan, dan tes lebih lanjut mungkin mengungkapkan sesuatu yang penting. Tentu saja, jika build itu sendiri gagal, Anda tidak dapat menjalankan tes unit. Jika pengembang menjalankan tes unit pada mesinnya sendiri, maka Anda mungkin ingin membatalkan pada kegagalan pertama.

Saya tidak melihat hubungan antara Scrum dan masalah Anda. Masalahnya benar-benar dapat terjadi dengan proses pengembangan apa pun.

— ahli hukum agama
sumber

Saya setuju, dengan membangun yang lebih cepat akan jauh lebih mudah. TechTeam kami telah menghabiskan waktu berhari-hari untuk meningkatkan kecepatan proses pembuatan, jika tidak, kami akan menunggu berhari-hari. Adapun saat ini, durasi umpan balik tersebut diberikan pada kira-kira. 2 jam. Jadi saya mencari pendekatan yang menganggapnya sebagai "pemberian". (Tentu saja, kami terus berusaha mempercepat pembangunan. Tetapi untuk waktu dekat, ini akan menjadi 2 jam)

— Simon

Beberapa tes dapat bertentangan dengan run paralel

— deFreitas

Hanya mungkin untuk melemparkan lebih banyak perangkat keras padanya jika tes ditulis dengan cara di mana mereka dapat berjalan secara independen satu sama lain tanpa memperkenalkan efek samping .. Semakin jauh Anda dapatkan dari perangkat keras semakin sulit ini ... sebagian besar pengembang tidak lakukan ini dengan benar, jadi sementara saya setuju dengan Anda, saya pertama-tama akan fokus pada penyusunan tes dengan cara yang benar.

— c_maker

2

Apakah tidak mungkin untuk memiliki lebih banyak instalasi Jenkins dan meminta pengembang memeriksa contoh Jenkins yang terpisah?

Saya akan berpikir solusi terbaik di sini adalah memiliki kode lulus semua tes sebelum diperiksa ke cabang master dan dikompilasi / diuji oleh instance Jenkins utama. Jangan biarkan orang-orang memeriksa kode yang merusak bangunan.

Saya memeriksa kode saya ke cabang pengembangan, melihat apakah ia lulus tes dan membuat permintaan tarik. Tetapi Anda jelas bisa meminta jenkins menarik cabang fitur dan mengujinya.

— xyious
sumber

1

Poin (2) tampaknya menjadi poin yang paling menyakitkan, jadi saya akan fokus pada hal itu.

Mungkin sudah waktunya untuk memecah proyek menjadi beberapa modul.

https://en.wikipedia.org/wiki/Dependency_inversion_principle

A. Modul tingkat tinggi tidak harus bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi.

B. Abstraksi tidak harus tergantung pada detail. Rinciannya harus bergantung pada abstraksi.

Jika satu modul gagal dibangun, build untuk modul lain akan dapat dilanjutkan, selama modul-modul lainnya dapat bergantung pada suatu antarmuka, dan kode yang membentuk antarmuka itu berhasil dibangun.

Ini akan memberi Anda umpan balik tentang apa yang mungkin terjadi kegagalan pembangunan lainnya, sehingga Anda punya waktu untuk memperbaiki lebih dari satu modul yang rusak sebelum pembangunan berikutnya terjadi.

Secara umum, prinsip-prinsip SOLID disusun untuk menangani perpustakaan dan membangun masalah. Dengan kata lain - serangkaian prinsip ini disusun untuk memecahkan jenis masalah yang Anda hadapi.

Sebagai catatan tambahan (lihat jawaban juhist), Anda tidak dapat membuat build berjalan lebih cepat (dengan paralelisasi) jika Anda tidak mempartisi build menjadi modul terpisah.

— rwong
sumber

0

Saya pikir tim Anda tidak memiliki salah satu prinsip utama scrum: selesai, perangkat lunak yang berfungsi. PBI tidak boleh ditandai sebagai selesai sampai melewati Definisi Selesai yang telah dibuat tim Anda. Definisi Done berbeda untuk setiap tim, tetapi kemungkinan akan mencakup hal-hal seperti:

Kode memiliki unit test
Uji lulus unit sebagai bagian dari bangunan otomatis
Kode telah digabung menjadi utama (dan konflik telah diselesaikan)
dll.

Jadi, pada dasarnya, apa yang terjadi adalah tim Anda menandai hal-hal yang sudah dilakukan yang sebenarnya tidak dilakukan. Itu masalah dalam dirinya sendiri.

Selain itu, itu bermuara pada manajemen kontrol versi yang tepat. Jika Anda menggunakan Git, maka semua pekerjaan dilakukan di repositori lokal dev dan mereka tidak boleh mendorong apa pun ke remote kecuali itu "selesai" dan berpotensi dapat dirilis. Pekerjaan yang tidak lengkap seharusnya tidak pernah didorong ke repositori utama Anda. Jika dev perlu bekerja pada cabang fitur yang berumur lebih lama dan ingin mendorong ke jarak jauh untuk memastikan bahwa mereka tidak kehilangan pekerjaan mereka, maka mereka harus bekerja dari garpu, dan Anda kemudian akan menggabungkan garpu itu menjadi utama ketika fitur "selesai" dan berpotensi dirilis - bukan sebelumnya.

Untuk TFVC, ini sedikit lebih rumit karena semuanya terjadi pada "jarak jauh". Itu berarti bahwa devs karenanya harus selalu bekerja di luar cabang, kecuali itu perbaikan cepat. Aturan yang sama berlaku di sini seperti halnya Git, meskipun: perangkat lunak tidak lengkap tidak mendapatkan komitmen. Titik. Dalam kontrol versi yang dikelola dengan benar, "main" harus selalu dapat dirilis. Jika komit dibuat bahwa borks "utama", maka Anda tidak melakukannya dengan benar.

— Chris Pratt
sumber