Berapa banyak pengembang sebelum integrasi berkelanjutan menjadi efektif bagi kami?


34

Ada overhead yang terkait dengan integrasi berkelanjutan, misalnya, pengaturan, pelatihan ulang, kegiatan penyadaran, penghentian untuk memperbaiki "bug" yang ternyata merupakan masalah data, pemisahan gaya gaya pemrograman yang dipaksakan, dll.

Pada titik apa integrasi berkesinambungan membayar untuk dirinya sendiri?

EDIT: Ini adalah temuan saya

Set-up adalah CruiseControl.Net dengan Nant, membaca dari VSS atau TFS.

Berikut adalah beberapa alasan untuk kegagalan, yang tidak ada hubungannya dengan pengaturan:

Biaya investigasi : Waktu yang dihabiskan untuk menyelidiki apakah lampu merah disebabkan oleh inkonsistensi logis asli dalam kode, kualitas data, atau sumber lain seperti masalah infrastruktur (misalnya, masalah jaringan, pembacaan batas waktu dari kontrol sumber, server pihak ketiga sedang down, dll, dll.)

Biaya politik atas infrastruktur : Saya mempertimbangkan melakukan pemeriksaan "infrastruktur" untuk setiap metode dalam uji coba. Saya tidak punya solusi untuk batas waktu kecuali untuk mengganti membangun server. Pita merah menghalangi dan tidak ada penggantian server.

Biaya perbaikan unit tes : Lampu merah karena masalah kualitas data bisa menjadi indikator dari tes unit yang ditulis dengan buruk. Jadi, tes unit dependen data ditulis ulang untuk mengurangi kemungkinan lampu merah karena data yang buruk. Dalam banyak kasus, data yang diperlukan dimasukkan ke dalam lingkungan pengujian untuk dapat menjalankan tes unitnya secara akurat. Masuk akal untuk mengatakan bahwa dengan membuat data lebih kuat maka tes menjadi lebih kuat jika tergantung pada data ini. Tentu saja, ini berhasil!

Biaya pertanggungan, yaitu, menulis tes unit untuk kode yang sudah ada : Ada masalah cakupan tes unit. Ada ribuan metode yang tidak memiliki tes unit. Jadi, dibutuhkan jumlah hari kerja yang cukup besar untuk menciptakannya. Karena ini akan terlalu sulit untuk menyediakan kasus bisnis, diputuskan bahwa unit test akan digunakan untuk metode publik baru yang akan datang. Mereka yang tidak memiliki unit test disebut 'berpotensi infra merah'. Titik intesting di sini adalah bahwa metode statis adalah titik diperdebatkan dalam bagaimana mungkin untuk secara unik menentukan bagaimana metode statis tertentu gagal.

Biaya rilis yang dipesan lebih dahulu : Skrip Nant hanya sejauh ini. Mereka tidak berguna untuk, katakanlah, CMS dependen build untuk EPiServer, CMS, atau penyebaran database berorientasi UI.

Ini adalah jenis masalah yang terjadi pada server build untuk menjalankan pengujian per jam dan build QA semalam. Saya terhibur bahwa ini tidak perlu sebagai master bangunan dapat melakukan tugas-tugas ini secara manual pada saat rilis, khususnya, dengan band satu orang dan sebuah bangunan kecil. Jadi, langkah tunggal membangun belum membenarkan penggunaan CI dalam pengalaman saya. Bagaimana dengan multistep build yang lebih kompleks? Ini bisa menjadi rasa sakit untuk dibangun, terutama tanpa naskah Nant. Jadi, bahkan setelah membuat satu, ini tidak lebih berhasil. Biaya memperbaiki masalah lampu merah melebihi manfaatnya. Akhirnya, pengembang kehilangan minat dan mempertanyakan validitas lampu merah.

Setelah mencobanya dengan adil, saya percaya bahwa CI itu mahal dan ada banyak pekerjaan yang harus dilakukan alih-alih menyelesaikan pekerjaan. Ini lebih hemat biaya untuk mempekerjakan pengembang berpengalaman yang tidak membuat kekacauan proyek besar daripada memperkenalkan dan memelihara sistem alarm.

