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
sumber
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.Jawaban:
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.
sumber
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.
sumber
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.
sumber
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.
sumber
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
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.
sumber
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:
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.
sumber