Ini adalah kasusnya bahkan jika para pengembang pergi. Tidak masalah jika pengembang yang baik pergi karena proses yang dia ikuti akan memastikan bahwa dia menulis spesifikasi kebutuhan, spesifikasi desain, menempel pada pedoman pengkodean, dan mengomentari kodenya sehingga dapat dibaca. Semua ini ditinjau. Jika ini tidak terjadi maka pemimpin timnya tidak melakukan pekerjaannya, yang harus diambil oleh manajernya dan seterusnya.

Agar CI bekerja, tidak cukup hanya menulis unit test, berupaya mempertahankan cakupan penuh, dan memastikan infrastruktur yang berfungsi untuk sistem yang cukup besar.

Intinya: Orang mungkin mempertanyakan apakah memperbaiki bug sebelum rilis bahkan diinginkan dari perspektif bisnis. CI melibatkan banyak pekerjaan untuk menangkap beberapa bug yang dapat diidentifikasi pelanggan dalam UAT atau perusahaan dapat dibayar untuk memperbaiki sebagai bagian dari perjanjian layanan klien ketika masa garansi berakhir.


13
Ini dapat bermanfaat bahkan untuk tim yang terdiri dari satu orang. Terutama jika Anda memiliki test suite yang berjalan lama, jauh lebih baik untuk mendapatkan secara otomatis hasil build semalam dan uji coba daripada melakukannya secara manual setiap saat.
SK-logic

3
@Carnotaurus, klon lokal repositori git jarak jauh menghilangkan batas waktu dari kontrol sumber. Masalah jaringan - untuk membangun produk? Sekarang, sungguh ...

3
@Carnotaurus lampu merah karena kualitas data atau infrastruktur adalah kode dari Uji Fragile . Lihat juga : mengelola-perawatan-beban-unit-pengujian
k3b

1
Semakin banyak tes tergantung pada aspek eksternal semakin rapuh. Contoh: Jika suatu pengujian hanya berhasil jika pelanggan XY ada dalam basis data pengujian jika rapuh kecuali tes-setup membuat yakin bahwa prasyarat ini ada dengan memasukkan data itu sendiri jika diperlukan.
k3b

6
"Intinya: Mengapa membuat produk yang berfungsi ketika kita bisa membuat orang lain membayar kita untuk memperbaikinya, karena itu tidak seperti mereka mengharapkan perangkat lunak untuk bekerja di tempat pertama"? Ini mungkin tidak memenuhi definisi hukum, tetapi kedengarannya seperti penipuan bagi saya.
Chris Pitman

Jawaban:


43

Menyiapkan mesin CI mirip dengan memasang alarm kebakaran di rumah.

Menurut saya manfaatnya tidak berkorelasi dengan banyak pengembang, tetapi dengan basis kode yang besar. Mesin CI secara aktif melakukan semua pekerjaan membosankan yang tidak ingin Anda lakukan sendiri, dan melakukannya setiap saat.

Jika Anda merusak modul jarak jauh yang sudah lama tidak Anda sentuh, Anda akan diberi tahu dengan segera. Tidak hanya kompilasi yang bijak, tetapi juga berfungsi jika Anda telah mengatur tes unit.

Juga perhatikan bahwa jika Anda membiarkan mesin CI Anda melakukan semua pekerjaan yang membosankan, termasuk mengatur installer dll, Anda tidak harus melakukannya secara manual. Anda cukup memeriksa sumber Anda, dan menunggu produk jadi dibangun di lokasi standar. (EDIT: Engine CI juga bekerja di lingkungan yang terdefinisi dengan baik, menghindari pengaturan spesifik pengembang, memastikan reproduktifitas)

Ini juga merupakan bagian dari jaminan kualitas.


EDIT: Setelah menulis di atas, saya memiliki pengalaman dengan alat pembuatan Maven untuk Java. Pada dasarnya ini memungkinkan kita untuk menyimpan konfigurasi CI lengkap di dalam proyek (dengan pom.xml) membuatnya lebih mudah untuk mempertahankan instalasi CI dan / atau bermigrasi ke mesin CI lain.


1
@Carnotaurus, dalam hal ini lampu merah juga digunakan untuk kesalahan sementara. Kedengarannya seperti batasan pada mesin CI yang Anda gunakan.

2
@Carnotaurus dalam pengalaman saya, pekerjaan yang dilakukan untuk mendokumentasikan dengan seksama setiap aspek dari segala hal, misalnya melakukan rilis dan kemudian melakukan rilis tersebut beberapa kali, lebih besar daripada menangkap alur kerja dalam skrip semut atau pakar yang kemudian dapat dieksekusi oleh robot beberapa kali. Robot tersebut juga bekerja di lingkungan ruangan yang bersih memastikan bahwa bangunan dapat direproduksi.

1
Perhatikan bahwa pemecahan yang saya cari bukan gagal pada unit test tetapi program aktual yang kami kirimkan masih dapat dibangun. Ini tidak lagi penting karena kami bermigrasi ke artefak pakar alih-alih mengkompilasi semuanya untuk setiap rilis, tetapi masih penting untuk mengetahui bahwa build ini berfungsi penuh. Kami hanya perlu bagian Penerapan Berkelanjutan juga.

2
@Carnotaurus: Saya tidak berbicara tentang sistem alarm. Jika tes gagal, tambalan tidak terintegrasi ke dalam repositori utama (sama sekali), memastikan bahwa setiap kali Anda checkout / klon Anda mendapatkan salinan yang berfungsi penuh dan dapat mulai bekerja segera. Sekarang, saya setuju dengan Anda bahwa tes bisa sulit untuk ditulis dan dipertahankan ... tetapi saya telah bekerja dengan dan tanpa tes, dan saya melihat peningkatan kualitas yang pasti dengan mereka. Jadi pertanyaannya adalah: otomatis atau tidak? Dalam pengalaman saya, perlu waktu untuk menguji secara manual daripada menulis skrip otomatisasi (tapi saya bekerja di perusahaan besar dengan alat untuk itu).
Matthieu M.

5
" Masih banyak pekerjaan untuk menangkap beberapa bug bahwa perusahaan akan dibayar untuk memperbaiki sebagai bagian dari perjanjian layanan klien " - yah dalam hal ini Anda memiliki insentif ekonomi TIDAK untuk menghasilkan perangkat lunak dengan bug sesedikit mungkin, dan dalam hal ini semua ini tidak berlaku untuk Anda.

33

Ini bukan berapa banyak pengembang, tetapi berapa banyak langkah yang diperlukan untuk mendapatkan dari 1 ke n (inklusif), di mana 1 & n ...

1: Memeriksa kode
Dan
n: memiliki paket installable \ deployable

Jika n <2 Anda mungkin tidak perlu CI
sebaliknya, Anda perlu CI

Pembaruan
Dari membaca temuan Anda, saya hanya dapat menyimpulkan bahwa Anda mendekati CI dari arah yang salah dan untuk alasan yang salah.


1
+1 - Saya sudah cukup banyak yang bisa saya tambahkan di atas - tetapi ini sangat dekat dengan inti mengapa saya suka CI ... tidak hanya untuk apa yang dilakukannya tetapi juga untuk apa yang mengharuskan Anda lakukan untuk membuatnya work (persyaratan itu adalah hal yang benar-benar harus Anda lakukan)
Murph

2
@murph: Yup, dan itu membawa sedikit keuntungan seperti 1) mengetahui apa yang ada di repositori Anda akan dibangun, 2) build klik tunggal, 3) bisa merilis versi pada saat pemberitahuan dan Jauh lebih banyak lagi
Binary Worrier

Jadi wajar untuk mengatakan bahwa itu tergantung pada kerumitan apa yang akan dirilis, diukur dengan jumlah langkah-langkahnya untuk penyebaran sebagai dapat "menguji" lapisan yang terpisah?
CarneyCode

1
@Carnotaurus: Maaf sobat, tapi saya tidak yakin saya tahu apa yang ingin Anda katakan. CI tidak ada hubungannya dengan pengujian. Ya, Anda bisa - dan harus - menjalankan tes unit sebagai bagian dari build, tetapi mereka tidak harus bergantung pada apa pun yang tidak diatur sebagai bagian dari tes. Namun CI melakukan pengujian bantuan. Salah satu dari banyak manfaat CI adalah memungkinkan tim QA untuk segera & mengambil perubahan kode baru. CI = Kemampuan Untuk Merilis Segera
Binary Worrier

1
@ BinaryWorrier - Saya pikir langkah 1 memeriksa kode;)

10

Ini bisa bernilai usaha bahkan untuk tim yang terdiri dari satu. Ini terutama benar ketika Anda mengembangkan kode lintas platform dan Anda perlu memastikan bahwa perubahan Anda akan bekerja pada kedua platform. Sebagai contoh, kompiler C ++ Microsoft lebih menerima daripada GCC, jadi jika Anda mengembangkan di Windows tetapi perlu mendukung Linux juga, memiliki sistem CI memberitahu Anda ketika build Anda rusak di Linux adalah bantuan besar.

Beberapa sistem CI cukup mudah diatur, sehingga biaya overhead tidak terlalu besar. Coba Jenkins atau Hudson misalnya.


Saya belum mempertimbangkan skenario lintas platform. Jika kompiler yang berbeda diperlukan untuk membuat build yang berbeda maka ada kasus kuat untuk CI - ambil upvote.
CarneyCode

4

Seperti yang Anda katakan ada biaya overhead pengaturan dan membuatnya tetap berjalan.

Tetapi pertanyaan di mana titik impas bukanlah fungsi dari berapa banyak orang yang Anda miliki di tim Anda, melainkan fungsi dari panjang proyek Anda.

Karena itu, ada bagian dari biaya setup yang dapat Anda gunakan dalam semua proyek masa depan Anda, sehingga dalam jangka panjang biaya overhead mungkin mendekati nol.


Jadi panjang proyek (ukuran proyek) penting bagi Anda CI? Saya telah menemukan alarm palsu menjadi sangat mahal.
CarneyCode

Ya, Anda harus punya waktu untuk membayar biaya pengaturan dan kurva pembelajaran. Secara teori Anda harus dari waktu ke waktu belajar cara menghilangkan alarm palsu.
Stephen Bailey

Ya, ini teori
CarneyCode

Yah, tidak, itu latihan. Seiring waktu, Anda membuat catatan tentang tes apa yang rapuh dan tes apa yang tidak, dan Anda tidak terlalu khawatir jika tes rapuh Anda pecah kecuali mereka pecah beberapa kali berturut-turut. Anda menulis tes yang lebih terisolasi dan kuat saat Anda mempelajari caranya, dan Anda membiarkan cakupan lama terbentuk seiring waktu alih-alih melakukannya sekaligus. Dalam prakteknya, CI bukan peluru perak, itu adalah proses perubahan yang membutuhkan waktu dan akhirnya mengarah ke perangkat lunak yang kurang buggy.
philosodad

3

Saya mengatur Jenkins minggu ini untuk membangun proyek .NET kecil yang saya kerjakan. Saya mengintegrasikannya dengan kontrol sumber Git saya sehingga memicu pembangunan di setiap komit. Saya mengintegrasikan unit test ke dalam build. Saya mengintegrasikan analisis statis dalam bentuk pelanggaran FxCop dan StyleCop.

Sekarang setiap kali saya check-in, itu memeriksa semua kode saya, membangunnya, menambah nomor versi di semua majelis, mengujinya, menganalisisnya untuk pelanggaran FxCop dan StyleCop, mengarsipkan pembuatan dan mencatat hasil dalam sejumlah grafik sehingga Saya memiliki visibilitas dari waktu ke waktu hasil pengujian dan pelanggaran.

Melakukannya dari awal membutuhkan waktu satu jam atau lebih (mungkin sehari dengan Google jika Anda belum pernah melakukannya). Tidak ada biaya karena semua alat tersedia secara gratis.

Jika, ketika dan ketika proyek dibangun, saya memiliki infrastruktur berkualitas tinggi yang akan tumbuh tanpa biaya. Jika atau ketika pengembang baru bergabung dengan proyek saya bisa mendapatkan visibilitas total pada pekerjaan mereka dan dampaknya terhadap proyek tanpa biaya.

Jadi satu-satunya skenario saya dapat melihat CI tidak layak sementara adalah untuk proyek yang akan memakan waktu satu hari atau lebih dan kemudian tidak pernah ditinjau kembali, atau satu dalam bahasa di mana tidak ada alat yang ada / gratis tersedia dan biaya untuk mendapatkannya tidak proporsional dengan pekerjaan.


Seperti yang saya katakan, itu adalah unit test untuk mencakup kode lawas yang menghadirkan biaya besar. Juga, kita tidak berbicara tentang tim satu orang di sini juga ... Saya menghargai kepala Jenkins.
CarneyCode

1
Untuk apa nilainya, saya memperoleh manfaat besar dari menjalankan server CI tanpa melakukan tes apa pun - hanya dari kepercayaan pada bangunan bersih dan ketersediaan paket penempatan.
Murph

1

Jika Anda dapat memverifikasi semua aspek proyek Anda setelah setiap perubahan, maka Anda tidak perlu CI.

Dalam semua kasus lain, ini merupakan kemenangan bersih.


Saya pikir ini adalah tempat saya berasal juga. Jauh lebih murah juga.
CarneyCode

Apa yang Anda maksud dengan verifikasi dalam kasus ini? Jika itu otomatis, terjadi sesering mungkin, dan membantu mengidentifikasi slip mental & kelalaian, maka saya siap untuk itu. :-)
William Payne

1

Overhead minimal. Saya akan mengatakan untuk proyek satu orang akan berguna. Setelah Anda mencapai dua itu sangat berharga.

Saya setuju bahwa untuk satu orang memproyeksikan jika Anda memiliki "satu langkah membangun / memverifikasi" maka Anda mungkin baik-baik saja dengan integrasi terus-menerus, tetapi dalam kasus-kasus tersebut Anda telah melakukan sebagian besar kerja keras untuk mengatur CI jadi mungkin juga hanya menempatkan itu dalam sistem formal (CC, Hudson, TeamCity, dll).


Maksudmu tanpa CI?
CarneyCode

1

Pertanyaan, kapan CI membayar untuk dirinya sendiri, adalah pertanyaan yang sulit dijawab pada proyek baru.

Pada proyek yang sudah ada, jauh lebih mudah dilihat. Jika Anda menemukan bug penting di bagian pengembangan rantai pasokan, Anda tahu bahwa masalah ada pada titik sedini mungkin. Biaya untuk memperbaiki itu sekarang adalah yang terendah. Jika masalah itu ada di lingkungan mana pun di atas pengembangan, biaya Anda lebih tinggi.

Sekarang, manajemen mungkin memutuskan untuk merilis dengan bug, tapi itu risiko bisnis. Setidaknya sekarang ini dapat dikurangi melalui penilaian risiko, daripada panggilan telepon / panik larut malam, yang, jika mereka ditagih dengan tarif per jam, akhirnya menjadi sangat mahal.

Hal lain yang perlu diperhatikan dalam hal biaya. Seperti apa departemen QA Anda? Apakah ini pengujian manual? Jika Anda menggunakan CI, Anda mungkin dapat mengurangi biaya QA keseluruhan dengan mengotomatiskan skrip-skrip tersebut pada kotak dev Anda. Anda mungkin dapat mengurangi jumlah orang QA yang mendukung proyek Anda dengan melibatkan mereka dalam fase CI.


1
Untuk mengganti tes regresi manual dengan beberapa tes otomatis UI dibutuhkan waktu dan keterampilan yang cukup. Di satu perusahaan, satu orang menulis sekitar 40% dari tes dan meninggalkan perusahaan. Beberapa tahun kemudian, tes masih belum ditulis. Saya yakin ini tipikal.
CarneyCode

Tidak, ini bukan tipikal.
quant_dev

Saya belum melihat banyak bukti
tandingan

Jika Anda menulis tes integrasi / penerimaan dalam bahasa DSL alami seperti Gherkin, Anda dapat dengan mudah menerjemahkan tes otomatis ke manual. Jadi saya tidak melihat itu sebagai masalah.
Mike Cornell

@Carnotaurus - Saya pikir ini tipikal. Saya sudah melihatnya dua kali juga. Tes otomatis UI sulit.
Rocklan

1

CI selalu selalu sepadan dengan itu: Rasa aman yang diberikannya memungkinkan Anda untuk bekerja pada tingkat yang lebih cepat daripada yang mungkin terjadi. Masalah yang Anda miliki tampaknya berkisar pada tes unit. Saya setuju bahwa tes unit sangat mahal, tetapi juga berpikir bahwa (untuk banyak hal) itu adalah pilihan paling buruk yang kita miliki. Secara pribadi, dan untuk jenis sistem yang cenderung saya kerjakan, saya bersumpah dengan tes tingkat sistem yang beroperasi pada kombinasi kasus dunia nyata dan (mungkin sintetik); Ini lebih murah daripada tes unit, dan masuk ke sudut-sudut yang sulit dijangkau dari alam semesta konseptual Anda: "Unknown Unknowns" karya Donald Rumsfeld.


Saya suka sedikit tentang tes UI tingkat sistem. Banyak pengujian hilang dalam kabut unit test kualitas dan cakupan yang dipertanyakan.
CarneyCode

Cakupan adalah masalah psikologi manusia juga; kami memiliki kecenderungan bawaan untuk menulis tes untuk kasus-kasus yang telah kami pikirkan. Karena alasan inilah bahwa untuk disertifikasi pada tingkat SIL yang tinggi, pengujian unit perlu ditulis oleh tim terpisah dari yang mengembangkan sistem yang diuji, dan meskipun demikian, ada banyak kasus & situasi yang jelas bagi semua orang saja. dalam retrospeksi. Diperlukan pemeriksaan ketat terhadap cakupan kode; tetapi luar biasa sulit dan mahal.
William Payne

... Karenanya manfaat yang Anda dapatkan dengan membuang sampah paling jahat yang dapat Anda temukan ke dalam sistem di tingkat atas dan melihat apa yang terjadi ... :-)
William Payne

1
+1 - Sepenuhnya setuju. Beberapa bagian dari suatu sistem tidak hanya dapat diuji unit (yaitu tepi seperti pada database). Tentu Anda bisa mengejek db, tetapi itu meninggalkan kode yang berbicara ke db belum teruji. Pada titik tertentu Anda perlu menulis beberapa tes dunia nyata yang mengintegrasikan sistem Anda dan berbicara dengan sistem lain. Ketika Anda melakukan itu, Anda selalu menemukan bug yang Anda lewatkan di dunia bersih nyaman dari unit test dan kerangka mengejek (LINQ to SQL muncul dalam pikiran).

Sebenarnya, saya baru-baru ini menemukan sebuah tes menarik tentang pengujian fuzz yang mungkin menebus pengujian unit: jester.sourceforge.net
William Payne

0

Selalu gunakan, terlepas dari ukuran tim. Jika itu hanya Anda misalnya, siapa tahu, Anda mungkin membuat kode dari laptop Anda di starbucks kemudian melanjutkan dari sistem beefier Anda di rumah?

Biaya overhead sebenarnya tidak terlalu buruk.


0

Satu. Ya, satu sudah cukup untuk mulai menggunakan integrasi berkelanjutan.


0

Ini bukan masalah berapa banyak pengembang, tetapi dari

Sebuah. Berapa banyak waktu yang Anda hemat menggunakan otomatisasi dan seberapa sering.

  • Hemat waktu untuk membangun setelah integrasi, menjalankan tes otomatis dan membuat pengaturan * frekuensi check-in = persen dari waktu yang disimpan.

b. Berapa banyak versi / cabang / produk yang Anda miliki.

  • Jika Anda memiliki satu pengembang yang bekerja pada dua cabang yang berbeda maka waktu yang dihemat menjadi dua kali lipat, karena masing-masing cabang membutuhkan pembangunan, pengujian dan pengemasan.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.